On Tue, 2006-02-21 at 10:29 +0300, Oleg Lapshin wrote:
> > This isn't really an error just a warning message to developers about the
> > fact that on the previous call to db_query they didn't free the result
> > before calling db_query again. Aaron added my patch for memory leaks and
> > in it was this sort of catch all check as I was seeing a lot of query's
> > that wern't being freeded as the default db_query stores all result's even
> > if it isn't really needed..etc. I will let Aaron comment on the sieve
> > stuff.
> >
> > -leif
> 
> OK, but after nearly 10-15 operations from smartsieve web interface I get:
> 
> $ top -b -n 1 | grep timsieve
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND          
>                                     
> 28847 nobody    25   0  5164 1388  932 R 72.4  0.2   1:44.10 dbmail-timsieve
> 28842 root      16   0  4852 1108  800 S  0.0  0.1   0:00.00 dbmail-timsieve
> 28843 nobody    16   0  5076 1476 1052 S  0.0  0.2   0:00.02 dbmail-timsieve
> 28845 nobody    15   0  5076 1252  824 S  0.0  0.2   0:00.08 dbmail-timsieve
> 
> and up to 95% of cpu
> And then:
> 
> $ kill 28842
> MainSigHandler(): got signal [15]
> pool.c,manage_stop_children: General stop requested. Killing children..
> serverchild.c,active_child_sig_handler: got signal [Terminated]
> serverchild.c,active_child_sig_handler: setting stop request
> serverchild.c,PerformChildTask: accept failed
> serverchild.c,PerformChildTask: stop requested
> pool.c,child_reg_disconnected: [28845]
> serverchild.c,disconnect_all: database connection still open, closing
> pool.c,child_unregister: child [28845] unregistered
> serverchild.c,active_child_sig_handler: got signal [Terminated]
> serverchild.c,active_child_sig_handler: setting stop request
> pool.c,manage_stop_children: not all children terminated at SIGTERM, killing 
> hard now
> main(): server done, exit.
> main(): server has exited, exit status [0]
> main(): exit
> 
> 
> What happens with dbmail-timsieved ?

Good question! Unfortunately I won't have much time to dig into it
during the rest of the week :-\  A good valgrind session will probably
turn up the culprit.

Aaron


Reply via email to