Summary: | memory leak in clist playback | ||
---|---|---|---|
Product: | Ghostscript | Reporter: | Henry Stiles <henry.stiles> |
Component: | Graphics Library | Assignee: | Ray Johnston <ray.johnston> |
Status: | NOTIFIED DUPLICATE | ||
Severity: | blocker | ||
Priority: | P1 | ||
Version: | master | ||
Hardware: | Macintosh | ||
OS: | MacOS X | ||
Customer: | 951 | Word Size: | --- |
Description
Henry Stiles
2009-03-02 20:05:22 UTC
FWIW, I know the output is cryptic but: 18352'th allocation client color_space indexed table means you can put a breakpoint on pl_alloc then continue skipping the next 18351 calls to pl_alloc like this: (gdb) c 18351 then the debugger puts you at the leaked allocation. Henry, thanks for the hint on breakpointing. I also usually use -ZA (which may not work as I am used to with the "normal" PS allocator) to find leaks and the causes. Accepting this as "assigned". (looks like fun). You can check out the new tree with the old memory manager and go byzantine with -ZA: The leaks.tcl script is screwy... I had to add something like: % Reading ../../tools/owl.pcl: memory allocated to the top of the memory log to get it to start parsing. After that the leak is easily seen with leaks.tcl The source of this issue is in gscolor2.c:gx_final_Indexed(), see the comments in the code. Sigh, I can't remember the details about this issue. *** This bug has been marked as a duplicate of 689822 *** Changing customer bugs that have been resolved more than a year ago to closed. |