RE: [Zope] Auto restart (at Zope's own initiative !!!)
That doesn't (to me, at least) explain why it never crashes except under the one case, nor why I was told by zope.com that this had been seen before with RDBMS extensions. I'm entirely open to the idea of improper memory or reference management, but I'd suspect that, since the extension is a constant, that crashes would appear in all cases. That not being the case, I suspect the environment that's setting up the thread -- Python, in this case. If it *is* a matter of the extension itself, then an example of how it should properly be done would be in order. I've not seen any. ---------- Keith J. Farmer kfarmer@thuban.org http://www.thuban.org -----Original Message----- From: Chris McDonough [mailto:chrism@zope.com] Sent: Monday, January 28, 2002 16:00 I don't think it has anything to do with C extensions in general (Zope has lots of those, and for the most part, we think they work OK). I think it has to do with particular C extensions that are coded improperly and thus cause segfaults. A "usual suspect" in those cases that there would be improper memory and/or reference management.
Keith J. Farmer wrote:
That doesn't (to me, at least) explain why it never crashes except under the one case, nor why I was told by zope.com that this had been seen before with RDBMS extensions.
Sorry, I actually didn't understand what you were saying within your message until now! I can't explain that behavior. Note that at this point you've isolated it so that it really has nothing to do with Zope It might be time to ask this question on the Python maillist (unless you've already done that).
I'm entirely open to the idea of improper memory or reference
management, but I'd suspect that, since the extension is a constant, that crashes would appear in all cases. That not being the case, I suspect the environment that's setting up the thread -- Python, in this case.
It's possible. But good programmers suspect everything before they suspect their tools, so I'd certainly keep an open mind. ;-)
If it *is* a matter of the extension itself, then an example of how it should properly be done would be in order. I've not seen any.
"Extending and Embedding Python" would be the right place to start. http://www.python.org/doc/current/ext/ext.html. Additionally, it may be useful to ask questions on the comp.lang.python newsgroup. Now that you've narrowed it down to a reproducible test case, I would hope somebody there could help you solve the mystery. Sorry I can't be more helpful! - C
Keith J. Farmer writes:
... application crashes in threaded mode, works in non-threaded mode ... If it *is* a matter of the extension itself, then an example of how it should properly be done would be in order. I've not seen any. Threaded execution poses *much* higher requirements on application code than non-threaded one.
Suppose, you have the following code: x= malloc(...) ... free(x) This is good in non-threaded code. It can lead to desaster when "x" is accessed concurrently in different threads, e.g. because it is a global variable or an object attribute used in two threads. Other desaster scenario: "Py_DECREF/Py_INCREF" concurrently in two different threads for the same object. The result is undefined, leading to potentially lost references and finally memory corruption. As a consequence: after "...AllowThreads..." you must not call any Python function that modifies reference counts. Almost all Python functions do that. Myriads of other (not necessary Python specific) scenarios for desaster exist... Dieter
participants (3)
-
Chris McDonough -
Dieter Maurer -
Keith J. Farmer