I'm getting random segfaults using zope 2.5.1b1, mysql-python 0.9.2a2, ZMySQLDA 2.0.9b1, and MySQL 3.23.49 (using InnoDB tables) whenever I hammer my site using a web stress tool. I can cause a crash to occur repeatedly in about 5 seconds :-). I have Zope configured to use 8 threads.
Here's the interesting thing: I find that if I either run zope using only a single thread, or if I change the DB class in ZMySQLDA to use the THUNK transaction manager (which forces transactions to happen serially instead of in parallel) the crashes go away.
Does anyone have any ideas about potential concurrency problems anywhere in mysql-python (or elsewhere)? I noticed the mysql-python 0.9.2a2 started linking against libmysqlclient_r instead of libmysqlclient, which I was hoping would stop the problem but doesn't seem to help :-(.
Thanks for any help or suggestions :-).
Steve
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for answering... yeah, I did try 2.0.9b1 (check my message again) and sadly it doesn't help :-(. Actually, I don't think the thread locking put into 2.0.9b1 will actually do anything for most Zope users, since zope doesn't share instances of objects between threads anyway.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
rats, I still get the segfaults. Do you or does anyone here know a good way to debug this? I've tried attaching gdb to each thread but it doesn't seem to work, each thread keeps getting signals (SIG32??) which causes gdb to stop it...
TIA!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Okay, I tried that but these weird signals keep causing gdb to break. I tried to keep hitting 'c' but they happen so fast there's no way to keep up:
[root@dev2 skehlet]# gdb
GNU gdb 5.0
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux".
(gdb) attach 20977
Attaching to Pid 20977
0x40093986 in ?? ()
(gdb) c
Continuing.
Program received signal SIG32, Real-time event 32.
0x40093986 in ?? ()
(gdb) c
Continuing.
Program received signal SIG32, Real-time event 32.
0x40093986 in ?? ()
(gdb) c
Continuing.
Program received signal SIG32, Real-time event 32.
0x40093986 in ?? ()
.....
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
thanks a ton for all the help on this. the problem is not in mysql-python. sorry to imply it was :-).
My problem is somewhere in my version of libpthread (I'm running RH7.2). thanks to your help I was able to get gdb to give me a backtrace which revealed the problem.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm getting random segfaults using zope 2.5.1b1, mysql-python 0.9.2a2, ZMySQLDA 2.0.9b1, and MySQL 3.23.49 (using InnoDB tables) whenever I hammer my site using a web stress tool. I can cause a crash to occur repeatedly in about 5 seconds :-). I have Zope configured to use 8 threads.
Here's the interesting thing: I find that if I either run zope using only a single thread, or if I change the DB class in ZMySQLDA to use the THUNK transaction manager (which forces transactions to happen serially instead of in parallel) the crashes go away.
Does anyone have any ideas about potential concurrency problems anywhere in mysql-python (or elsewhere)? I noticed the mysql-python 0.9.2a2 started linking against libmysqlclient_r instead of libmysqlclient, which I was hoping would stop the problem but doesn't seem to help :-(.
Thanks for any help or suggestions :-).
Steve
Try the new 2.0.9b1 release.
Thanks for answering... yeah, I did try 2.0.9b1 (check my message again) and sadly it doesn't help :-(. Actually, I don't think the thread locking put into 2.0.9b1 will actually do anything for most Zope users, since zope doesn't share instances of objects between threads anyway.
Oh, I see there are some new files up, I think you meant try mysql-python 0.9.2b1... I'll try it out, thanks! :-)
rats, I still get the segfaults. Do you or does anyone here know a good way to debug this? I've tried attaching gdb to each thread but it doesn't seem to work, each thread keeps getting signals (SIG32??) which causes gdb to stop it...
TIA!
Once you attach gdb, use the cont command to continue execution. When it dies, bt will produce a backtrace. If you get one, file a bug report.
Okay, I tried that but these weird signals keep causing gdb to break. I tried to keep hitting 'c' but they happen so fast there's no way to keep up:
[root@dev2 skehlet]# gdb
GNU gdb 5.0
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux".
(gdb) attach 20977
Attaching to Pid 20977
0x40093986 in ?? ()
(gdb) c
Continuing.
Program received signal SIG32, Real-time event 32.
0x40093986 in ?? ()
(gdb) c
Continuing.
Program received signal SIG32, Real-time event 32.
0x40093986 in ?? ()
(gdb) c
Continuing.
Program received signal SIG32, Real-time event 32.
0x40093986 in ?? ()
.....
Try using the gdb command
handle 32 nostop
before continuing. You may need to add other signals (but not 11, that's the one you are waiting for).
thanks a ton for all the help on this. the problem is not in mysql-python. sorry to imply it was :-).
My problem is somewhere in my version of libpthread (I'm running RH7.2). thanks to your help I was able to get gdb to give me a backtrace which revealed the problem.