Bug 690313 - memory leak in clist playback
Summary: memory leak in clist playback
Status: NOTIFIED DUPLICATE of bug 689822
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: Graphics Library (show other bugs)
Version: master
Hardware: Macintosh MacOS X
: P1 blocker
Assignee: Ray Johnston
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-03-02 20:05 UTC by Henry Stiles
Modified: 2011-09-18 21:45 UTC (History)
0 users

See Also:
Customer: 951
Word Size: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Henry Stiles 2009-03-02 20:05:22 UTC
The allocation on gxclrast.c:2501 (byte *table = gs_alloc_string(mem,
num_values, "color_space indexed table") is never freed.

main/obj/pcl6 -r600 -dNOPAUSE -sDEVICE=ppmraw -sOutputFile=/dev/null
/mnt/hgfs/henrys/tests_private/pcl/pcl5cfts/fts.0090
Recovered 9c4dd48 size 768 33259'th allocation client color_space indexed table
Recovered 9c4d9f8 size 768 32512'th allocation client color_space indexed table
Recovered 9c4d6e8 size 768 31769'th allocation client color_space indexed table
Recovered 9c4d398 size 768 31048'th allocation client color_space indexed table
Recovered 9c4d048 size 768 18352'th allocation client color_space indexed table
Recovered 9bc9ed8 size 100001 1878'th allocation client char cache chunk(data)
Recovered 9bc9ea0 size 16 1877'th allocation client char cache chunk
Recovered 9b38660 size 16 180'th allocation client initial_chunk
Recovered 9b3c2b8 size 32768 179'th allocation client font_dir_alloc(chars)
Recovered 9b38748 size 15200 178'th allocation client font_dir_alloc(mdata)
Recovered 9b386a8 size 148 177'th allocation client font_dir_alloc(dir)
Recovered 9b26458 size 16 132'th allocation client initial_chunk
Recovered 9b1e430 size 32768 131'th allocation client font_dir_alloc(chars)
Recovered 9b1a8a8 size 15200 130'th allocation client font_dir_alloc(mdata)
Recovered 9b1a7f0 size 148 129'th allocation client font_dir_alloc(dir)
Recovered 9b19738 size 20 122'th allocation client gs_state_alloc(view_clip)
Recovered 9b196d8 size 60 121'th allocation client gs_state_alloc(view_clip)
Recovered 9b195f0 size 196 120'th allocation client gs_state_alloc(view_clip)
Recovered 9b18e98 size 20 108'th allocation client gstate_alloc_parts(clip_path)
Recovered 9b18e38 size 60 107'th allocation client gstate_alloc_parts(clip_path)
Recovered 9b18d50 size 196 106'th allocation client gstate_alloc_parts(clip_path)
Recovered 9b18d18 size 20 105'th allocation client gstate_alloc_parts(path)
Recovered 9b18ca0 size 84 104'th allocation client gstate_alloc_parts(path)
Recovered 9b16720 size 20 95'th allocation client gs_state_alloc(view_clip)
Recovered 9b166c0 size 60 94'th allocation client gs_state_alloc(view_clip)
Recovered 9b165d8 size 196 93'th allocation client gs_state_alloc(view_clip)
Recovered 9b15e80 size 20 81'th allocation client gstate_alloc_parts(clip_path)
Recovered 9b15e20 size 60 80'th allocation client gstate_alloc_parts(clip_path)
Recovered 9b15d38 size 196 79'th allocation client gstate_alloc_parts(clip_path)
Recovered 9b15d00 size 20 78'th allocation client gstate_alloc_parts(path)
Recovered 9b15c88 size 84 77'th allocation client gstate_alloc_parts(path)
Recovered 9b0b258 size 64 7'th allocation client gs_iodev_init(iodev)
Recovered 9b0b1f0 size 64 6'th allocation client gs_iodev_init(iodev)
Recovered 9b0b188 size 64 5'th allocation client gs_iodev_init(iodev)
Recovered 9b0b120 size 64 4'th allocation client gs_iodev_init(iodev)
Recovered 9b0b0b8 size 64 3'th allocation client gs_iodev_init(iodev)
Recovered 9b0b080 size 20 2'th allocation client gs_iodev_init(table)
Recovered 37 blocks, 201773 bytes


...

For this simple job it is not a problem.  For larger jobs the problem is severe.
Comment 1 Henry Stiles 2009-03-02 20:15:25 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.
Comment 2 Ray Johnston 2009-03-02 22:26:23 UTC
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).
Comment 3 Henry Stiles 2009-03-06 12:14:34 UTC
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
Comment 4 Henry Stiles 2009-03-11 21:46:58 UTC
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.
Comment 5 Ray Johnston 2009-03-11 23:09:48 UTC

*** This bug has been marked as a duplicate of 689822 ***
Comment 6 Marcos H. Woehrmann 2011-09-18 21:45:57 UTC
Changing customer bugs that have been resolved more than a year ago to closed.