I've applied both patches, however I've changed the incref part a
little. Now it reads:
#define Py_INCREF(op) ((op)-ob_refcnt 0 ? (op)-ob_refcnt++ :
fprintf(stderr,Eeek! Increfing an object from refct 0 at
%s:%d\n,__FILE__,__LINE__), (op)-ob_refcnt++)
It's all in one line if my MUA wrapped it.
On Mon, 2002-03-18 at 17:44, Leonardo Rochael Almeida wrote:
I've applied both patches, however I've changed the incref part a
little. Now it reads:
#define Py_INCREF(op) ((op)-ob_refcnt 0 ? (op)-ob_refcnt++ :
fprintf(stderr,Eeek! Increfing an object from refct 0 at
Leonardo Rochael Almeida wrote:
On Wed, 2002-03-13 at 21:30, Matthew T. Kromer wrote:
On Wednesday, March 13, 2002, at 10:40 AM, Leonardo Rochael Almeida
wrote:
What about patching Python to report the freed objects like you
mentioned on IRC? Also, how about turning on some flags in
5On Thu, 2002-03-14 at 13:28, Matthew T. Kromer wrote:
OK, I'm attaching a patch to Python's Modules/gcmodule.c which should
set a trap for where the garbage collector trips over bad data; this
will grab the bad data and send it to stderr so I can build a better trap.
I'm on it. Will send
Don't know if this helps, but the last three segfaults I have seen were
right after someone logs in, during loading /manage.
Zope-2.5.0 Win32 binary on Win2k. The pop-up referenced the same
instruction 0x1e13490a at the same memory address 0x005c all
three times, saying 'memory could not
Leonardo Rochael Almeida writes:
In any event, Martijn Jacobs (a.k.a. instability case #3 :-) sees his
crashes in pure dtml methods, which could mean that PythonScripts are
inocent in this case... or not, since the segfault hits inside the gc,
which might be collecting something
Dieter Maurer wrote:
Leonardo Rochael Almeida writes:
In any event, Martijn Jacobs (a.k.a. instability case #3 :-) sees his
crashes in pure dtml methods, which could mean that PythonScripts are
inocent in this case... or not, since the segfault hits inside the gc,
which might be
On Thu, 2002-03-14 at 17:17, Dieter Maurer wrote:
Leonardo Rochael Almeida writes:
In any event, Martijn Jacobs (a.k.a. instability case #3 :-) sees his
crashes in pure dtml methods, which could mean that PythonScripts are
inocent in this case... or not, since the segfault hits inside
Attached is another diagnostic patch which you might apply to Python.
If you apply this patch, you WILL need to rebuild Zope to include it.
What it will do is complain to stderr if an object is INCREF'd from
refcount 0. It also silences the complaint for the one area which I
know revives
Matthew T. Kromer wrote:
Attached is another diagnostic patch which you might apply to Python.
If you apply this patch, you WILL need to rebuild Zope to include it.
What it will do is complain to stderr if an object is INCREF'd from
refcount 0. It also silences the complaint for the one
Hi Matt,
I'll wait for the patch where you also silence the dead-raising area in
ExtensionClass.
What if, instead of detecting this situation, we try to detect if the
incref is happening without the interpreter lock held? increfs and
decrefs shouldn't be happening freely and simultaneously
Dieter Maurer wrote
Just a wild guess: is the GC guaranteed to be thread safe?
Yep.
The GC is _almost_ certainly not the problem here - it's just that the
GC is the poor bunny that has to walk through the objects in memory. So
when something's been mangled, the GC is the thing that falls
On Tuesday, March 12, 2002, at 05:08 PM, Leonardo Rochael Almeida wrote:
Matthew, thanks for taking the time to gdb the beast with me. Did you
come up with any instrumentation I should add to Python or Zope to get
what it is that Python is trying to resease twice? If you want, I can
On Wed, 2002-03-13 at 09:09, Matthew T. Kromer wrote:
On Tuesday, March 12, 2002, at 05:08 PM, Leonardo Rochael Almeida wrote:
Matthew, thanks for taking the time to gdb the beast with me. Did you
come up with any instrumentation I should add to Python or Zope to get
what it is that
Leonardo Rochael Almeida wrote:
Well, I have the energy, I just don't know where to start. But it's
beginning to look like I'll just have to roll up my sleeves and dive in
C code to hunt this beast down. And to think that I'd chosen Python as
my official programming language to avoid just
I set MALLOC_CHECK_ to 1 and it said it was using the malloc debug
hooks, but didn't report anything else before the crashes, so no point
in setting it to 2...
On Wed, 2002-03-13 at 13:49, Shane Hathaway wrote:
Leonardo Rochael Almeida wrote:
On Wed, 2002-03-13 at 13:04, Shane Hathaway wrote:
On Wed, 2002-03-13 at 21:30, Matthew T. Kromer wrote:
On Wednesday, March 13, 2002, at 10:40 AM, Leonardo Rochael Almeida
wrote:
What about patching Python to report the freed objects like you
mentioned on IRC? Also, how about turning on some flags in
gc.seg_debug()? Do you think we
narrator voice=koshAnd so it continues.../narrator
I've finally recompiled all pythonScripts (all scripts and ZCatalog
tricks I tried before didn't know how to get the PythonScripts inside
the ZClasses. BTW, if anyone is interested, I can send you the scripts I
used to recompile all
18 matches
Mail list logo
