bad dynamic mem access in final.c

Robert Lipe
Sun Feb 27 21:09:00 GMT 2000

I just tried a bootstrap with electric fence.  It triggered on a naughty
access that I pray is the source of much recent weirdness for me. The
host is i686-sco-sco3.2v5.0.5 and the test case is bootstrapping.  The
file being compiled is libgcc2.c and the specific entry is __fixunsdfdi.
Strangely, I can't get electric fence to trigger this case on rh6.1,
but if I breakpoint at the key addresses, I can see the same thing is

shorten_branches computes max_uid as 218 and then calls xcalloc to get
space for 218 ints and calls it "insn_addresses".

So later, final() comes along and loops over the available insns

	 for (insn = NEXT_INSN (first); insn;)
		insn_current_address = insn_addresses[INSN_UID (insn)];

Boom!  We just walked past the end of insn_addresses.  Interestingly,
it computes max_uid to be 219 and that is the value of INSN_UID(insn)
in the evaluated expression that causes grief.  It's not clear, but I
suspect this is an "off by two" error and not an "off by one".

I don't know which is right.  I don't know why they're different.  I
don't know if it should be reallocating/copying something in here.  But
my gut tells me this is wrong somehow.

If there additional information I can provide, please let me know.   I hope
the resolution to this problem gets me back into three-stage-land.


More information about the Gcc mailing list