[fpc-pascal] How to analyze a core dump?
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
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
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