On Wed, 2001-12-05 at 15:41, Matthew T. Kromer wrote:
Leonardo Rochael Almeida wrote:
We aren't getting any core files, even after setting ulimit correctly (although we could be setting it uncorrectly. I'll look into that further). Anyway, someone else in this list said that core dumps for threaded apps in Linux were mostly useless, so we aren't investing much energy in it anyway.
With the short restart times we have, I'd prever a solution that didn't involve keeping a dead site dead for too long (as in, debugging with gdb). We are working in a ZEO scheme that would switch over the accelerator to proxy another zeo client, but we are not there yet.
It would be ideal if we could instruct python to grab the SIG11, invoke gdb, get a C stacktrace for all threads and let Zope die in peace. If it all happend in a few seconds, we will still keep the client happy.
Well largely, ALL I want is the backtrace -- and I'm wondering if I could cobble something together that could get it. The problem is it needs to look at the symbol table, and I dont know how to get at that via C -- ie, gdb doesnt have an interface that I know of that you can link in to grab a stack trace and exit.
If you don't think a core dump is going to be useful, gdb isn't going to be either. I know I have gotten Zope to dump core before, and I think I did this with -Z '', i.e. don't start a management process. Then you need some other way to start Zope when it dies. As for ZMySQLDA/MySQLdb, I do know that the MySQL client libraries will crash if you try use the same connection more than once simultaneously in two different threads. I have never quite been sure whether or not there is some kind of locking in Zope to prevent threads from simultaneously using two database connections, since I expect this would cause problems on virtually all implementations. -- Andy Dustman PGP: 0x930B8AB6 @ .net http://dustman.net/andy You can have my keys when you pry them from my dead, cold neurons.