Re: [exim] Bug#360696: Bug#360696: Failed to get write lock …

Página Inicial
Delete this message
Reply to this message
Autor: Philip Hazel
Data:  
Para: Michel Meyers
CC: exim-users, 360696-quiet, Andreas Metzler
Assunto: Re: [exim] Bug#360696: Bug#360696: Failed to get write lock for /var/spool/exim4/db/retry.lockfile:timedout
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