Re: hooking up gdb (was Re: [Zope-dev] More signal 11 restarts....)
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. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: hooking up gdb (was Re: [Zope-dev] More signal 11 restarts....)
Andy Dustman wrote: If you don't think a core dump is going to be useful, gdb isn't going to be either. Well, the problem is on Linux, the core file is from the process that received the SIG11, not the one that caused it, in most cases (due to the way Linux implements threads). To the best of my knowledge, the core does NOT contain the necessary registers of the remaining threads; thus gdb can't show you which thread dumped core. However, attaching gdb to the running zope usually does work, since gdb can inspect the processes when they are running to get the thread information. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
hooking up gdb (was Re: [Zope-dev] More signal 11 restarts....)
Well, one of the things I was going to ask next was for some help doing postmortem. 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. So, to answer your question, yes, I am confortable hooking up gdb. I'd just prefer if it could be done in as little time as possible. Cheers, Leo On Wed, 2001-12-05 at 18:10, Matthew T. Kromer wrote: Leo, Are you comfortable with hooking up gdb to Zope to try to catch this? I suspect, but do not know, that the MySQL python adapter is probably not doing something right w.r.t. memory management. Unfortunately, it is probably also the case that the problem only occurs with high-volume traffic -- particularly if it is a timing related bug. We have not been able to reproduce this problem in any deterministic way -- and the only people who seem to have it are those who are heavy MySQL users; it makes me think there is something in the adapter which is not behaving the same way under Python 2.1 than it did under Python 1.5.2. I have not looked at the adapter, so I'm making a few guesses as what is going wrong. -- Ideas don't stay in some minds very long because they don't like solitary confinement. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: hooking up gdb (was Re: [Zope-dev] More signal 11 restarts....)
Leonardo Rochael Almeida wrote: Well, one of the things I was going to ask next was for some help doing postmortem. 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. So, to answer your question, yes, I am confortable hooking up gdb. I'd just prefer if it could be done in as little time as possible. Cheers, Leo 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. Its been a while since I prowled the gdb source. I may not be able to do anything automatic like you want -- but I sure wish that tool was available! ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: hooking up gdb (was Re: [Zope-dev] More signal 11 restarts....)
Matthew T. Kromer writes: ... 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. I seem to remember that one can define gdb commands that are executed whenever the program stops. It this were true, we could activate such a definition in a .gdbinit file and then run the program. When the Python stops due to a signal, the command would be activated. It would make a backtrace followed by a quit. Not sure, it will work, though... Dieter ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
