[tlbuild] TeX Live 2010 Regression Test Failure on OpenBSD

Peter Breitenlohner peb at mppmu.mpg.de
Tue Jun 15 11:22:35 CEST 2010


On Mon, 14 Jun 2010, Karl Berry wrote:

> Hi Edd,
>
>    > I ran GDB on this and here is the backtrace:
>    Did this get noticed?
>
> It got noticed but I remain stymied.  Setting up an openbsd
> environment will take more time.
>
> So ... meanwhile: if you compiled with optimization, try turning that
> off.  If you haven't tried on a different system (x86 instead of
> amd64?), or with a different compiler, that could be worth doing.
>
> Finally, given this line:
> 576         planes[c/PLANE][c%PLANE]->tag = tag;
>
> Presumably it is dereferencing unallocated memory, but it's far from
> clear what that is or how it happened.  How about printing all the
> relevant values, e.g.,
> p c
> p c/0x10000
> p planes[$]
> p c%0x10000
> p planes[c/0x10000][c%0x10000]
> p *$
>
> And see where in there we run into the problem.  No idea if the above
> will tell us, but it's somewhere to start.

Hi Edd, Karl,

looking at the code, I'd guess that some data (pointers?) have been
overwritten.  But why?

According to the code all this is triggered by OCherokee.ovp l.150
   (LABEL H 13E4)
where 0x13e4 is 5092:

pl-parser.y l.256
   OneLigKernEntry :
     LABEL NUMBER
       { set_label_command($2.yint); }

ligkern_routines.c l.71
   check_char_tag(c);
   set_char_tag(c, TAG_LIG);

char_routines.c l.567ff

both check_char_tag() and set_char_tag() first call ensure_existence(c)
and that should guarantee that planes[c/0x10000][c%0x10000] points to
a valid char_entry structure (presumably freshly xmalloced).

So what goes wrong?

Regards
Peter Breitenlohner <peb at mppmu.mpg.de>


More information about the tlbuild mailing list