0

When an application causes a serious segment-fault issue, which is hard to find or track. I can use a debug version and generate a core dump file when issue happens. And debug this app with core-dump file.

But how to track down exceptional bugs in application when released? There seems to be no core-dump file in release version. Although log is an option, it is useless when there is a hard to track bugs happens.

So my question is how to track down those hard to track bugs in release version? Any suggestions or technology out there available?

Following reference may help the discussion.

[1] Core dump in Linux

[2] generate a core dump in linux

[3] Solaris Core dump analysis

Community
  • 1
  • 1
Daniel
  • 631
  • 2
  • 7
  • 14

4 Answers4

1

You can compile a release version with gcc -g -O2 ...

The lack of core dump is related to your user's setting of resource limits (unless the application is explicitly calling setrlimit or is setuid; then you should offer a way to avoid that call). You might teach your users how to get core dumps (with the appropriate bash ulimit builtin).

(and there is some obscure way to put the debugging information outside of the executable)

Basile Starynkevitch
  • 223,805
  • 18
  • 296
  • 547
1

The distributions provide -dbg packages that provide debugging symbols for programs. They are built along with the binary packages and can provide your users the ability to generate meaningful backtraces from core dumps. If you build your packages using the same utilities, you can get these -dbg packages for your own software "nearly free".

sarnold
  • 102,305
  • 22
  • 181
  • 238
0

Ask the "customer" for a description of what he or she did to make it crash, and try to replicate it yourself with your own version that has debug information.

The hard part is getting correct information from the customer. Often they will say they did nothing special or nothing different than before. If possible, go see the person having the problem, and ask them to do what they do to make the program crash, writing down every step.

Some programmer dude
  • 400,186
  • 35
  • 402
  • 621
  • Well, you know it's really difficult to write down these steps. And even we have those steps. It can't reproduce the bug, which is described by the customer. So I'm here asking a possible way to tell the customer to open the flag and run the application. When it crashes. Send me XXX files. – Daniel Dec 06 '11 at 09:12
  • Ok, sometimes, we send a debug version to our customer, the debug version never crashes. But I have checked those DEBUG MACROs, and have no clue to the root cause. So I wanna just use the same binary file and generate some core-dump files and debug the issue with core-dump file. Anyway, I just wanna use the same binary file to get what's happening out there. – Daniel Dec 06 '11 at 09:15
0

I suggest to use a crash reporting system, in my experience we use google's break-pad project for our windows client program, of course you can write your own.

Google break-pad is an open-source multi-platform crash reporting system, it can make mini or full memory dump when exception or crash happen, then you can config it to upload the dump file and any additional files to a specific ftp server or http server, very help to find bug.

Here is the link:

Google Break-pad

Louis
  • 407
  • 2
  • 7
  • [Breakpad would use a per-user daemon to write out a minidump that does not have, interact with or depend on the crashing process.](http://code.google.com/p/google-breakpad/wiki/ExceptionHandling) How about the performance impact? Any data available? Links are appreciated. Thanks. – Daniel Dec 07 '11 at 02:57
  • I'm using break-pad as a thread in my process, not a daemon. Break-pad just start the thread and waiting for a signal or exception, I think there is no performance impact at the runtime. – Louis Dec 07 '11 at 07:29