* GDB crashing because of Python
@ 2012-08-23 13:21 Kevin Pouget
2012-08-23 13:56 ` Tom Tromey
0 siblings, 1 reply; 10+ messages in thread
From: Kevin Pouget @ 2012-08-23 13:21 UTC (permalink / raw)
To: gdb
Hello,
I notice today a lot for GDB crash because of Python, am I the only one?
(I didn't refresh my git tree since a while, so it might not be
directly related to the last Python patches)
It's hard to tell exactly what cause it, but for instance I see repeatedly:
> SystemError: /builddir/build/BUILD/Python-2.7.3/Objects/listobject.c:178: bad argument to internal function
This one aborts() GDB
> Fatal Python error: GC object already tracked
from
> #2 0x0000003f2c4f7b3e in Py_FatalError (msg=msg@entry=
> 0x3f2c520ae8 "GC object already tracked")
> at /usr/src/debug/Python-2.7.3/Python/pythonrun.c:1685
> #3 0x0000003f2c4739cb in PyList_New (size=size@entry=0)
> at /usr/src/debug/Python-2.7.3/Objects/listobject.c:170
> #4 0x0000003f2c4f58a5 in PyArena_New ()
> at /usr/src/debug/Python-2.7.3/Python/pyarena.c:143
> #5 0x0000003f2c4f793a in PyRun_FileExFlags (...)
and this one raises a segfault:
> Program received signal SIGSEGV, Segmentation fault.
> PyObject_Malloc (nbytes=32)
> at /usr/src/debug/Python-2.7.3/Objects/obmalloc.c:784
> 784 if ((pool->freeblock = *(block **)bp) != NULL) {
from:
> #0 PyObject_Malloc (nbytes=32)
> at /usr/src/debug/Python-2.7.3/Objects/obmalloc.c:784
> #1 0x0000003f2c475291 in _PyLong_New (size=1)
> at /usr/src/debug/Python-2.7.3/Objects/longobject.c:76
> #2 0x0000003f2c479e9f in PyLong_FromUnsignedLongLong (
> ival=ival@entry=135084326)
> at /usr/src/debug/Python-2.7.3/Objects/longobject.c:883
> #3 0x00000000004df100 in frapy_pc (self=
> <gdb.Frame at remote 0x2c1d130>, args=<optimized out>)
> at ../../../git/gdb/gdb/python/py-frame.c:209
> #4 0x0000003f2c4dce36 in call_function (oparg=<optimized out>,
> pp_stack=0x7fff850c3638)
> at /usr/src/debug/Python-2.7.3/Python/ceval.c:4082
> #5 PyEval_EvalFrameEx (f=f@entry=
I'm on Fedora 17, x86_64, Python seems to be at version 2.7.3, gdb is
up to date against the trunk (7.5.50.20120823-cvs)
Cordially,
Kevin
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: GDB crashing because of Python
2012-08-23 13:21 GDB crashing because of Python Kevin Pouget
@ 2012-08-23 13:56 ` Tom Tromey
2012-08-23 14:30 ` Kevin Pouget
0 siblings, 1 reply; 10+ messages in thread
From: Tom Tromey @ 2012-08-23 13:56 UTC (permalink / raw)
To: Kevin Pouget; +Cc: gdb
>>>>> "Kevin" == Kevin Pouget <kevin.pouget@gmail.com> writes:
Kevin> I notice today a lot for GDB crash because of Python, am I the
Kevin> only one? (I didn't refresh my git tree since a while, so it
Kevin> might not be directly related to the last Python patches)
Kevin> It's hard to tell exactly what cause it, but for instance I see
Kevin> repeatedly:
[...]
I haven't seen it.
I updated from CVS just now, rebuilt, and ran the gdb.python tests
without any problems.
Kevin> I'm on Fedora 17, x86_64, Python seems to be at version 2.7.3, gdb is
Kevin> up to date against the trunk (7.5.50.20120823-cvs)
I'm still on Fedora 16. I wouldn't expect 17 to have particular
problems like this though.
What were you doing when you got these crashes? Is it something simple
that I could try? What happens if you run the gdb.python tests?
Tom
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: GDB crashing because of Python
2012-08-23 13:56 ` Tom Tromey
@ 2012-08-23 14:30 ` Kevin Pouget
2012-08-23 18:52 ` Tom Tromey
0 siblings, 1 reply; 10+ messages in thread
From: Kevin Pouget @ 2012-08-23 14:30 UTC (permalink / raw)
To: Tom Tromey; +Cc: gdb
[-- Attachment #1: Type: text/plain, Size: 2275 bytes --]
On Thu, Aug 23, 2012 at 3:55 PM, Tom Tromey <tromey@redhat.com> wrote:
>>>>>> "Kevin" == Kevin Pouget <kevin.pouget@gmail.com> writes:
>
> Kevin> I notice today a lot for GDB crash because of Python, am I the
> Kevin> only one? (I didn't refresh my git tree since a while, so it
> Kevin> might not be directly related to the last Python patches)
>
> Kevin> It's hard to tell exactly what cause it, but for instance I see
> Kevin> repeatedly:
> [...]
>
> I haven't seen it.
> I updated from CVS just now, rebuilt, and ran the gdb.python tests
> without any problems.
>
> Kevin> I'm on Fedora 17, x86_64, Python seems to be at version 2.7.3, gdb is
> Kevin> up to date against the trunk (7.5.50.20120823-cvs)
>
> I'm still on Fedora 16. I wouldn't expect 17 to have particular
> problems like this though.
>
> What were you doing when you got these crashes? Is it something simple
> that I could try? What happens if you run the gdb.python tests?
>
> Tom
Hello,
> What happens if you run the gdb.python tests?
unfortunately, the run 100% fine ...
> What were you doing when you got these crashes?
just "normal" things, I mean, running code which have been running
fine until today.
> SystemError: /builddir/build/BUILD/Python-2.7.3/Objects/listobject.c:178: bad argument to internal function
this one is triggered in the middle of a Breakpoint callback, so it
appears quite often
> Program received signal SIGSEGV, Segmentation fault.
> PyObject_Malloc (nbytes=32)
> at /usr/src/debug/Python-2.7.3/Objects/obmalloc.c:784
this one is when I want to attach gdb to another gdb instance (gdb2
--pid $(pidof gdb))
and finally:
> Fatal Python error: GC object already tracked
this one appears when I start the inferior execution, and start it again
I've attached the complete stack of this crash (from a third gdb!).
We can see that it crashed while auto-loading
"/usr/lib/debug/usr/bin/gdb-gdb.py", which is the original file from
Fedora gdb package.
I can also see that the stack contains "prompt_hook", I've seen another crash
which was mentioned this file [1], which deals with prompt customization.
It *might* be related, but I'm not sure at all.
Thanks,
Kevin
[1] : http://gitorious.org/misc-gdb-stuff/misc-gdb-stuff/blobs/master/misc_gdb/gaudy_prompt.py
[-- Attachment #2: stack.txt --]
[-- Type: text/plain, Size: 3717 bytes --]
(gdb) where
#0 0x0000003f19035925 in __GI_raise (sig=sig@entry=6)
at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1 0x0000003f190370d8 in __GI_abort () at abort.c:91
#2 0x0000003f2c4f7b3e in Py_FatalError (msg=msg@entry=
0x3f2c520ae8 "GC object already tracked")
at /usr/src/debug/Python-2.7.3/Python/pythonrun.c:1685
#3 0x0000003f2c4739cb in PyList_New (size=size@entry=0)
at /usr/src/debug/Python-2.7.3/Objects/listobject.c:170
#4 0x0000003f2c4f58a5 in PyArena_New ()
at /usr/src/debug/Python-2.7.3/Python/pyarena.c:143
#5 0x0000003f2c4f793a in PyRun_FileExFlags (fp=fp@entry=
0x478ec40, filename=filename@entry=
0x3d8f910 "/usr/lib/debug/usr/bin/gdb-gdb.py",
start=start@entry=257, globals=globals@entry=
{'GdbOutputFile': <classobj at remote 0x23d8460>, '__builtins__': <module at remote 0x7f0a6e5f4ad0>, '__file__': '\x00\x00\x00\x00/lib/deb\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00', 'GdbRemoveReadlineFinder': <classobj at remote 0x23d83f8>, 'init': <module at remote 0x23ff718>, '__package__': None, 'sys': <module at remote 0x7f0a6e5f4b78>, 'GdbOutputErrorFile': <classobj at remote 0x23d84c8>, 'gdb': <module at remote 0x23f5830>, 'prompt_hook': None, '__name__': '__main__', 'GdbSetPythonDirectory': <function at remote 0x23f2758>, 'os': <module at remote 0x7f0a6e5bacc8>, '__doc__': None},
locals=locals@entry=
{'GdbOutputFile': <classobj at remote 0x23d8460>, '__builtins__': <module at remote 0x7f0a6e5f4ad0>, '__file__': '\x00\x00\x00\x00/lib/deb\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00', 'GdbRemoveReadlineFinder': <classobj at remote 0x23d83f8>, 'init': <module at remote 0x23ff718>, '__package__': None, 'sys': <module at remote 0x7f0a6e5f4b78>, 'GdbOutputErrorFile': <classobj at remote 0x23d84c8>, 'gdb': <module at remote 0x23f5830>, 'prompt_hook': None, '__name__': '__main__', 'GdbSetPythonDirectory': <function at remote 0x23f2758>, 'os': <module at remote 0x7f0a6e5bacc8>, '__doc__': None},
closeit=closeit@entry=0, flags=flags@entry=0x0)
at /usr/src/debug/Python-2.7.3/Python/pythonrun.c:1335
#6 0x0000003f2c4f83ab in PyRun_SimpleFileExFlags (fp=fp@entry=
0x478ec40, filename=filename@entry=
0x3d8f910 "/usr/lib/debug/usr/bin/gdb-gdb.py",
closeit=closeit@entry=0, flags=flags@entry=0x0)
at /usr/src/debug/Python-2.7.3/Python/pythonrun.c:951
#7 0x00000000004d9b11 in python_run_simple_file (filename=
0x3d8f910 "/usr/lib/debug/usr/bin/gdb-gdb.py", file=
0x478ec40) at ../../../git/gdb/gdb/python/python.c:269
#8 source_python_script_for_objfile (objfile=0x26ed780, file=
0x478ec40, filename=
0x3d8f910 "/usr/lib/debug/usr/bin/gdb-gdb.py")
at ../../../git/gdb/gdb/python/python.c:1134
#9 0x000000000050b1cc in auto_load_objfile_script (
objfile=objfile@entry=0x26ed780, language=language@entry=
0x748390 <script_language_python>)
at ../../../git/gdb/gdb/auto-load.c:770
#10 0x00000000004da3df in gdbpy_load_auto_scripts_for_objfile (
objfile=0x26ed780)
at ../../../git/gdb/gdb/python/py-auto-load.c:233
#11 0x0000000000583d5d in captured_main (data=data@entry=
0x7fffe49b9d30) at ../../../git/gdb/gdb/main.c:964
#12 0x000000000058213e in catch_errors (func=func@entry=
0x583780 <captured_main>, func_args=func_args@entry=
0x7fffe49b9d30, errstring=errstring@entry=0x733ab2 "",
mask=mask@entry=6) at ../../../git/gdb/gdb/exceptions.c:546
#13 0x0000000000584794 in gdb_main (args=args@entry=
0x7fffe49b9d30) at ../../../git/gdb/gdb/main.c:1008
#14 0x000000000045894e in main (argc=<optimized out>,
argv=<optimized out>) at ../../../git/gdb/gdb/gdb.c:34
(gdb)
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: GDB crashing because of Python
2012-08-23 14:30 ` Kevin Pouget
@ 2012-08-23 18:52 ` Tom Tromey
2012-08-27 16:05 ` Kevin Pouget
0 siblings, 1 reply; 10+ messages in thread
From: Tom Tromey @ 2012-08-23 18:52 UTC (permalink / raw)
To: Kevin Pouget; +Cc: gdb
Kevin> I'm on Fedora 17, x86_64, Python seems to be at version 2.7.3, gdb is
Kevin> up to date against the trunk (7.5.50.20120823-cvs)
I installed F17 in a mock chroot and ran the latest gdb there.
This isn't an identical scenario due to possible kernel differences, but
I wouldn't expect those to matter.
>> Fatal Python error: GC object already tracked
Kevin> this one appears when I start the inferior execution, and start it again
I couldn't make it crash.
What happens if you run under valgrind?
When I do that, I see some output, but nothing that looks too serious
and/or new.
Tom
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: GDB crashing because of Python
2012-08-23 18:52 ` Tom Tromey
@ 2012-08-27 16:05 ` Kevin Pouget
2012-08-27 16:36 ` Tom Tromey
0 siblings, 1 reply; 10+ messages in thread
From: Kevin Pouget @ 2012-08-27 16:05 UTC (permalink / raw)
To: Tom Tromey; +Cc: gdb
On Thu, Aug 23, 2012 at 8:52 PM, Tom Tromey <tromey@redhat.com> wrote:
>
> Kevin> I'm on Fedora 17, x86_64, Python seems to be at version 2.7.3, gdb is
> Kevin> up to date against the trunk (7.5.50.20120823-cvs)
>
> I installed F17 in a mock chroot and ran the latest gdb there.
> This isn't an identical scenario due to possible kernel differences, but
> I wouldn't expect those to matter.
>
> >> Fatal Python error: GC object already tracked
>
> Kevin> this one appears when I start the inferior execution, and start it again
>
> I couldn't make it crash.
> What happens if you run under valgrind?
> When I do that, I see some output, but nothing that looks too serious
> and/or new.
>
> Tom
Hello,
so based on `git bisect`, it looks like the errors were introduced by
this commit:
--> SystemError:
/builddir/build/BUILD/Python-2.7.3/Objects/listobject.c:178: bad
argument to internal function
--> Fatal Python error: GC object already tracked
# http://sourceware.org/ml/gdb-patches/2012-08/msg00434.html
> commit 97143778fc8aceaca6895de13b93c88811402441
> Author: Tom Tromey <tromey@redhat.com>
> Date: Wed Aug 15 14:21:57 2012 +0000
> PR python/14387:
I'm not sure about what relevant information I can provide with
valgrind, so here is the complete log:
==29717== Memcheck, a memory error detector
==29717== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==29717== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==29717== Command: gdb-master --pid 26304 -ex quit
==29717==
GNU gdb (GDB) 7.5.50.20120815-cvs
[... gdb starts ...]
Attaching to process 26304
Reading symbols from /home/kevin/travail/i386/gdb-trunk.build/gdb/gdb...done.
==29719==
==29719== HEAP SUMMARY:
==29719== in use at exit: 18,910,812 bytes in 38,905 blocks
==29719== total heap usage: 174,966 allocs, 136,061 frees,
132,543,220 bytes allocated
==29719==
==29719== LEAK SUMMARY:
==29719== definitely lost: 5,598 bytes in 33 blocks
==29719== indirectly lost: 24 bytes in 1 blocks
==29719== possibly lost: 1,819,580 bytes in 10,752 blocks
==29719== still reachable: 17,085,610 bytes in 28,119 blocks
==29719== suppressed: 0 bytes in 0 blocks
==29719== Rerun with --leak-check=full to see details of leaked memory
==29719==
==29719== For counts of detected and suppressed errors, rerun with: -v
==29719== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2)
Reading symbols from /lib64/libdl.so.2...Reading symbols from
/usr/lib/debug/lib64/libdl-2.15.so.debug...
[... symbols loading ...]
==29717== Invalid read of size 8
==29717== at 0x501076: objfpy_get_printers (py-objfile.c:88)
==29717== by 0x502ACD: find_pretty_printer_from_objfiles
(py-prettyprint.c:114)
==29717== by 0x502D75: find_pretty_printer (py-prettyprint.c:190)
==29717== by 0x503EEE: apply_val_pretty_printer (py-prettyprint.c:719)
==29717== by 0x5819E8: val_print (valprint.c:727)
==29717== by 0x581CAD: common_val_print (valprint.c:806)
==29717== by 0x5C33DA: print_frame_arg (stack.c:282)
==29717== by 0x5C3F5D: print_frame_args (stack.c:647)
==29717== by 0x5C4E72: print_frame (stack.c:1171)
==29717== by 0x5C44A9: print_frame_info (stack.c:826)
==29717== by 0x5C2F4E: print_stack_frame (stack.c:165)
==29717== by 0x5BCB09: normal_stop (infrun.c:6053)
==29717== Address 0xbf8d638 is 24 bytes inside a block of size 240 free'd
==29717== at 0x4A079AE: free (vg_replace_malloc.c:427)
==29717== by 0x6F9D9C: xfree (common-utils.c:107)
==29717== by 0x5CAFAD: catcher_pop (exceptions.c:123)
==29717== by 0x5CB03D: exceptions_state_mc (exceptions.c:149)
==29717== by 0x5CB1C8: exceptions_state_mc_action_iter (exceptions.c:210)
==29717== by 0x6CEE1B: get_frame_pc_if_available (frame.c:1990)
==29717== by 0x6CEBD2: get_prev_frame (frame.c:1891)
==29717== by 0x6594F2: value_of_dwarf_reg_entry (dwarf2loc.c:1238)
==29717== by 0x65969B: value_of_dwarf_block_entry (dwarf2loc.c:1300)
==29717== by 0x65F125: loclist_read_variable_at_entry (dwarf2loc.c:4009)
==29717== by 0x5C3632: read_frame_arg (stack.c:335)
==29717== by 0x5C3F3F: print_frame_args (stack.c:644)
==29717==
==29717==
==29717== Process terminating with default action of signal 11 (SIGSEGV)
==29717== Bad permissions for mapped region at address 0x456EF0
==29717== at 0x501081: objfpy_get_printers (py-objfile.c:88)
==29717== by 0x502ACD: find_pretty_printer_from_objfiles
(py-prettyprint.c:114)
==29717== by 0x502D75: find_pretty_printer (py-prettyprint.c:190)
==29717== by 0x503EEE: apply_val_pretty_printer (py-prettyprint.c:719)
==29717== by 0x5819E8: val_print (valprint.c:727)
==29717== by 0x581CAD: common_val_print (valprint.c:806)
==29717== by 0x5C33DA: print_frame_arg (stack.c:282)
==29717== by 0x5C3F5D: print_frame_args (stack.c:647)
==29717== by 0x5C4E72: print_frame (stack.c:1171)
==29717== by 0x5C44A9: print_frame_info (stack.c:826)
==29717== by 0x5C2F4E: print_stack_frame (stack.c:165)
==29717== by 0x5BCB09: normal_stop (infrun.c:6053)
0x0000003f190e8b84 in __GI___poll (==29717==
==29717== HEAP SUMMARY:
==29717== in use at exit: 37,857,799 bytes in 42,044 blocks
==29717== total heap usage: 849,325 allocs, 807,281 frees,
807,618,669 bytes allocated
==29717==
==29717== LEAK SUMMARY:
==29717== definitely lost: 5,598 bytes in 33 blocks
==29717== indirectly lost: 24 bytes in 1 blocks
==29717== possibly lost: 1,839,074 bytes in 10,983 blocks
==29717== still reachable: 36,013,103 bytes in 31,027 blocks
==29717== suppressed: 0 bytes in 0 blocks
==29717== Rerun with --leak-check=full to see details of leaked memory
==29717==
==29717== For counts of detected and suppressed errors, rerun with: -v
==29717== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 2)
[1] 29717 segmentation fault valgrind gdb-master --pid 26304 -ex quit
Thanks for your help,
Kevin
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: GDB crashing because of Python
2012-08-27 16:05 ` Kevin Pouget
@ 2012-08-27 16:36 ` Tom Tromey
2012-08-27 16:39 ` Tom Tromey
2012-08-28 19:45 ` Tom Tromey
0 siblings, 2 replies; 10+ messages in thread
From: Tom Tromey @ 2012-08-27 16:36 UTC (permalink / raw)
To: Kevin Pouget; +Cc: gdb
>>>>> "Kevin" == Kevin Pouget <kevin.pouget@gmail.com> writes:
Kevin> so based on `git bisect`, it looks like the errors were introduced by
Kevin> this commit:
Can you please try the appended patch?
I think the bug here is that this code assumes that
objfile_to_objfile_object returns a new reference, but in fact it does
not.
While looking at this I think I found even more reference counting bugs.
Despair.
Tom
diff --git a/gdb/python/py-newobjfileevent.c b/gdb/python/py-newobjfileevent.c
index 3059ae4..d014be6 100644
--- a/gdb/python/py-newobjfileevent.c
+++ b/gdb/python/py-newobjfileevent.c
@@ -25,7 +25,7 @@ static PyObject *
create_new_objfile_event_object (struct objfile *objfile)
{
PyObject *objfile_event;
- PyObject *py_objfile = NULL;
+ PyObject *py_objfile;
objfile_event = create_event_object (&new_objfile_event_object_type);
if (!objfile_event)
@@ -36,12 +36,10 @@ create_new_objfile_event_object (struct objfile *objfile)
"new_objfile",
py_objfile) < 0)
goto fail;
- Py_DECREF (py_objfile);
return objfile_event;
fail:
- Py_XDECREF (py_objfile);
Py_XDECREF (objfile_event);
return NULL;
}
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: GDB crashing because of Python
2012-08-27 16:36 ` Tom Tromey
@ 2012-08-27 16:39 ` Tom Tromey
2012-08-28 19:45 ` Tom Tromey
1 sibling, 0 replies; 10+ messages in thread
From: Tom Tromey @ 2012-08-27 16:39 UTC (permalink / raw)
To: Kevin Pouget; +Cc: gdb
Tom> While looking at this I think I found even more reference counting bugs.
I thought perhaps the weird logic in inferior_to_inferior_object would
cause problems. But it turns out that the struct inferior doesn't own a
reference, and infpy_dealloc solves the problem I thought I was seeing.
Tom
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: GDB crashing because of Python
2012-08-27 16:36 ` Tom Tromey
2012-08-27 16:39 ` Tom Tromey
@ 2012-08-28 19:45 ` Tom Tromey
2012-08-29 8:14 ` Kevin Pouget
1 sibling, 1 reply; 10+ messages in thread
From: Tom Tromey @ 2012-08-28 19:45 UTC (permalink / raw)
To: Kevin Pouget; +Cc: gdb
Kevin> so based on `git bisect`, it looks like the errors were introduced by
Kevin> this commit:
Tom> Can you please try the appended patch?
I spent some time today trying to make a robust test case for this.
I can see the error clearly with valgrind, but I can't make it crash.
Printing the Objfile reference counts "works" but it seems to not be
very robust -- in the failing case the count appears to be 12 on my
machine, but of course this is just a fluke, and it could well be
anything.
-lmcheck unfortunately doesn't help, because Python is typically built
using its own allocator. It would be nice if we could disable this for
the test suite -- it is automatically disabled under valgrind (under
some typical configurations), so it could be done cheaply -- but this
isn't available.
Anyway, I'm going to write a ChangeLog and send it to the patch list.
Tom
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: GDB crashing because of Python
2012-08-28 19:45 ` Tom Tromey
@ 2012-08-29 8:14 ` Kevin Pouget
2012-09-06 19:27 ` Tom Tromey
0 siblings, 1 reply; 10+ messages in thread
From: Kevin Pouget @ 2012-08-29 8:14 UTC (permalink / raw)
To: Tom Tromey; +Cc: gdb
On Tue, Aug 28, 2012 at 9:44 PM, Tom Tromey <tromey@redhat.com> wrote:
> Kevin> so based on `git bisect`, it looks like the errors were introduced by
> Kevin> this commit:
>
> Tom> Can you please try the appended patch?
>
> I spent some time today trying to make a robust test case for this.
> I can see the error clearly with valgrind, but I can't make it crash.
> Printing the Objfile reference counts "works" but it seems to not be
> very robust -- in the failing case the count appears to be 12 on my
> machine, but of course this is just a fluke, and it could well be
> anything.
>
> -lmcheck unfortunately doesn't help, because Python is typically built
> using its own allocator. It would be nice if we could disable this for
> the test suite -- it is automatically disabled under valgrind (under
> some typical configurations), so it could be done cheaply -- but this
> isn't available.
>
> Anyway, I'm going to write a ChangeLog and send it to the patch list.
>
> Tom
Hello,
Thanks, the patch of the previous email seems to resolve all the bugs
I detailed!
I was thinking that it's strange that I'm the only one seeing this bug
from a file *I* committed ... but maybe I'm the only one actually
using the feature! Did you try to register a Python handler to
`gdb.events.new_objfile` to trigger the bug? (gdb/trunk doesn't not
crash anymore if I remove the connection from my init files)
Cordially,
Kevin
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: GDB crashing because of Python
2012-08-29 8:14 ` Kevin Pouget
@ 2012-09-06 19:27 ` Tom Tromey
0 siblings, 0 replies; 10+ messages in thread
From: Tom Tromey @ 2012-09-06 19:27 UTC (permalink / raw)
To: Kevin Pouget; +Cc: gdb
>>>>> "Kevin" == Kevin Pouget <kevin.pouget@gmail.com> writes:
Kevin> Thanks, the patch of the previous email seems to resolve all the bugs
Kevin> I detailed!
I'm going to check it in today.
Kevin> I was thinking that it's strange that I'm the only one seeing this bug
Kevin> from a file *I* committed ... but maybe I'm the only one actually
Kevin> using the feature! Did you try to register a Python handler to
Kevin> `gdb.events.new_objfile` to trigger the bug? (gdb/trunk doesn't not
Kevin> crash anymore if I remove the connection from my init files)
It is a regression due to an earlier, but post-7.5, patch.
Tom
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2012-09-06 19:27 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-08-23 13:21 GDB crashing because of Python Kevin Pouget
2012-08-23 13:56 ` Tom Tromey
2012-08-23 14:30 ` Kevin Pouget
2012-08-23 18:52 ` Tom Tromey
2012-08-27 16:05 ` Kevin Pouget
2012-08-27 16:36 ` Tom Tromey
2012-08-27 16:39 ` Tom Tromey
2012-08-28 19:45 ` Tom Tromey
2012-08-29 8:14 ` Kevin Pouget
2012-09-06 19:27 ` Tom Tromey
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).