How to get a core dump (or debug a SIGSEGV)

[georg.viehoever]

Hi,

when running my devepment module, I currently get

Code: [Select]

...
Transferring pixel data: 100%
*** PCL Unix Signal Handler: Critical signal catched (11): Segmentation violation
Reading swap files...
103.76 MB/s
<* failed *>
Usually, I would now look into the core dump to find the place where this happens. But PI is clever enough to catch this. So how should I debug this situation?

Georg

[Nocturnal]

How about if you start PI from within gdb? Doesn't that give you a stack trace?

[Carlos Milovic]

BTW, this usually appears when you go outside a matrix or image. Check the limits of your "for" loops

[Juan Conejero]

So how should I debug this situation?

Usually you can catch the bug easily by writing control messages to stdout. For example:

std::cout << "*1" << std::flush;
... some code that perhaps throws a sigsegv
std::cout << "*2" << std::flush;

then launch PI from a terminal window. If you get this on the terminal:

*1*2

you know the problem is not within the code you are testing. However if you get only:

*1

before the exception, then you've catched it. If necessary, repeat this technique to stretch the code more and more until you get the offending bit. I use this technique and it helps me catch all bugs in the 98% of situations. Note that the calls to std::flush are essential here; without them, buffered output makes the testing code useless.

For the remaining 2%, I strongly recommend you create an Eclipse project for your module and launch the PixInsight Core application to start an interactive GDB session.

Good luck!