Zope stops responding on hpux
Dear list-members I am desperately trying to get our zope application run on hpux, and any help is greatly appreciated. I have the following problem: When I click on a tal-object ("Page Template") to edit it, then zope stops responding. No error is logged, nothing. I even cannot stop zope anymore with "zopectl stop" or control-c if started with runzope. It seems that zope silently crashes... However, I can create a tal-object, it only happens when I try to edit. The last entries in tracert.log are: <snip> B 1087990040 2005-05-07T22:52:27 GET /temp_folder/tz/manage_workspace I 1087990040 2005-05-07T22:52:27 0 A 1087990040 2005-05-07T22:52:27 302 370 E 1087990040 2005-05-07T22:52:27 B 1087991560 2005-05-07T22:52:27 GET /temp_folder/tz/pt_editForm I 1087991560 2005-05-07T22:52:27 0 ----crash---- The last entries in Z2.log: <snip> 127.0.0.1 - admin [07/May/2005:22:51:57 +0200] "POST /temp_folder/manage_addProduct/PageTemplates/manage_addPageTemplate HTTP/1.1" 302 215 "http://localhost:8080/temp_folder/manage_addProduct/PageTemplates/manage_add..." "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 Firefox/1.0.3" 127.0.0.1 - admin [07/May/2005:22:51:57 +0200] "GET /temp_folder/manage_main HTTP/1.1" 200 15638 "http://localhost:8080/temp_folder/manage_addProduct/PageTemplates/manage_add..." "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 Firefox/1.0.3" 127.0.0.1 - admin [07/May/2005:22:51:57 +0200] "GET /misc_/PageTemplates/zpt.gif HTTP/1.1" 304 258 "http://localhost:8080/temp_folder/manage_main" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 Firefox/1.0.3" 127.0.0.1 - admin [07/May/2005:22:52:27 +0200] "GET /temp_folder/tz/manage_workspace HTTP/1.1" 302 370 "http://localhost:8080/temp_folder/manage_main" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 Firefox/1.0.3" ---crash---- My configuration are: Python 2.3.3 compiled from source downloaded from the HP site: http://hpux.connect.org.uk/hppd/hpux/Languages/python-2.3.3/ This is the only python I manage to compile with-threads enabled. Zope 2.7.6-final compiled from source hpux version: $ uname -a HP-UX zuse B.11.11 U 9000/800 647349392 unlimited-user license Zope Version (Zope 2.7.6-final, python 2.3.3, hp-ux11) Python Version 2.3.3 (#40, May 3 2005, 09:18:26) [GCC 3.4.3] System Platform hp-ux11 I have also compiled and run zope versions 2.7.0/3/5, with no luck and always the same problem. Has anyone seen a similar problem with zope? Is anyone running zope successfully on hpux? Information on zope on hpux is very scarce, so I fear that I am very lonely in the field... Any hint is greatly appreciated where I can look at or how I could debug zope. Thank you very much Samuel
On May 7, 2005, at 23:45 , Samuel Bieri wrote:
Dear list-members
I am desperately trying to get our zope application run on hpux, and any help is greatly appreciated. I have the following problem:
I know this isn't really helpful, but when it comes to exotic operating systems like HP-UX you might be all on your own and there won't be many people to help. If you really want to use Zope it might be easier and cheaper in the long run to buy a i386-based commodity server and put Linux on it. jens
Samuel Bieri <samuel.bieri@e-globe-technologies.com> wrote:
When I click on a tal-object ("Page Template") to edit it, then zope stops responding. No error is logged, nothing. I even cannot stop zope anymore with "zopectl stop" or control-c if started with runzope. It seems that zope silently crashes...
You may want to try DeadlockDebugger. Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of R&D +33 1 40 33 71 59 http://nuxeo.com fg@nuxeo.com
Thank you a lot Florent for the hint ! The DeadlockDebugger seems to install and run correctly: event.log: <snip> 2005-05-08T19:55:20 INFO(0) ZServer HTTP server started at Sun May 8 19:55:20 2005 Hostname: zuse.xxxx Port: 8080 ------ 2005-05-08T19:55:20 INFO(0) ZServer FTP server started at Sun May 8 19:55:20 2005 Hostname: zuse Port: 8021 ------ 2005-05-08T19:55:21 INFO(0) DeadlockDebugger Installed ------ 2005-05-08T19:55:24 INFO(0) Zope Ready to handle requests And the Debugger gives me the threads traceback dump. But when I click on a tal-object, then zope deadlocks and also DeadlockDebugger does not return the dump anymore. Samuel Florent Guillaume wrote:
Samuel Bieri <samuel.bieri@e-globe-technologies.com> wrote:
When I click on a tal-object ("Page Template") to edit it, then zope stops responding. No error is logged, nothing. I even cannot stop zope anymore with "zopectl stop" or control-c if started with runzope. It seems that zope silently crashes...
You may want to try DeadlockDebugger.
Florent
Samuel Bieri wrote at 2005-5-7 23:45 +0200:
... When I click on a tal-object ("Page Template") to edit it, then zope stops responding. No error is logged, nothing. I even cannot stop zope anymore with "zopectl stop" or control-c if started with runzope. It seems that zope silently crashes... However, I can create a tal-object, it only happens when I try to edit.
Try to run Zope inside a debugger. The debugger may be able to tell you about spurious signals causing Zope to die or to analyse the state once Zope is hanging. -- Dieter
Dieter Maurer wrote:
Samuel Bieri wrote at 2005-5-7 23:45 +0200:
... When I click on a tal-object ("Page Template") to edit it, then zope stops responding. No error is logged, nothing. I even cannot stop zope anymore with "zopectl stop" or control-c if started with runzope. It seems that zope silently crashes... However, I can create a tal-object, it only happens when I try to edit.
Try to run Zope inside a debugger.
I managed to compile GNU debug 6.1.1 on the hp-ux box. When I run zope inside gdb I get the following: (gdb) run <snip> 2005-05-08T22:29:59 INFO(0) Zope Ready to handle requests [New thread 2 (system thread 9556080)] [New thread 3 (system thread 9556082)] [New thread 4 (system thread 9556083)] [New thread 5 (system thread 9556084)] ---> here I klick on a tal-obect in zope. Zope freezes. Then I kill zope. Program received signal SIGQUIT, Quit. 0x77d2ca58 in __lwp_sema_wait () from /usr/lib/librt.2 (gdb) bt #0 0x77d2ca58 in __lwp_sema_wait () from /usr/lib/librt.2 #1 0x77d2ba78 in sem_wait () from /usr/lib/librt.2 #2 0x77d2ba10 in sem_wait () from /usr/lib/librt.2 #3 0x77d2ba10 in sem_wait () from /usr/lib/librt.2 Previous frame identical to this frame (corrupt stack?) (gdb) Can any experienced zope programmer help me further? What does this mean? Thank you very much, Samuel
On Sun, 8 May 2005, Samuel Bieri wrote:
I managed to compile GNU debug 6.1.1 on the hp-ux box.
I hope it wasn't too much trouble. You could have gotten it from here: http://www.hp.com/go/wdb
---> here I klick on a tal-obect in zope. Zope freezes. Then I kill
zope.
Program received signal SIGQUIT, Quit. 0x77d2ca58 in __lwp_sema_wait () from /usr/lib/librt.2
(gdb) bt # 0 0x77d2ca58 in __lwp_sema_wait () from /usr/lib/librt.2 # 1 0x77d2ba78 in sem_wait () from /usr/lib/librt.2 # 2 0x77d2ba10 in sem_wait () from /usr/lib/librt.2 # 3 0x77d2ba10 in sem_wait () from /usr/lib/librt.2 Previous frame identical to this frame (corrupt stack?) (gdb)
Can any experienced zope programmer help me further? What does this mean?
Looks like a deadlock on a semaphore to me, though I couldn't say where. Did you python build pass all of the self tests? Did you build your python with the posix threads apis (i.e. not DCE threads)? Jeff D ---- Jeff Donsbach Webmaster (and bass drummer) Middlesex County Volunteers Fifes and Drums http://www.mcvfifesanddrums.org/ webmaster@mcvfifesanddrums.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 zope-list@mcvfifesanddrums.org wrote:
On Sun, 8 May 2005, Samuel Bieri wrote:
I managed to compile GNU debug 6.1.1 on the hp-ux box.
I hope it wasn't too much trouble. You could have gotten it from here: http://www.hp.com/go/wdb
---> here I klick on a tal-obect in zope. Zope freezes. Then I kill
zope.
Program received signal SIGQUIT, Quit. 0x77d2ca58 in __lwp_sema_wait () from /usr/lib/librt.2
(gdb) bt # 0 0x77d2ca58 in __lwp_sema_wait () from /usr/lib/librt.2 # 1 0x77d2ba78 in sem_wait () from /usr/lib/librt.2 # 2 0x77d2ba10 in sem_wait () from /usr/lib/librt.2 # 3 0x77d2ba10 in sem_wait () from /usr/lib/librt.2 Previous frame identical to this frame (corrupt stack?) (gdb)
Can any experienced zope programmer help me further? What does this mean?
Looks like a deadlock on a semaphore to me, though I couldn't say where.
Did you python build pass all of the self tests? Did you build your python with the posix threads apis (i.e. not DCE threads)?
Good points. In addition, you need to find a way to build Python 2.3.4, at least (2.3.5 would be; that release fixed a GC bug which was known to cause segfaults in Zope. It might be useful to read through the python-dev traffic related to HP-UX, as well, e.g.: http://mail.python.org/pipermail/python-dev/2004-January/thread.html#41607 Tres. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCf0lx+gerLs4ltQ4RAsGIAKClBraMxufi6IlEgwch+KIVkALUYwCfXKUX 8mUUP5hPHcIdusViyWYt9Rk= =T7Yv -----END PGP SIGNATURE-----
Samuel Bieri wrote at 2005-5-8 22:44 +0200:
...
Try to run Zope inside a debugger.
I managed to compile GNU debug 6.1.1 on the hp-ux box. When I run zope inside gdb I get the following: (gdb) run <snip> 2005-05-08T22:29:59 INFO(0) Zope Ready to handle requests [New thread 2 (system thread 9556080)] [New thread 3 (system thread 9556082)] [New thread 4 (system thread 9556083)] [New thread 5 (system thread 9556084)]
---> here I klick on a tal-obect in zope. Zope freezes. Then I kill zope.
Program received signal SIGQUIT, Quit. 0x77d2ca58 in __lwp_sema_wait () from /usr/lib/librt.2
Usually, "Control-C" is a better way to get debugger control.
(gdb) bt #0 0x77d2ca58 in __lwp_sema_wait () from /usr/lib/librt.2 #1 0x77d2ba78 in sem_wait () from /usr/lib/librt.2 #2 0x77d2ba10 in sem_wait () from /usr/lib/librt.2 #3 0x77d2ba10 in sem_wait () from /usr/lib/librt.2 Previous frame identical to this frame (corrupt stack?) (gdb)
That's sad. It may mean that the runtime library is so much optimized that GDB is unable to rebuild the call chain. If this is indeed the case, then it will not be easy to analyse your problem...
Can any experienced zope programmer help me further?
At least the incomplete traceback is not a Zope but an HP-UX issue. -- Dieter
participants (6)
-
Dieter Maurer -
Florent Guillaume -
Jens Vagelpohl -
Samuel Bieri -
Tres Seaver -
zope-list＠mcvfifesanddrums.org