Valgrind reports a memory leak running jpx-file1.pdf test file. About 11K is lost per file. $ ~/local/bin/valgrind --leak-check=full \ gs/debugobj/gs -dNOPAUSE -dBATCH -dNOGC -sDEVICE=nullpage \ /home/regression/comparefiles/jpx-file1.pdf \ /home/regression/comparefiles/jpx-file1.pdf Valgrind results: ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 28 from 1) malloc/free: in use at exit: 23,402 bytes in 74 blocks. malloc/free: 17,794 allocs, 17,720 frees, 47,022,829 bytes allocated. For counts of detected errors, rerun with: -v searching for pointers to 74 not-freed blocks. checked 309,892 bytes. 23,402 (11,736 direct, 11,666 indirect) bytes in 26 blocks are definitely lost in loss record 2 of 2 at 0x401B867: malloc (vg_replace_malloc.c:149) by 0x8174F8E: jas_malloc (jas_malloc.c:170) by 0x8171D5C: jas_iccprof_create (jas_icc.c:209) by 0x8171DC4: jas_iccprof_copy (jas_icc.c:228) by 0x816DABE: jas_cmprof_createfromiccprof (jas_cm.c:357) by 0x816D86E: jas_cmprof_createfromclrspc (jas_cm.c:197) by 0x816FFAB: jas_image_decode (jas_image.c:387) by 0x816D5B5: s_jpxd_decode_image (sjpx.c:301) by 0x816D67C: s_jpxd_process (sjpx.c:368) by 0x80CB196: sreadbuf (stream.c:806) by 0x80CB01B: s_process_read_buf (stream.c:732) by 0x80E694C: image_file_continue (zimage.c:480) LEAK SUMMARY: definitely lost: 11,736 bytes in 26 blocks. indirectly lost: 11,666 bytes in 48 blocks. possibly lost: 0 bytes in 0 blocks. still reachable: 0 bytes in 0 blocks. suppressed: 0 bytes in 0 blocks.
Created attachment 6647 [details] Sample file. The file has been deleted from comparefiles/ as by the rev. 3210 as a duplicate to the file in tests_public/pdf/ and later replaced with a new set of JP2 files by the rev. r10177.
The leak is still there and it's proportional to the number of times the file runs.
(In reply to comment #2) > The leak is still there and it's proportional to the number of times > the file runs. Yes I am looking at the code in jas_cm.c around line 194: default: if (!(iccprof = jas_iccprof_createfromclrspc(clrspc))) goto error; if (!(prof = jas_cmprof_createfromiccprof(iccprof))) goto error; #if 0 jas_iccprof_destroy(iccprof); #else prof->iccprof = iccprof; #endif if (!jas_clrspc_isgeneric(clrspc)) prof->clrspc = clrspc; break; } return prof; This doesn't make sense, iccprof should be destroyed and there should be no assigment to prof->iccprof, exactly the opposite of the conditional directive. jas_cmprof_createfromiccprofile() makes a copy of the profile passed in as a parameter and puts it in `prof'.
Sigh, the leak is also fixed in jasper 1.9 I guess we never upgraded. A consultant is going to start integrating openjpeg shortly so I'm not going to attempt upgrading jasper.
We don't use jasper anymore, closing.