On 10/11/2004 Tres Seaver wrote:
causing the problem. You can "fix" the problem by one of two means:
- Run with a newer, NPTL-enabled glibc. To stay on Debian, I belive this would entail upgrading from Woody to Sarge. I am only lightly familiar with Debian, so perhaps somebody can correct me?
thanks for that suggestion, anyway i'm quite sure that this isn't the problem, as all machines where i try to reproduce this bug run the same libc6 version (2.3.2.ds1). if it could be a kernel matter, the failing box runs 2.4.27, but i already tested this on another machine with 2.4.27 kernel as well, and it wasn't even reproducable there. could it be a matter of kernel configuration? other things that came into my mind are: -> the failing box has 3 virtual ips on virtual devices, maybe this causes problems? nevertheless i started zope with -a 127.0.0.1 and -d 127.0.0.1, so could this be an issue? -> maybe some python modules cause zope to fail? this would mean, that self-compiled python uses the installed debian python modules as well. the only modules installed on the failing box, but not on the other test machines are python2.2-egenix-mxdatetime, python2.2-egenix-mxtools, python2.2-optik and python2.2-photo, as these are required by Zope products we use.
- Install an alternate threading package, and compile Python to use it instead of the default one in libc. Note that I have *no* idea how to do this even on systems where I am more comfortable than with Debian.
so you mean replacing my libc6? i'm quite confident that my libc6 has threating support. are you discussing the issue, that python2.2 doesn't restart zope after SIGSEGV(11)? in this case ignore my response *g* this thread is about the problem itself, why zope SIGSEGVs at all. bye jonas