Re: pdf problem

> Uwe, I think we have another pdflib problem. > > Using the current CVS compiled with --enable-debug to get Zeev's memory > debugging stuff enabled (weird place for the segfault here), I get the > following seg fault: > > Program received signal SIGSEGV, Segmentation fault. > 0x6569c in _mem_block_check (ptr=0x5a5a5a00, silent=1, filename=0x0, lineno=158) at alloc.c:384 > 384 { > (gdb) bt > #0 0x6569c in _mem_block_check (ptr=0x5a5a5a00, silent=1, filename=0x0, lineno=158) at > alloc.c:384 > #1 0x651b8 in _efree (ptr=0x5a5a5a00, filename=0x173b80 "functions/pdf.c", > lineno=158) at alloc.c:155 > #2 0x99488 in _free_pdf_info (info=0x298390) at functions/pdf.c:158 > > How do you want to approach solving this? We could keep our own internal > struct here and keep a copy of those estrdup'ed pointers. The way pdflib > is written, I don't know how the author thinks people are supposed to > avoid memory leaks here. The way he blows away the info pointer doesn't > give anybody any chance to free the underlying element memory. Since the pdf_info struct isn't needed after the pdf_open call, I decided to get rid of it right after the pdf_open call. I don't know if this is OK because pdf_info disappears silently. Do you think this is acceptable? Uwe > -- > PHP Development Mailing List http://www.php.net/ > To unsubscribe send an empty message to php-dev-unsubscribe@lists.php.net > For help: php-dev-help@lists.php.net > > -- PHP Development Mailing List http://www.php.net/ To unsubscribe send an empty message to php-dev-unsubscribe@lists.php.net For help: php-dev-help@lists.php.net