import of zexp containing Page Template objects causes sudden zope death
Hi All, So, here the story; I have a zodb that's been around for many years. In it, it has a folder containing a few ZPTs and python scripts. This server is now running Zope 2.12. If I zexp export that folder and import into a clean 2.12 instance, the import works fine, but when I try to go to the folder in the ZMI, Zope dies immediately. No messages, no errors, no output. If I delete the ZPTs before the export and import, everything is okay. I can browse the folder and ZPTs fine on the originating server, even after the 2.12 upgrade. I'm left with a vague "wtf?!" feeling. Does anyone have any clue what the problem might be or how I can get any kind of output or error message when it does happen? Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chris Withers wrote:
Hi All,
So, here the story; I have a zodb that's been around for many years. In it, it has a folder containing a few ZPTs and python scripts.
This server is now running Zope 2.12.
If I zexp export that folder and import into a clean 2.12 instance, the import works fine, but when I try to go to the folder in the ZMI, Zope dies immediately. No messages, no errors, no output.
If I delete the ZPTs before the export and import, everything is okay.
I can browse the folder and ZPTs fine on the originating server, even after the 2.12 upgrade.
I'm left with a vague "wtf?!" feeling. Does anyone have any clue what the problem might be or how I can get any kind of output or error message when it does happen?
Binary search is your friend: - - Is it only one of the ZPTs which cause the crash? - - Can you trim out parts of its content and make it not crash? - - etc. Also, you might try exporting to XML and looking at the XML file for oddities (mojibake, etc.) You might try to open the imported folder under 'zopectl debug' and see if you can examine the contents of the ZPTs. If that works, then the issue must be in how 'manage_main' is trying to render the links / titles of the templates. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkx330cACgkQ+gerLs4ltQ7tIgCfdQRrfof/plQCLV3eSjj2HnTf VaAAn2JcARDIeqOJBG0TY/1sIEfppMBF =knjo -----END PGP SIGNATURE-----
Tres Seaver wrote:
Binary search is your friend:
- - Is it only one of the ZPTs which cause the crash?
Dunno this yet, will try and find out...
- - Can you trim out parts of its content and make it not crash?
Yep, if I leave the ZPTs out, it's fine ;-)
Also, you might try exporting to XML and looking at the XML file for oddities (mojibake, etc.)
mojibake?
You might try to open the imported folder under 'zopectl debug' and see if you can examine the contents of the ZPTs.
Yep, that worked.
If that works, then the issue must be in how 'manage_main' is trying to render the links / titles of the templates.
I can render manage_main under zopectl debug with a Test.makerequest'd app and a newSecurityManager(None,app.acl_users.getUserById('chris')) :-/ Again, "wtf?!" It's the sudden death I have issue with, not a peep of logging anywhere... Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chris Withers wrote:
Tres Seaver wrote:
Binary search is your friend:
- - Is it only one of the ZPTs which cause the crash?
Dunno this yet, will try and find out...
- - Can you trim out parts of its content and make it not crash?
Yep, if I leave the ZPTs out, it's fine ;-)
I meant "part of the offending template".
Also, you might try exporting to XML and looking at the XML file for oddities (mojibake, etc.)
mojibake?
Google is your friend.
You might try to open the imported folder under 'zopectl debug' and see if you can examine the contents of the ZPTs.
Yep, that worked.
If that works, then the issue must be in how 'manage_main' is trying to render the links / titles of the templates.
I can render manage_main under zopectl debug with a Test.makerequest'd app and a newSecurityManager(None,app.acl_users.getUserById('chris')) :-/
Again, "wtf?!"
It's the sudden death I have issue with, not a peep of logging anywhere...
Two options there: - - Set a breakpoint inside 'manage_main' and step into it until the fault. Figuring out how to do that for a DTMLFile instance is left as an exercise for the reader. :) - - Run under gdb. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkx37RQACgkQ+gerLs4ltQ5h+ACfS2FJdVmuMqkRGzjjR2rwPaOG j5gAoIUPYU5vIKAskMuQspAfit4npqXR =XetT -----END PGP SIGNATURE-----
Tres Seaver wrote:
It's the sudden death I have issue with, not a peep of logging anywhere...
Two options there:
- - Run under gdb.
gdb says: Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0xb0186cec [Switching to process 12270] 0x000dc08c in import_submodule () (gdb) bt #0 0x000dc08c in import_submodule () #1 0x000dc409 in load_next () #2 0x000dcdb1 in PyImport_ImportModuleLevel () #3 0x000b5a4f in builtin___import__ () #4 0x0000eb25 in PyObject_Call () #5 0x000bb4be in PyEval_CallObjectWithKeywords () Now, how in gdb do I find out what it was that was trying to be imported? (should any sort of import cause a core dump?!) Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chris Withers wrote:
Tres Seaver wrote:
It's the sudden death I have issue with, not a peep of logging anywhere... Two options there:
- - Run under gdb.
gdb says:
Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0xb0186cec [Switching to process 12270] 0x000dc08c in import_submodule () (gdb) bt #0 0x000dc08c in import_submodule () #1 0x000dc409 in load_next () #2 0x000dcdb1 in PyImport_ImportModuleLevel () #3 0x000b5a4f in builtin___import__ () #4 0x0000eb25 in PyObject_Call () #5 0x000bb4be in PyEval_CallObjectWithKeywords ()
Now, how in gdb do I find out what it was that was trying to be imported? (should any sort of import cause a core dump?!)
http://wiki.python.org/moin/DebuggingWithGdb Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkx4FxEACgkQ+gerLs4ltQ4GbgCg2NrcybBl6re/0aldLOTayf1g 8GIAniqrILMuvJ+fEpDqmRaZlGQK+2LG =Iv8Y -----END PGP SIGNATURE-----
Tres Seaver wrote:
Now, how in gdb do I find out what it was that was trying to be imported? (should any sort of import cause a core dump?!)
Things you learn, thanks for that :-) Okay, another interesting data point; this appears to be related to OS. The originating server is a 32-bit (I think, how can I double check?) linux box, the crashing machine is my 64-bit (but I'm pretty sure python is 32-bit, how can I check?) MacBook Pro. I tried importing the .zexp back onto the originating server; no crashes. I tried importing the .zexp onto my linux dev both; no crashes. This ring any bells for anyone? Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk
Hi Chris file command run on any binary (lib, executable will tell you) on linux timh@chrome:~$ file /usr/bin/python2.5 /usr/bin/python2.5: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15, stripped timh@chrome:~$ os/x will work the same. Rgds T On Sat, Aug 28, 2010 at 3:53 PM, Chris Withers <chris@simplistix.co.uk>wrote:
Tres Seaver wrote:
Now, how in gdb do I find out what it was that was trying to be imported? (should any sort of import cause a core dump?!)
Things you learn, thanks for that :-)
Okay, another interesting data point; this appears to be related to OS. The originating server is a 32-bit (I think, how can I double check?) linux box, the crashing machine is my 64-bit (but I'm pretty sure python is 32-bit, how can I check?) MacBook Pro.
I tried importing the .zexp back onto the originating server; no crashes.
I tried importing the .zexp onto my linux dev both; no crashes.
This ring any bells for anyone?
Chris
-- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Tim Hoffman wrote:
on linux
timh@chrome:~$ file /usr/bin/python2.5 /usr/bin/python2.5: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15, stripped timh@chrome:~$
Right, so the linux boxes are 32-bit as I suspected: $ file /usr/local/bin/python2.6 /usr/local/bin/python2.6: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.5, dynamically linked (uses shared libs), not stripped $ file /usr/local/bin/python2.6 /usr/local/bin/python2.6: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.8, not stripped
os/x will work the same.
Sadly not: $ file /Library/Frameworks/Python.framework/Versions/2.6/bin/python2.6 /Library/Frameworks/Python.framework/Versions/2.6/bin/python2.6: Mach-O universal binary with 2 architectures /Library/Frameworks/Python.framework/Versions/2.6/bin/python2.6 (for architecture ppc): Mach-O executable ppc /Library/Frameworks/Python.framework/Versions/2.6/bin/python2.6 (for architecture i386): Mach-O executable i386 Nonetheless, why would a .zexp on a 32-bit architecture and import on 64-bit cause sudden crash death when viewing /manage_main of a an imported folder containing Page Templates?! Still in "wtf?!" mode... Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk
On 29 August 2010 10:03, Chris Withers <chris@simplistix.co.uk> wrote:
Tim Hoffman wrote:
on linux
timh@chrome:~$ file /usr/bin/python2.5 /usr/bin/python2.5: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15, stripped timh@chrome:~$
Right, so the linux boxes are 32-bit as I suspected:
$ file /usr/local/bin/python2.6 /usr/local/bin/python2.6: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.5, dynamically linked (uses shared libs), not stripped
$ file /usr/local/bin/python2.6 /usr/local/bin/python2.6: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.8, not stripped
os/x will work the same.
Sadly not:
$ file /Library/Frameworks/Python.framework/Versions/2.6/bin/python2.6 /Library/Frameworks/Python.framework/Versions/2.6/bin/python2.6: Mach-O universal binary with 2 architectures /Library/Frameworks/Python.framework/Versions/2.6/bin/python2.6 (for architecture ppc): Mach-O executable ppc /Library/Frameworks/Python.framework/Versions/2.6/bin/python2.6 (for architecture i386): Mach-O executable i386
This is telling you that the executable contains versions for ppc and i386 (no x86_64, so no 64bit version). Another way to confirm this is at the python prompt with: import sys; sys.maxint
Nonetheless, why would a .zexp on a 32-bit architecture and import on 64-bit cause sudden crash death when viewing /manage_main of a an imported folder containing Page Templates?!
Still in "wtf?!" mode...
Your best bet is adding the breakpoint and stepping through with pdb until you hit the error (you can usually just hold down the return key after the first step...) Laurence
Laurence Rowe wrote:
architecture i386): Mach-O executable i386
This is telling you that the executable contains versions for ppc and i386 (no x86_64, so no 64bit version). Another way to confirm this is at the python prompt with: import sys; sys.maxint
That's annoying, I was hoping it'd be a 32-bit versus 64-bit problem.
Nonetheless, why would a .zexp on a 32-bit architecture and import on 64-bit cause sudden crash death when viewing /manage_main of a an imported folder containing Page Templates?!
Still in "wtf?!" mode...
Your best bet is adding the breakpoint and stepping through with pdb until you hit the error (you can usually just hold down the return key after the first step...)
Thankfully, I don't deploy in production on Mac OS X so, for now, it's a case of "don't do that" :-( If anyone wants to inspect the .zexp and see if they can figure out what's making it go pop, lemme know and I'll try and get one together that is small enough that I can let it out to play... Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk
On Mon, Aug 30, 2010 at 06:38:01PM +0100, Chris Withers wrote:
Laurence Rowe wrote:
Nonetheless, why would a .zexp on a 32-bit architecture and import on 64-bit cause sudden crash death when viewing /manage_main of a an imported folder containing Page Templates?!
Still in "wtf?!" mode...
Your best bet is adding the breakpoint and stepping through with pdb until you hit the error (you can usually just hold down the return key after the first step...)
Thankfully, I don't deploy in production on Mac OS X so, for now, it's a case of "don't do that" :-(
If anyone wants to inspect the .zexp and see if they can figure out what's making it go pop, lemme know and I'll try and get one together that is small enough that I can let it out to play...
I'm intrigued by mysteries like this. If you give me a .zexp, I'll give it a go. Of course the most likely and disappointing outcome is that it will just import cleanly on my Linux system. Marius Gedminas -- http://pov.lt/ -- Zope 3/BlueBream consulting and development
participants (5)
-
Chris Withers -
Laurence Rowe -
Marius Gedminas -
Tim Hoffman -
Tres Seaver