On Thu, 27 Apr 2006, Michel Meyers wrote:
> Then I tried gcore:
> gcore -o /var/core 30611
>
> That dumped a file which I gzipped. I don't know whether my previous
> mail went through (might've been rejected with the big file), so just to
> be sure I uploaded it to Rapidshare (I don't have any fast webspace
> available myself). You can get it here:
>
> http://rapidshare.de/files/19037900/core.30611.gz.html
I downloaded that file, but gdb doesn't make much sense of it:
(gdb) backtrace
#0 0xffffe410 in ?? ()
(gdb) up
Initial frame selected; you cannot go up.
(gdb) down
Bottom (innermost) frame selected; you cannot go down.
(gdb) info frame
Stack level 0, frame at 0xbfd18cd8:
eip = 0xffffe410; saved eip 0xbfd18ce8
Arglist at 0xbfd18cd0, args:
Locals at 0xbfd18cd0, Previous frame's sp is 0xbfd18cd8
Saved registers:
eip at 0xbfd18cd4
(gdb) info locals
No symbol table info available.
I'm no expert in using gdb (I hardly ever use it). Can anybody else
suggest any other way of getting info out of this dump? Incidentally,
was this Exim compiled with -g? The lack of a symbol table suggests not.
(Or do I need a copy of the matching binary to get that?) What I'm
hoping to find in the end is where in the code this process is getting
into a loop. The fact that there is only one stack frame is confusing.
--
Philip Hazel University of Cambridge Computing Service
Get the Exim 4 book: http://www.uit.co.uk/exim-book
