[fpc-pascal] How to analyze a core dump?
tom at openhardware.net
Tue Jun 26 05:02:05 CEST 2007
Luca Olivetti wrote:
> En/na Jonas Maebe ha escrit:
>> On 14 jun 2007, at 19:04, Luca Olivetti wrote:
>>> No suggestions? Is there some special option (apart from -g) that I
>>> should specify to compile/link my program?
>> No. But the garbage backtrace means that either your gdb cannot parse
>> the signal handler frame, or that your program corrupted the call stack.
> Well, I'm starting to get desperate, I cannot debug where the sigsev
> occurs, I put a bazillion writeln and still I cannot see where the
> problem is. I can reproduce the sigsev at will, only I cannot see
> where it happens. I suspect it's one of the threads in the c library
> (linphonecore, http://www.linphone.org) I'm using (since in all of my
> threads I put writeln in the critical places, as well as in all the
> callbacks from said library), alas there's no sigsev when the same
> library is driven by the c console program that comes with it
> At one point I though the problem was in CheckSynchronize (since the
> last writeln before the sigsev was right before calling it), but it
> was just a timing coincidence (I was calling it with 1000, then when I
> tried with 0 I saw the sigsev right in the middle of a debugging
> printf in the library).
> Maybe it's not a good idea to mix c multithreaded libraries and pascal
> code? Any special unit I should use? (I already tried cmem and it made
> no difference).
> If I cannot solve it I think I'll have to write a small backend
> program in c that communicates with pascal either through stdin/stdout
> redirection or with a socket.
IIRC, it is 'gcc -c <corefilename>'
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net http://cyberiansoftware.com http://openzipit.org
"Windows? No thanks, I have work to do..."
More information about the fpc-pascal