This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: bad dynamic mem access in final.c
- To: Jeffrey A Law <law at cygnus dot com>
- Subject: Re: bad dynamic mem access in final.c
- From: Robert Lipe <robertl at sco dot com>
- Date: Tue, 18 Apr 2000 22:14:45 -0500
- Cc: gcc at gcc dot gnu dot org
- References: <20000227230730.A1661@rjlhome.sco.com> <8693.955658564@upchuck>
re: http://gcc.gnu.org/ml/gcc/2000-02/msg00725.html
Jeffrey A Law wrote:
>
> In message <20000227230730.A1661@rjlhome.sco.com>you write:
> > 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".
>
> You might be able to track this down by putting a breakpoint in
> make_insn_raw or one of its related routines after the computation]
> of max_uid. From there you should be able to track down what
I'll try that as insomnia permits.
> Of course, this is an old message, so maybe you (or someone else) has
> already fixed this problem.
Nope. It's still there. I just verified it with the UW7 malloc
instrumentation.
Thanx for the response, Jeff.
RJL