[Zope-dev] Core Dump (Zope 2.7, Python 2.3.3, FreeBSD 4.5)
I've been experiencing the most peculiar core dump under Zope 2.7. It's on a web application we only decided to revive late last week, so it was never tested under earlier beta/RC conditions. The core dump occurs when visiting manage_main on a particular folder. The contents of this folder are basically just Python Scripts, Page Templates, and a few DTML Methods (including standard_error_message). I can get manage_main to render in zopectl debug (using Testing.make_request to make enough of a REQUEST object for it to render with). And I can read everything in that particular folder with zopectl debug. I used this to experiment with moving items around between folders - including moving all of the templates/scripts into their own folder outside of the web application. It still core dumps. At one point, I thought I had narrowed it down to a particular template (although the reasons for why it would be this template elude me) by doing some interactive Python work [I had written some helper 'move_object' and 'copy_object' functions a while back, and used them to move items between a pair of folders and then seeing which one Zope would crash on]. I got the contents of the template out using ``zopectl debug``, and recreated the template by hand, now that I could actually get into the target folder. It worked for a brief moment, but so did the source folder, which now had this one particular template remaining. I tried various imports and exports of the web application, including using one that was known to still be working off of a production server (Zope 2.6.1, Python 2.1). I even tried copying the contents (individually) of the folder - completely removing them from original context. It still core dumps. (Before I tried imports and exports, it was running in a Data.fs that had been copied from a Zope 2.6.1 instance to 2.7. Python Scripts were recompiled) Finally, I thought it might be a Python 2.3.3/FreeBSD issue (like there were issues with default stack size on Python 2.1.x and FreeBSD). This Python 2.3.3 had been built from source just last week, on the day I installed Zope 2.7 final on our development server. So I downloaded Zope 2.6.4 and ran that with Python 2.3.3, importing the problematic export. I could list the contents of this particular folder just fine. The import had Python 2.1 compiled scripts, so I recompiled them and exported it again just to see if that was causing strange issues - but when brought into Zope 2.7, the core dump still happens. The folder in question is not terribly large - when I extracted the scripts/templates manually into a new folder, I think it has about 41 items in it. What should I do next? Should I familiarize myself with gdb and inspect the core? What are some things I could look for if that's the next step? ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] [ZConfig] import inhomogenous
The import element of ZConfig schemas is inhomogenous: * with a package attribute it imports a component from a Python package * with an src attribute it imports a schema from an URL It would be better if the type of the imported object (schema or component) were orthogonal to the location from where the object is found (in a package or via an URL). A use case is the import of the section types defined in Zope.Startup.zopeschema.xml for other ZEO applications that require access to the same ZODB database(s). It is far more convenient to access this schema via package+file than an URL. The attached patch adds an additional type attribute to the import element. It can take values schema or component and determines the type of object to be imported. Its default value () is handled to provide backward compatibility. -- Dieter zconfig_import.pat Description: ZConfig patch to make 'import' more orthogonal with respect to type of imported object and import location ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Core Dump (Zope 2.7, Python 2.3.3, FreeBSD 4.5)
On Tue, 2004-02-17 at 11:45, Jeffrey P Shell wrote: What should I do next? Should I familiarize myself with gdb and inspect the core? What are some things I could look for if that's the next step? The code dump is an important clue, so it's definitely worth looking at. It's also pretty simple. Run gdb [python] [core] where python is the binary you use with Zope and core is the core file. A few commands will give the most benefit. bt will produce a backtrace, much like a Python traceback. It will tell us where the program actually failed and what was on the call stack. If you only do this, we'll probably be in good shape. If you put the following code in your ~/.gdbinit file, then you can also inspect the Python stack frames: # If you are in an eval_frame() function, calling pyframe with no # arguments will print the filename, function name, and line number. # It assumes that f is the name of the current frame. define pyframe x/s ((PyStringObject*)f-f_code-co_filename)-ob_sval x/s ((PyStringObject*)f-f_code-co_name)-ob_sval p f-f_lineno end That helps match the C stack and the Python stack and pinpoints what Python code was executing. Jeremy ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Core Dump (Zope 2.7, Python 2.3.3, FreeBSD 4.5)
It does sound suspiciously like the freebsd python issue. What do you get in the event log when python crashes ? Is it SIGSEGV(11)/SIGBUS(10) or whatever ? This tends not to get triggered with a zeo debug prompt, for whatever reason. To find out, you could: - rebuild python with a very large stack - 1Mb *should* be enough - rebuild python with debugging symbols, then run python/zope with gdb and see what the stack trace says when it crashes. - sprinkle the zope code with log statements until you narrow down where the crash is happening. If it's the stack thing, it's probably in a call to the re module. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Understanding 2.7 Product import
Erik A.Dahl wrote at 2004-2-16 14:00 -0500: Ok 2.7 has an instance/Products directory. What magic is letting them be imported? You find this magic (implemented) in App.FindHomes. -- Dieter ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [ZConfig] import inhomogenous
On Tuesday 17 February 2004 01:10 pm, Dieter Maurer wrote: It would be better if the type of the imported object (schema or component) were orthogonal to the location from where the object is found (in a package or via an URL). I agree, that does seem nicer. Another approach would be to deprecate the import src=url/ form, so we only need to deal with components. The original src=url flavor was created before schema components had been thought through, and I'd be happy to see that go. A use case is the import of the section types defined in Zope.Startup.zopeschema.xml for other ZEO applications that require access to the same ZODB database(s). It is far more convenient to access this schema via package+file than an URL. Is there some reason not to simply move the section types to a schema component? That seems more in the spirit of making the schema modular. The attached patch adds an additional type attribute to the import element. It can take values schema or component and determines the type of object to be imported. Its default value () is handled to provide backward compatibility. I've not read the patch yet, so I'll ask: what's the point of the type attribute? Should it be an error if the type doesn't match the top-level element of the resource? If only advisory, is it actually useful? Thanks for thinking critically about ZConfig. Yes, I'm aware there are some proposals for changes I've not yet addressed. ;-) -Fred -- Fred L. Drake, Jr. fred at zope.com PythonLabs at Zope Corporation ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] The number of threads in z2.py file.
i'm using Zope-2.6.3, Red Hat-8.0, CMF-1.4.2, and CMFPlone-2.0-RC3. If the number of threads=4, the zope can start but cannot load into ZMI. After i change the number of threads=1, it can load into ZMI. Why? __ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] (no subject)
Dear Sir or Madame I'm workig with DTML methods and after puting the valors I can't see the values again.I would like to know if some can help me on after put the values can see them. Yours faithfully, Fábio Bruno _ MSN Messenger: converse com os seus amigos online. http://messenger.msn.com.br ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
