Re: [pdf-devel] pdf-stm-f-lzw.c

[Steven Vancoillie]

Juan Pedro Bolivar Puente wrote:
> Steven Vancoillie wrote:
>> Hi,
> 
>> I encountered the following problem when running "make check":
> 
>> base/stm/pdf-stm-write.c:998:E:pdf_stm_write:pdf_stm_write_016:0: (after
>> this point) Received signal 11 (Segmentation fault)
> 
>> With gdb, I could trace the problem to the following line
>> (base/pdf-stm-f-lzw.c:321)
> 
>> *(*decode)-- = d->table[code].suffix;
> 
>> The value of the variable "code" (unsigned) at this point is 131117,
>> while the maximum allowed value is 4096 to stay within the bounds of the
>> table array (size defined by LZW_MAX_DICTSIZE).
> 
>> Two questions:
> 
>> 1) When I ran gdb, the value of the variable "code" was indicated as
>> code=<value optimized out>.  Is there a way to obtain the value from gdb
>> by changing e.g. some compiler flags?  Otherwise one has to add print
>> statements to the source code.
> 
>> 2) Is it possible to track the value of "code" throughout the program,
>> e.g. asking gdb to stop when the value goes above 4096?
> 
>> Thanks for your help,
>> Steven
> 
> 
> I will take a look at it. I have not run throught that problem so it
> seems to be a subtle error. Can you tell me in which test case did the
> problem arise? And could you give me some details about wordsize and
> endianess of your machine?
> 
> Thanks for your feedback,
> JP
> 

Hi,

I don't know if you already solved the problem, but after some digging I
found that the following is happening in the function
lzw_buffer_get_code in pdf-stm-f-lzw.c

b->valbuf is an unsigned long, and b->valbits seems to assumes this is
32 bit in size (from what I can make of it). On x86-64 however, unsigned
long is 64 bit.

When I compile with option -m32 (which sets unsigned long to 32 bit),
the problem disappears. Also, setting the type of b->valbuf to unsigned
solves the problem (all tests pass).

grtz
Steven

signature.asc
Description: OpenPGP digital signature