[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [xml/sgml] xerces packages and arm: opinions sought

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

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

Reply to: