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
