[fpc-pascal] How to analyze a core dump?

Tom Walsh 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 
> (linphonec).
> 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.
> Bye
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 mailing list