[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/