Small fix to AnyEvent::DBI, does not close correctly on DESTROY/kill_child

Marc Lehmann schmorp at
Tue Aug 27 17:18:49 CEST 2013

On Mon, Aug 26, 2013 at 02:55:46PM +0200, Jerry Lundström <jerry.lundstrom at> wrote:
> Hi Marc,
> I'm using AnyEvent::DBI and was getting some strange behavior (corrupt SQLite databases after a select(?)) and noticed that the spawned process did not always exit correctly, it sill existed even after the AnyEvent::DBI object was gone. After trashing the module with a lot of debug output I saw that the TERM signal was most likely ignored in the serve_fh and resulted in the process still waiting for input after the object was gone. Checked the code where the TERM signal was sent and saw that it only closes the socket, no specific shutdown. Added shutdown (both read/write) and it seems to have solved this issue.

Hi, this is all very confusing. First of all, if SQlite corrupts it's
database that would be a bug in sqlite. Regarding signals, it's possible
that something sets it to ignore, but it looks as if, again, this would be
a bug in sqlite (it has no business messing with signals).

I could try to reset the signal handler, in case it was set to ignore or
so before forking, but sqlite shouldn't ignore it. I could also indeed ask
the server differently to exit, if possible

Lastly, closing unrelated fds again shouldn't affect sqlite, which would
be another bug in sqlite.

Overall, this is not very surprising to me - sqlite quality is truly
atrocious, and the internet is full of people who ran into corruption
or crash bugs even without AnyEvent::DBI (including me), so I guess the
primary way out here is to bring sqlite up to the standard of other
database interfaces.

                The choice of a       Deliantra, the free code+content MORPG
      -----==-     _GNU_    
      ----==-- _       generation
      ---==---(_)__  __ ____  __      Marc Lehmann
      --==---/ / _ \/ // /\ \/ /      schmorp at
      -=====/_/_//_/\_,_/ /_/\_\

More information about the anyevent mailing list