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

Luca Olivetti luca at ventoso.org
Mon Jun 25 22:44:16 CEST 2007

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.


More information about the fpc-pascal mailing list