Re: [Zope-dev] recipe for trapping SIGSEGV and SIGILL signals on solaris
Matt - Well, your patch seems fine in our testing environment. Unfortunately, we do not see any restarts in the testing environment ... always in production. I had to rebuild our entire software base because we are using other products that use extensions class and they are not included under the main zope installation. It caused a bus error the first time (with only running wo_pcgi.py). As I mentioned in my prior e-mail, I modified the patch slightly to exactly match the struct in Python's object.h. Please review this patch. I will apply the patch in production tomorrow morning, 12/13, (Japan Standard Time or GMT+9) and monitor the system. If zope does not restart during the day, then I think you have fixed the problem. I'm using Zope 2.4.3 and Python 2.1.1 with pymalloc disabled on the solaris platform. thanks and regards, - joe n. p.s. I looked **briefly** at the Zope 2.5 source and this patch will not be compatible since there doesn't seem to be a standard among the different extension classes on whether to include or not include the COUNT_ALLOCS define. The cAccessControl class seems to be the exception. *** ExtensionClass.h.bak Fri Nov 16 10:37:11 2001 --- ExtensionClass.h Wed Dec 12 15:10:03 2001 *************** *** 136,154 **** PySequenceMethods *tp_as_sequence; PyMappingMethods *tp_as_mapping; ! /* More standard operations (at end for binary compatibility) */ hashfunc tp_hash; ternaryfunc tp_call; reprfunc tp_str; getattrofunc tp_getattro; setattrofunc tp_setattro; ! /* Space for future expansion */ ! long tp_xxx3; ! long tp_xxx4; char *tp_doc; /* Documentation string */ #ifdef COUNT_ALLOCS /* these must be last */ int tp_alloc; --- 136,169 ---- PySequenceMethods *tp_as_sequence; PyMappingMethods *tp_as_mapping; ! /* More standard operations (here for binary compatibility) */ hashfunc tp_hash; ternaryfunc tp_call; reprfunc tp_str; getattrofunc tp_getattro; setattrofunc tp_setattro; ! ! /* Functions to access object as input/output buffer */ ! PyBufferProcs *tp_as_buffer; ! ! /* Flags to define presence of optional/expanded features */ ! long tp_flags; char *tp_doc; /* Documentation string */ + /* call function for all accessible objects */ + traverseproc tp_traverse; + + /* delete references to contained objects */ + inquiry tp_clear; + + /* rich comparisons */ + richcmpfunc tp_richcompare; + + /* weak reference enabler */ + long tp_weaklistoffset; + #ifdef COUNT_ALLOCS /* these must be last */ int tp_alloc; *************** *** 302,308 **** { PyExtensionClassCAPI->Export(D,N,&T); } /* Convert a method list to a method chain. */ ! #define METHOD_CHAIN(DEF) { DEF, NULL } /* The following macro checks whether a type is an extension class: */ #define PyExtensionClass_Check(TYPE) \ --- 317,330 ---- { PyExtensionClassCAPI->Export(D,N,&T); } /* Convert a method list to a method chain. */ ! /* MTK -- make it pad the type structure out -- presumes only use is in ! ** type structure initialization ! */ ! #ifdef COUNT_ALLOCS ! #define METHOD_CHAIN(DEF) 0,0,0,0,0,0,0,0,{ DEF, NULL } ! #else ! #define METHOD_CHAIN(DEF) 0,0,0,0,{ DEF, NULL } ! #endif /* The following macro checks whether a type is an extension class: */ #define PyExtensionClass_Check(TYPE) \ *************** *** 336,342 **** #define PURE_MIXIN_CLASS(NAME,DOC,METHODS) \ static PyExtensionClass NAME ## Type = { PyObject_HEAD_INIT(NULL) \ 0, # NAME, sizeof(PyPureMixinObject), 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, \ ! 0, 0, 0, 0, 0, 0, 0, DOC, {METHODS, NULL}, \ EXTENSIONCLASS_BASICNEW_FLAG} /* The following macros provide limited access to extension-class --- 358,364 ---- #define PURE_MIXIN_CLASS(NAME,DOC,METHODS) \ static PyExtensionClass NAME ## Type = { PyObject_HEAD_INIT(NULL) \ 0, # NAME, sizeof(PyPureMixinObject), 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, \ ! 0, 0, 0, 0, 0, 0, 0, DOC, METHOD_CHAIN(METHODS), \ EXTENSIONCLASS_BASICNEW_FLAG} /* The following macros provide limited access to extension-class
Joseph Wayne Norton wrote:
Matt -
Well, your patch seems fine in our testing environment. Unfortunately, we do not see any restarts in the testing environment ... always in production. I had to rebuild our entire software base because we are using other products that use extensions class and they are not included under the main zope installation. It caused a bus error the first time (with only running wo_pcgi.py).
As I mentioned in my prior e-mail, I modified the patch slightly to exactly match the struct in Python's object.h. Please review this patch. I will apply the patch in production tomorrow morning, 12/13, (Japan Standard Time or GMT+9) and monitor the system. If zope does not restart during the day, then I think you have fixed the problem.
I'm using Zope 2.4.3 and Python 2.1.1 with pymalloc disabled on the solaris platform.
thanks and regards,
- joe n.
p.s. I looked **briefly** at the Zope 2.5 source and this patch will not be compatible since there doesn't seem to be a standard among the different extension classes on whether to include or not include the COUNT_ALLOCS define. The cAccessControl class seems to be the exception.
My fingers and toes are crossed for you ;) I've actually built 2.5 with the modified extensionclass.h and it seems to build OK and it runs and passes all of its unit tests. Thats not proof one way or another, but... Sorry our turnaround times are so laggy; thats the downside of diagnosing a problem on the other side of the globe.
participants (2)
-
Joseph Wayne Norton -
Matthew T. Kromer