Hi,
I attached with gdb to find the problem and had posted the stack traces
under the [Dbmail] Still waiting for bug resolutions thread.
The problem is that the crash is inside of the signal handler out of malloc
or free. So I am convinced it's a memory overwrite.
Thanks,
Andy

 under the On 12/23/02 17:52, "Dave Meador" <[EMAIL PROTECTED]> wrote:

> I've been running dbmail for several weeks but have not noticed this
> problem.  My mail system is not heavily loaded, so that may be a factor why
> I am not seeing this problem.  Whatever the casuse of the problem, it should
> be easy enough to find where it is getting into a loop by attaching into the
> process with gdb.
> 
> First, make sure your binaries are compiled with debug information by
> adding -g to CFLAGS as follows:
> 
> Find the CFLAGS in your Makefile (whichever you are using), for example:
> CFLAGS = -g  -Wall -O2 -D_BSD_SOURCE -D_SVID_SOURCE
> 
> Next, make the binaries with debug info -- run make distclean, then run
> make.
> Stop your existing pop/imap daemons: killall dbmail-pop3d; killall
> dbmail-imapd
> Start the newly compiled daemons that contain debug information:
> ./dbmail-pop3d; ./dbmail-imapd
> 
> Now let the servers run until you notice they are comsuming 50-100% cpu...
> 
> Determin which process-id  is consuming too much cpu with "top".  By default
> top shows the most active process at the top of the list... and on my
> machine the PID of that process is in the first column.  This should be the
> runaway dbmail-pop3d or dbmail-imapd process.
> 
> Run gdb --pid=<PID of runaway process>
> 
> Assuming you already know how to use the gdb debugger, you would just run
> "step", several times and I believe it will be extremely obvious in a short
> period of time which part of the program is in a tight loop.  Please report
> your findings back here...
> 
> Regards and good luck,
> --Dave
> 
> ----- Original Message -----
> From: "Craig Whitmore" <[EMAIL PROTECTED]>
> To: <[email protected]>
> Sent: Monday, December 23, 2002 11:41 AM
> Subject: Re: [Dbmail] DBMail 1.0 keeps using 50-99% CPU time.
> 
> 
>> Yes. we get it alot.. (but in imap as well(same problem as pop3)). It
> seems
>> to get stuck in a loop.
>> 
>> nobody     880  0.0  0.0  2156  868 ?        S    Dec22   0:00
> dbmail/imap4
>> : Idle
>> nobody   22478 97.3  0.1  3256 1188 ?        R    Dec23 731:23
> dbmail/imap4
>> : USER: username [1.1.1.1]
>> nobody   27117  0.0  0.0  2192  916 ?        S    08:38   0:00
> dbmail/imap4
>> : Idle
>> nobody   27118  0.0  0.0  2192  916 ?        S    08:38   0:00
> dbmail/imap4
>> : Idle
>> nobody   27119  0.0  0.0  2192  916 ?        S    08:38   0:00
> dbmail/imap4
>> : Idle
>> nobody   27120  0.0  0.0  2192  916 ?        S    08:38   0:00
> dbmail/imap4
>> : Idle
>> nobody   27121  0.0  0.0  2192  916 ?        S    08:38   0:00
> dbmail/imap4
>> : Idle
>> nobody   27122  0.2  0.0  2192  916 ?        S    08:38   0:00
> dbmail/imap4
>> : Idle
>> nobody   27123  0.0  0.0  2192  916 ?        S    08:38   0:00
> dbmail/imap4
>> : Idle
>> nobody   27124  0.0  0.0  2192  916 ?        S    08:38   0:00
> dbmail/imap4
>> : Idle
>> 
>> strace -p 22478
>> 
>> alarm(4294925807)                       = 21474837
>> read(6, "", 4096)                       = 0
>> getpid()                                = 22478
>> time(NULL)                              = 1040672347
>> alarm(4294925807)                       = 21474837
>> read(6, "", 4096)                       = 0
>> getpid()                                = 22478
>> time(NULL)                              = 1040672347
>> alarm(4294925807)                       = 21474837
>> read(6, "", 4096)                       = 0
>> getpid()                                = 22478
>> time(NULL)                              = 1040672347
>> alarm(4294925807)                       = 21474837
>> read(6, "", 4096)                       = 0
>> getpid()                                = 22478
>> time(NULL)                              = 1040672347
>> alarm(4294925807)                       = 21474837
>> read(6, "", 4096)                       = 0
>> getpid()                                = 22478
>> time(NULL)                              = 1040672347
>> alarm(4294925807)                       = 21474837
>> read(6, "", 4096)                       = 0
>> getpid()                                = 22478
>> time(NULL)                              = 1040672347
>> alarm(4294925807)                       = 21474837
>> read(6, "", 4096)                       = 0
>> getpid()                                = 22478
>> time(NULL)                              = 1040672347
>> alarm(4294925807)                       = 21474837
>> read(6, "", 4096)                       = 0
>> getpid()                                = 22478
>> time(NULL)                              = 1040672347
>> alarm(4294925807)                       = 21474837
>> read(6, "", 4096)                       = 0
>> getpid()                                = 22478
>> time(NULL)                              = 1040672347
>> alarm(4294925807)                       = 21474837
>> read(6, "", 4096)                       = 0
>> getpid()                                = 22478
>> 
>> 
>> Located in serverservice.c
>> 
>> ----- Original Message -----
>> From: "Eelco van Beek - IC&S" <[EMAIL PROTECTED]>
>> To: <[email protected]>
>> Sent: Tuesday, December 24, 2002 8:24 AM
>> Subject: Re: [Dbmail] DBMail 1.0 keeps using 50-99% CPU time.
>> 
>> 
>>> Yes, we are experiencing exactly that same thing...
>>> The problem is that we cannot narrow down the problem. Anybody?
>>> 
>>> Eelco
>>> 
>>> On maandag, dec 23, 2002, at 19:16 Europe/Amsterdam, Eric Renfro wrote:
>>> 
>>>> I keep having a consistant problem with dbmail-pop3d using up an
> almost
>>>> constant 50-99% CPU time while it's running. I keep noticing it
>>>> because my
>>>> compiles go extremely slow during that.
>>>> 
>>>> 
>>>> --
>>>> Eric Renfro
>>>> Myrddin Computers & Designs - CEO/President
> 
> _______________________________________________
> Dbmail mailing list
> [email protected]
> https://mailman.fastxs.nl/mailman/listinfo/dbmail
> 
> 

Reply via email to