On Sat, 2004-05-22 at 18:20, Sheldon Hearn wrote:
That patch doesn't stop Zorp's HTTP proxy dying under load, still with a sig 11. The Plug proxy doesn't exhibit this behaviour.
I'm going to try downgrading to 2.0.9, which also claims to have fixed this bug.
Downgrading to zorp-2.0.9 with libzorpll-2.0.26.24 doesn't improve the situation. # /usr/lib/zorp/zorp --version Zorp 2.0.9 Compile-Date: May 22 2004 16:56:47 Config-Date: 2004/05/22 Trace: on Debug: on IPOptions: off IPFilter-Tproxy: off Netfilter-Tproxy: on Netfilter-Linux22-Fallback: on Linux22-Tproxy: off Conntrack: on Zorplib 2.0.26.24 Compile-Date: May 22 2004 16:50:51 Trace: on MemTrace: off Caps: on Debug: on StackDump: on Again, the Plug proxy doesn't have a problem, which suggests that this isn't flakey memory causing the SIGSEGV: (gdb) back #0 0x4011ad0d in PyObject_Malloc () from /usr/lib/libpython2.3.so.1.0 #1 0x00000001 in ?? () #2 0x00000028 in ?? () #3 0x401b1b60 in _Py_NotImplementedStruct () from /usr/lib/libpython2.3.so.1.0 #4 0x4003a0fc in __JCR_LIST__ () from /usr/lib/libzorp.so.2 #5 0x40039660 in z_py_zorp_sockaddr_funcs () from /usr/lib/libzorp.so.2 #6 0x40d04470 in ?? () #7 0xbffff4c8 in ?? () #8 0x40020856 in z_py_zorp_sockaddr_new (sa=0x1) at pysockaddr.c:215 Previous frame inner to this frame (corrupt stack?) So neither the stable nor development branches of zorp-gpl copes with any significant level of concurrency. I'm testing with Apache Benchmark (ab) with a concurrency limit of only 100. Ciao, Sheldon.