Bug 205757 - Setting a breakpoint changes program data
Setting a breakpoint changes program data
Product: Fedora
Classification: Fedora
Component: gdb (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Elena Zannoni
Depends On:
  Show dependency treegraph
Reported: 2006-09-08 08:22 EDT by Stefan Ring
Modified: 2007-11-30 17:11 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-09-14 03:52:07 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Stefan Ring 2006-09-08 08:22:41 EDT
Description of problem:

A program my company is developing stopped working all of a sudden after some
unrelated changes. Inside the Py_InitializeEx() call, the following assertion
pops up every time.

Objects/object.c:42: _Py_AddToAllObjects: Assertion `(op->_ob_prev == ((void
*)0)) == (op->_ob_next == ((void *)0))' failed.

So I started investigating but didn't get very far because of an annoying
problem in gdb. Notice how _Py_NoneStruct._ob_next changes in the following

(gdb) tb main
Breakpoint 2 at 0x805ccf0: file VTGA_SRV/unixmain.cpp, line 460.
(gdb) r
main (argc=-1079169704, argv=0xd9c724) at VTGA_SRV/unixmain.cpp:460
(gdb) p _Py_NoneStruct 
$1 = {_ob_next = 0x0, _ob_prev = 0x0, ob_refcnt = 1, ob_type = 0xa78ac0}
(gdb) br bltinmodule.c:2196
Breakpoint 3 at 0x9edefb: file Python/bltinmodule.c, line 2196.
(gdb) p _Py_NoneStruct 
$2 = {_ob_next = 0x19, _ob_prev = 0x0, ob_refcnt = 1, ob_type = 0xa78ac0}

Version-Release number of selected component (if applicable):

Stock FC5 installation, "yum update" current as of last week
g++ 4.1.1, custom built python 2.4.3 (--with-pydebug) & boost_python

How reproducible:

Unfortunately, I don't have enough time at the moment to really find out how to
reproduce this.

Actual results:

program data changed after setting breakpoint

Expected results:

no change in program data

Additional info:

If anyone cares about this bug, I'm willing to help. But I won't invest hours
now trying to make this reproducible if noone bothers to do anything about it

It might be related to the combination gcc 4.x and dwarf-2. Our code is normally
developed on an x86_64 server where we also use FC5 but GCC 3.4.6 because
debugging was impossible on this platform with gcc 4 and dwarf-2. I filed some
bug reports because of this several months ago, alas apparently they keep
getting ignored.
Comment 1 Jan Kratochvil 2006-09-10 14:42:08 EDT
I would be interested for reproducibility although primarily for the gcc-4.x
issues. As your "argc" in the dump is corrupted I assume your stack frames got
corrupt and so their decoding (appropriately) failed - the cause of the changes.

Sorry for your STABS Bug 187789, it is a valid bugreport, just AFAIK the STABS
format use by FC/RH is only marginal.
Comment 2 Stefan Ring 2006-09-14 03:52:07 EDT
Unfortunately I have not been able to reproduce this on a freshly installed FC5.
Neither the python assertion nor the gdb problem. Let's just call it your
average anomaly caused by cosmic rays or whatever ;)

BTW, I wouldn't want to use STABS if a DWARF linker run would complete in a
reasonable timeframe... (see Bug 187795)

Note You need to log in before you can comment on or make changes to this bug.