[xml/sgml] xerces packages and arm: opinions sought
Jay Berkenbilt
ejb@ql.org
Wed, 11 Aug 2004 02:45:32 GMT
This information is potentially very helpful. I will forward it to
the bug report I opened for icu28 FTBFS on arm. My decision to
downgrade is a temporary one -- there were other fixes in the most
recent upload of the xerces packages that should really be in sarge if
possible. With the freeze imminent, I don't want icu28 to prevent
xerces from transitioning which would in turn prevent xalan from
transitioning.
> On Tue, Aug 10, 2004 at 07:49:17PM -0400, Jay Berkenbilt wrote:
> >
> > Responding to my own question, I talked about this on IRC and decided
> > to just downgrade to icu21 rather than dropping arm support. Someone
> > on IRC volunteered to sponsor the upload.
>
> Your decision notwithstanding, the problem with icu28 seems to be:
>
> Program received signal SIGSEGV, Segmentation fault.
> expandGroupLengths (s=0x5e4744e2 <Address 0x5e4744e2 out of bounds>,
> offsets=0xbfffe908, lengths=0xbfffe8c4) at ../../source/common/unames.c:520
> 520 lengthByte=*s++;
> Current language: auto; currently c
> (gdb) bt
> #0 expandGroupLengths (s=0x5e4744e2 <Address 0x5e4744e2 out of bounds>,
> offsets=0xbfffe908, lengths=0xbfffe8c4) at
> ../../source/common/unames.c:520
> #1 0x400adb30 in enumGroupNames (names=0x40420020, group=0x0, start=0,
> end=31, fn=0x40420020, context=0x404248ec, nameChoice=U_EXTENDED_CHAR_NAME)
> at ../../source/common/unames.c:605
> (gdb)
>
> Which implies the problem is in the calculation of the "s" pointer:
>
> const uint8_t *s=(uint8_t *)names+names->groupStringOffset+
> (group->offsetHigh<<16|group->offsetLow);
> s=expandGroupLengths(s, offsets, lengths);
>
> I have no idea how this code is supposed to work but perhaps knowing the
> values involved at the time of the call might be of use (this is right
> before the call to expandGroupLengths():
>
> (gdb) p s
> $2 = (const uint8_t *) 0x5e4744e2 <Address 0x5e4744e2 out of bounds>
> (gdb) p names
> $3 = (UCharNames *) 0x40420020
> (gdb) p names->groupStringOffset
> $4 = 17580
> (gdb) p group->offsetHigh
> $5 = 7685
> (gdb) p group->offsetLow
> $6 = 22
> (gdb) p *names
> $7 = {tokenStringOffset = 3030, groupsOffset = 14410,
> groupStringOffset = 17580, algNamesOffset = 142956}
>
> I'm troubled by the use of arrays are arguments in the expandGroupLengths()
> function. I'm not sure how this is meant to work; in plain C the best you
> could hope for is to pass a pointer and then dereference it in the function.
> I suspect that is what is happening here, but as written it looks like the
> "offsets" and "lengths" are passed uninitialized to expandGroupLengths(),
> which then goes ahead and increments values therein.
>
> Definately suspect code, on any platform, i my books anyways.
At a very casual glance, it looks like code that was trying work even
if it was on a 16-bit system. Not that that sheds much light though.
In any case, thanks for the information. In case you're interested in
pursuing this further, the bug in question is 264860.
--
Jay Berkenbilt <ejb@ql.org>
http://www.ql.org/q/