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
> %s:%d\n",__FI
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 wrappe
>>> 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
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 even
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
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 dea
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 in
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
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 comple
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 n
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 s
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
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
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 might be able to glance something by
> seeing what objects
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 wrot
Leonardo Rochael Almeida wrote:
> On Wed, 2002-03-13 at 13:04, Shane Hathaway wrote:
>
>>I just found out about something that might help. If you compiled
>>against the GNU C library, you can set the environment variable
>>MALLOC_CHECK_ to 1 to get malloc usage warnings printed to stderr, or
On Wed, 2002-03-13 at 12:40, Leonardo Rochael Almeida wrote:
> Also, how about turning on some flags in
> gc.seg_debug()? Do you think we might be able to glance something by
> seeing what objects where logged as freed or by storing them in
> gc.garbage?
Forgot to mention, gc module documentation
On Wed, 2002-03-13 at 13:04, Shane Hathaway wrote:
> I just found out about something that might help. If you compiled
> against the GNU C library, you can set the environment variable
> MALLOC_CHECK_ to 1 to get malloc usage warnings printed to stderr, or
> set it to 2 to cause an abort() as
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
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
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
> a
And so it continues...
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 pythonScripts inside ZClasses).
But it s
22 matches
Mail list logo
