Stuck with a strange core (C code) -- Please help.

[SZ]

Hi,

I've hit this core multiple times when running an application (coded
in C)
running on BSD OS. Using gdb getting to the core, it shows:

.....
(gdb) bt
#0 0x8541fa3 in mTimerQUnlink (t=0xd7f5a51, head=0x8fec13c)
at ../../rsvp/eventwheel.c:16 0
#1 0x854288d in mTimerInsert (t=0xd7f5a51,
callback=0x873c e88 <retran_unacked >, param=0xd7f5a01 , time=50,
type=1)
at ../../rsvp/eventwheel.c:53 6
#2 0x873d266 in retran_unacked (unacked_cb=0xd 7f5a00)
at ../../rsvp/rrrmsgi3.c:1425
....
Notice that the address (0xd7f5a00) of "unacketd_c b" (pointer of a
struct)
at level 2 is passed to the function of mTimerInsert as "param". But
"param" becomes 0xd7f5a01 (which added a "1" at the end). All the
subsequent processing is based on this wrong address causing the core.
The application is compiled with gcc with "-O2" along with some other
options.

I know address here can not start with ood number. This is a weired
problem. The stack shown with bt command in gdb seems to be complete.

Anyone knows what direction should I go with for the trouble shooting?

Thanks a lot

-SZ

[SZ]

I think the problem is found:

there is a function, which is a couple of layers down from
rrr_resend_pack et(), got something like a[i]++ with a[] defined
as local and i uninitialized. This cause it radmomly pick up
a place (in stack) and increment it.

Geez, I hope there is a better systematic way to catch memory
violation like this.

Thanks everyone for your help.

-SZ

[Richard Bos]

sh******@yahoo. com (SZ) wrote:

there is a function, which is a couple of layers down from
rrr_resend_pack et(), got something like a[i]++ with a[] defined
as local and i uninitialized. This cause it radmomly pick up
a place (in stack) and increment it.

Geez, I hope there is a better systematic way to catch memory
violation like this.

Well, in this case, a good way to catch it would probably have been not
to rely on a memory tracker and your OS alone, but to turn up the
warning level on your compiler until the knob nearly comes off, and then
turning it one stop back. All compilers I've ever worked with were
capable of telling you that you're using an uninitialised variable,
which would've caught this bug before it got out.
(The reason for the one stop back, btw, is that most compilers' "really
anal-retentive" settings are _too_ strict and pick up things that are,
e.g., only a problem if you're compiling for an embedded system, which
you probably aren't; at least one edition of one compiler famously
complains about its own system headers when set to the highest warning
level. Nevertheless, below the extreme, stricter warnings is better.)

Richard