RE : Re: [Zope] RE : Re: RE : Re: Frequent Zope crashes (Zope 2.9.8)
Hi, --- Andreas Jung [EMAIL PROTECTED] a écrit : --On 17. Februar 2008 16:59:54 +0100 Paul Brettschneider [EMAIL PROTECTED] wrote: If I am informed correctly, only ZPsycopgDA contains C-code. The psycopg module is not built from source but installed via the Debian package repository. psycopg is partly written in C. Since you're using packages, try to compile psycopg yourself from the sources. If you're using a system python, try to setup your site with a Python source installation. we tried again with python 2.4 compiled from source (including psycopg and PIL) and a fresh compiled Zope 2.9.8. The crash still happens. Here is a gdb backtrace: 0x00446623 in type_dealloc (type=0x613280) at Objects/typeobject.c:2108 2108_PyObject_GC_UNTRACK(type); #0 0x00446623 in type_dealloc (type=0x613280) at Objects/typeobject.c:2108 #1 0x2b062b0f5f41 in cc_oid_unreferenced (self=0x2aaad120, oid=0x2bea6180) at persistent/cPickleCache.c:607 #2 0x2b062aeed5a8 in Per_dealloc (self=0x9fa7cf8) at persistent/cPersistence.c:578 #3 0x00446c23 in subtype_dealloc (self=0x9fa7cf8) at Objects/typeobject.c:703 #4 0x00436bfc in dict_dealloc (mp=0x4e1f1c0) at Objects/dictobject.c:766 #5 0x00446c7c in subtype_dealloc (self=0x9fa7c08) at Objects/typeobject.c:691 #6 0x00436bfc in dict_dealloc (mp=0x2ebfd40) at Objects/dictobject.c:766 #7 0x00446c7c in subtype_dealloc (self=0x9fa7230) at Objects/typeobject.c:691 #8 0x00436bfc in dict_dealloc (mp=0x53387c0) at Objects/dictobject.c:766 #9 0x00446c7c in subtype_dealloc (self=0x9fa72a8) at Objects/typeobject.c:691 #10 0x00436bfc in dict_dealloc (mp=0x24b2c20) at Objects/dictobject.c:766 #11 0x00446c7c in subtype_dealloc (self=0x2b319848) at Objects/typeobject.c:691 #12 0x00436bfc in dict_dealloc (mp=0x5baa280) at Objects/dictobject.c:766 #13 0x00446c7c in subtype_dealloc (self=0x2b3196e0) at Objects/typeobject.c:691 #14 0x00436bfc in dict_dealloc (mp=0x4aaf710) at Objects/dictobject.c:766 #15 0x00446c7c in subtype_dealloc (self=0x2bb80668) at Objects/typeobject.c:691 #16 0x00436bfc in dict_dealloc (mp=0x4ba6100) at Objects/dictobject.c:766 #17 0x00446c7c in subtype_dealloc (self=0x2bb80500) at Objects/typeobject.c:691 #18 0x00436bfc in dict_dealloc (mp=0x8b59320) at Objects/dictobject.c:766 #19 0x00446c7c in subtype_dealloc (self=0x2bb80398) at Objects/typeobject.c:691 #20 0x00436bfc in dict_dealloc (mp=0xf7fdd80) at Objects/dictobject.c:766 #21 0x00446c7c in subtype_dealloc (self=0x2bb801b8) at Objects/typeobject.c:691 #22 0x00436bfc in dict_dealloc (mp=0x80e06e0) at Objects/dictobject.c:766 #23 0x00446c7c in subtype_dealloc (self=0x2bb80cf8) at Objects/typeobject.c:691 #24 0x00436bfc in dict_dealloc (mp=0x5b74d10) at Objects/dictobject.c:766 #25 0x00446c7c in subtype_dealloc (self=0x2bb80d70) at Objects/typeobject.c:691 #26 0x00438dfb in _PyTrash_destroy_chain () at Objects/object.c:2087 #27 0x2b062b0f65fa in cc_clear (self=0x2aaad120) at persistent/cPickleCache.c:756 #28 0x0049f112 in collect (generation=117993392) at Modules/gcmodule.c:710 #29 0x0049f9b5 in _PyObject_GC_New (tp=0x5f3be0) at Modules/gcmodule.c:872 #30 0x0041a9fc in PyInstance_NewRaw (klass=0x2b062b81eb30, dict=0x4f52700) at Objects/classobject.c:543 #31 0x0041d093 in PyInstance_New (klass=0x2b062b81eb30, arg=0xbcc4cb0, kw=0xa01f2e0) at Objects/classobject.c:568 #32 0x00413a10 in PyObject_Call (func=0x613280, arg=0x2bea6180, kw=0x0) at Objects/abstract.c:1795 #33 0x004723c9 in PyEval_EvalFrame (f=0x4d3de90) at Python/ceval.c:3776 #34 0x00472d69 in PyEval_EvalFrame (f=0x5101a40) at Python/ceval.c:3651 #35 0x00472d69 in PyEval_EvalFrame (f=0x57902a0) at Python/ceval.c:3651 #36 0x00472d69 in PyEval_EvalFrame (f=0x5d42260) at Python/ceval.c:3651 #37 0x00472d69 in PyEval_EvalFrame (f=0x5790030) at Python/ceval.c:3651 #38 0x00472d69 in PyEval_EvalFrame (f=0x24f1090) at Python/ceval.c:3651 #39 0x00472d69 in PyEval_EvalFrame (f=0x5c06f70) at Python/ceval.c:3651 #40 0x00472d69 in PyEval_EvalFrame (f=0x542fc20) at Python/ceval.c:3651 #41 0x00472d69 in PyEval_EvalFrame (f=0x8dfb5d0) at Python/ceval.c:3651 #42 0x00472d69 in PyEval_EvalFrame (f=0x5ee53b0) at Python/ceval.c:3651 #43 0x00472d69 in PyEval_EvalFrame (f=0x3317c30) at Python/ceval.c:3651 #44 0x00472d69 in PyEval_EvalFrame (f=0x8655750) at Python/ceval.c:3651 #45 0x00472d69 in PyEval_EvalFrame (f=0x2d4c500) at Python/ceval.c:3651 #46 0x00472d69 in PyEval_EvalFrame (f=0x7ca56a0) at Python/ceval.c:3651 #47 0x00472d69 in PyEval_EvalFrame (f=0x4d25e40) at Python/ceval.c:3651 #48 0x00472d69 in
[Zope] RE : Re: RE : Re: Frequent Zope crashes (Zope 2.9.8)
Hi, --- Tres Seaver [EMAIL PROTECTED] a écrit : -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul Brettschneider wrote: Hi, --- Tres Seaver [EMAIL PROTECTED] a écrit : Paul Brettschneider wrote: Hello, my Zope 2.9.8 instance crashes up to 6 times per hour. This is very unfortunate since the constant restarting brings performance to its knees. It runs under Linux in 64 bit mode on an AMD64 . I managed to catch two backtraces with gdb (see end of the mail). Both backtraces show a crash in cc_oid_unreferenced(ccobject *self, PyObject *oid) in persistent/cPickleCache.c: Either in line 576: v = PyDict_GetItem(self-data, oid); or in line 607: Py_DECREF((ccobject *)((cPersistentObject *)v)-cache); v and v-cache seem to point to heap: (gdb) print v $1 = (PyObject *) 0x5f8920 (gdb) print ((cPersistentObject *)v)-cache $2 = (PerCache *) 0x613620 Always called from Per_dealloc(cPersistentObject *self) in persistent/cPersistence.c in line 578: cPersistenceCAPI-percachedel(self-cache, self-oid); Is this a known issue? Thank you for any help, Can you reproduce using the following from-scratch build? No, the crash only happens with this zope instance and only under heavy load. I will try to remove all custom products before filing a bug report. Hmm, I was hopeful that there might have been a build glitch (some 32- vs. 64 bit thing). Isolating such a problem will be easier if we can reproduce the error on a system whose Zope you built yourself from source. This instance is compiled from source. I will try again with an updated gcc. I wouldn't rip out third-party products, esepecially those which have no C extensions: they can hardly be provoking the segfault. Hmm, I wonder if you might be using a third-party library which *does* (e.g., an RDBMS or LDAP client library, PIL, etc.). Verifying the mechanism used to build them would be important, too. I removed a custom product which I suspected being the culprit. The crashes still happen, but now only about five times a day (probably due to much less traffic at the moment), making obtaining gdb backtraces hard. I managed to do it and it still segfaults in the same place: #0 0x00436777 in PyDict_Contains () #1 0x004369ad in PyDict_GetItem () #2 0x2b3c60f78f37 in cc_oid_unreferenced (self=0x2ab034c8, oid=0x2dae6cf0) at persistent/cPickleCache.c:576 #3 0x2b3c60d70d28 in Per_dealloc (self=0x2dae4a28) at persistent/cPersistence.c:578 The currently installed products are: drwxr-xr-x 8 zope users 4096 2007-10-31 11:16 CMFActionIcons drwxr-xr-x 9 zope users 4096 2007-10-31 11:16 CMFCalendar drwxr-xr-x 9 zope users 4096 2007-10-31 11:16 CMFCore drwxr-xr-x 12 zope users 4096 2007-10-31 11:16 CMFDefault drwxr-xr-x 6 zope users 4096 2007-10-31 11:16 CMFSetup drwxr-xr-x 7 zope users 4096 2007-10-31 11:16 CMFTopic drwxr-xr-x 5 zope users 4096 2007-10-31 11:16 CMFUid drwxr-sr-x 4 zope users 4096 2007-11-06 11:46 CookieCrumbler drwxr-xr-x 7 zope users 4096 2007-10-31 11:20 DCWorkflow drwxr-sr-x 2 zope users 4096 2008-01-28 21:26 DeadlockDebugger drwx--Sr-x 4 zope users 4096 2007-11-24 11:05 Epoz drwxr-xr-x 6 zope users 4096 2007-11-24 11:05 ExternalEditor drwxr-xr-x 7 zope users 4096 2007-11-24 11:05 Localizer drwxr-sr-x 3 root users 4096 2007-11-06 11:37 TranslationService drwxr-sr-x 2 root users 4096 2007-11-06 11:37 ZNagios drwxr-sr-x 3 zope users 4096 2008-02-17 14:57 ZPsycopgDA If I am informed correctly, only ZPsycopgDA contains C-code. The psycopg module is not built from source but installed via the Debian package repository. The imports in all external methods are: from base64 import encodestring from DateTime import * from DateTime import DateTime from DocumentTemplate import HTML from email.Header import Header from htmlentitydefs import entitydefs from HTMLParser import HTMLParser,HTMLParseError,piclose, charref, entityref from math import floor from os import popen from PIL import Image from popen2 import popen2 from re import match from string import * from string import atoi from string import atoi, atof from string import atoi, atof, split, find from string import atoi, atof, split, join from string import find from string import join from string import lower,find from string import replace from string import split from string import split, atoi from string import strip from StringIO import StringIO from StructuredText import HTML from tempfile import NamedTemporaryFile from whrandom import choice from whrandom import randint from ZODB.POSException import POSKeyError import cStringIO import difflib import httplib import os import PIL.Image import PIL.Image, PIL.ImageDraw, PIL.ImageFont import re import regex import re,string import rfc822, string import smtplib import string import StringIO Nothing really suspicious. Thanks, Paul
Re: [Zope] RE : Re: RE : Re: Frequent Zope crashes (Zope 2.9.8)
--On 17. Februar 2008 16:59:54 +0100 Paul Brettschneider [EMAIL PROTECTED] wrote: If I am informed correctly, only ZPsycopgDA contains C-code. The psycopg module is not built from source but installed via the Debian package repository. psycopg is partly written in C. Since you're using packages, try to compile psycopg yourself from the sources. If you're using a system python, try to setup your site with a Python source installation. -aj pgp2Wfg2TQzOa.pgp Description: PGP signature ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
