Re: [Zope-dev] Core Dump (Zope 2.7, Python 2.3.3, FreeBSD 4.5)
Dieter Maurer wrote at 2004-2-19 19:52 +0100: We have a report for Zope 2.7 about an object magically turning into None (1 or 2 weeks ago). A similar problem was discovered recently by a colleague. I started analysing it today. It turned out that objects are non-deterministically converted into None. I have seen such behaviour in the past (with an old Python version). Later, it turned out to be a memory corruption problem in this Python version. Memory corruption can also cause death with a core dump. It is well possible that our problem is caused by my Zope modifications or other (third party) C level extensions. But, there might also be some lingering problem in Python2.3.3/Zope2.7. After having looked at the Python code, I recognize the extreme low likelyhood that a memory corruption manifests itself in objects becoming None. I was able to explain most (if not all) of our problems from harmless causes: * I had a bare return in a function that should return a value -- protected by a condition that is true only under very special (history dependent) circumstances. This explains the apparently non-deterministic apparent transition to None. In fact, no object transitioned to None and the behaviour was completely deterministic. * Another family of incidents where apparently constant objects became None was explained by the well known refresh property to bind the variables in a flushed module to None. * A third report is not yet explained but I am confident that it, too, will find an explanation without a memory corruption assumption. -- 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] Core Dump (Zope 2.7, Python 2.3.3, FreeBSD 4.5)
We have a report for Zope 2.7 about an object magically turning into None (1 or 2 weeks ago). A similar problem was discovered recently by a colleague. I started analysing it today. It turned out that objects are non-deterministically converted into None. I have seen such behaviour in the past (with an old Python version). Later, it turned out to be a memory corruption problem in this Python version. Memory corruption can also cause death with a core dump. It is well possible that our problem is caused by my Zope modifications or other (third party) C level extensions. But, there might also be some lingering problem in Python2.3.3/Zope2.7. I will thouroughly investigate our problem within the next week and report back. -- 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] Core Dump (Zope 2.7, Python 2.3.3, FreeBSD 4.5)
Dieter, Have you seen this behavior with a debug build of Python? Under a debug build, you're more likely to get complaints about dodgy C code and the garbage collection will complain about refcount problems it can detect. Jeffrey, Any luck with you're core dump? 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 )
Re: [Zope-dev] Core Dump (Zope 2.7, Python 2.3.3, FreeBSD 4.5)
On Feb 19, 2004, at 1:09 PM, Jeremy Hylton wrote: Jeffrey, Any luck with your core dump? I recompiled Python 2.3 with a bigger stack size, and that seems to have worked. We had similar problems with Python 2.1.3 (it's a pretty infamous Python+FreeBSD problem, AFAICT), and I thought that it was patched in the Python core by now as I thought I heard something along those lines a while back, but I may have been hearing about the patch being applied to the BSD 'ports' collection. -- Jeffrey P Shell [EMAIL PROTECTED] ___ 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)
[Jeffrey P Shell] We had similar problems with Python 2.1.3 (it's a pretty infamous Python+FreeBSD problem, AFAICT), and I thought that it was patched in the Python core by now as I thought I heard something along those lines a while back, but I may have been hearing about the patch being applied to the BSD 'ports' collection. I don't think anything relevant changed in the Python core, apart from special-casing regexp tests on FreeBSD to have ever-lower expectations. Googling suggests that the BSD 'ports' collection (I have no understanding of what that means, though) added a Makefile option WANT_HUGE_STACK_SIZE which, if specified, causes FreeBSD to give threads the same stack size most other OSes give by default. It's an interesting meaning for huge, anyway wink. ___ 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 )
