[sldev] [VWR] OpenJPEG backtraces

[Nicholaz Beresford]

Argent Stonecutter wrote:
 >> h.mem = v.mem = (int*)( (unsigned)m + 16 - ( (unsigned)m % 16 ) ) ;
 >
 > h.mem = v.mem = (int*)( (char *)m + 16 - ( (char *)m % 16 ) ) ;

the modulo operator can't be applied to a pointer type (same goes for
"ptr & x"), only legal arithmetic for potiner is addition and subtract.


 > I'm not sure what the correct portable correct version is to make a
 > patch thats good for 32 and 64 systems.

I'd say do it as (unsigned long).   ULONG should have a size large
enough on both versions to hold the numeric equivalent of a pointer.

If you want to be sure add an assertion, like
    assert(sizeof(unsigned long)>=sizeof(int*));


My variant would be.
    h.mem = v.mem = (int*)( ((unsigned long)m + 16) & ~0xF ) ;


As a side note, depending on the source, they probably want to do a
+15 instead of +16 to not skip to the next segment if the pointer
is already 16-aligned, but that depends on what's about to happen
there exactly.


Nick


Second Life from the inside out:
http://nicholaz-beresford.blogspot.com/


Robin Cornelius wrote:
> Robin Cornelius wrote:
>>
>> (gdb) bt
>> #0  0x0000000001dcb476 in dwt_interleave_h (h=0x41801b90, a=0xff6a0f0) 
>> at libopenjpeg/dwt.c:166
>> #1  0x0000000001dcdfaf in dwt_decode_tile (tilec=0x845ede0, stop=0, 
> 
> Looking at frame #1 i've found the problem
> 
> in dwt.c line 623 we have pointer truncation
> 
> h.mem = v.mem = (int*)( (unsigned)m + 16 - ( (unsigned)m % 16 ) ) ;
> 
> I've checked the contents of h and m using the gdb console and with the 
> (unsigned) cast you get a bogus memory location and with a (unsigned 
> long) cast you get the intended memory location
> 
> 64bit systems only
> 
> I'm not sure what the correct portable correct version is to make a 
> patch thats good for 32 and 64 systems.
> 
> Robin
> 
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> /index.html