GNOME Bugzilla – Bug 352869
More than a gig of heap consumed when displaying certain documents
Last modified: 2006-08-29 12:08:47 UTC
Please describe the problem: When evince loads certain types of pdf files, its heap size grows and quickly exceeds 1Gbyte Steps to reproduce: 1.Install GNOME 2.14 and evince 0.5.3 on Solaris. 2.launch evince with the following file: http://www.redbooks.ibm.com/redpapers/pdfs/redp4150.pdf Actual results: Evince does display the document. Other applications are swapped out of memory. evince's heap and memory usage grows quickly to over 1 Gigabyte. Expected results: Evince should display this document using no more than 33M of Aononymous memory (as acroread does) Does this happen every time? Yes Other information: > ::findleaks BYTES LEAKED VMEM_SEG CALLER 4096 4 cc32b000 MMAP 4096 1 d0b6d000 MMAP 12288 1 cdd04000 MMAP 4096 1 cc42a000 MMAP 32776 10597 8f2cbb8 libz.so.1`zcalloc+0x1e ------------------------------------------------------------------------ Total 10601 oversized leaks, 347351848 bytes CACHE LEAKED BUFCTL CALLER 080c6a10 11 08e036a0 libCrun.so.1`__1c2n6FI_pv_+0x33 080c6a10 3 08dcaad0 libCrun.so.1`__1c2n6FI_pv_+0x33 080c6a10 82 08c250b8 libCrun.so.1`__1c2n6FI_pv_+0x33 080c6c10 59 08dbdb98 libCrun.so.1`__1c2n6FI_pv_+0x33 080c6c10 3 08dbd850 libCrun.so.1`__1c2n6FI_pv_+0x33 080c6e10 2 08b9f470 libCrun.so.1`__1c2n6FI_pv_+0x33 080c9210 1 08cfade8 libCrun.so.1`__1c2n6FI_pv_+0x33 080c9610 1 08c9c600 libCrun.so.1`__1c2n6FI_pv_+0x33 080c9810 2 08d21010 libCrun.so.1`__1c2n6FI_pv_+0x33 080c9c10 1 08e0cf38 libCrun.so.1`__1c2n6FI_pv_+0x33 080c9c10 1 08e09030 libCrun.so.1`__1c2n6FI_pv_+0x33 080c9010 1 081a2ce8 libglib-2.0.so.0.1000.2`standard_calloc+0x1f 080c9210 1 0816e600 libglib-2.0.so.0.1000.2`standard_calloc+0x1f 080c9210 1 08b88c98 libglib-2.0.so.0.1000.2`standard_calloc+0x1f 080c9210 1 0816e6f0 libglib-2.0.so.0.1000.2`standard_calloc+0x1f 080c9210 1 08b88e00 libglib-2.0.so.0.1000.2`standard_calloc+0x1f 080cfc10 1 080f17f8 libglib-2.0.so.0.1000.2`standard_calloc+0x1f 080c6c10 1 08e2b0e0 libglib-2.0.so.0.1000.2`standard_malloc+0x1b 080c6c10 1 0813c0a8 libglib-2.0.so.0.1000.2`standard_malloc+0x1b 080c6e10 1 08155c00 libglib-2.0.so.0.1000.2`standard_malloc+0x1b 080c9010 1 08c1e428 libglib-2.0.so.0.1000.2`standard_malloc+0x1b 080c9410 1 08d6e0c0 libglib-2.0.so.0.1000.2`standard_malloc+0x1b 080c9410 1 08bdbd50 libglib-2.0.so.0.1000.2`standard_malloc+0x1b 080c9c10 1 08c7b708 libglib-2.0.so.0.1000.2`standard_malloc+0x1b 080cf410 1 08cd2848 libpoppler.so.1.0.0`grealloc+0x29 080cfa10 1 08c276b8 libpoppler.so.1.0.0`grealloc+0x29 080c6e10 13986 08f95f30 libz.so.1`zcalloc+0x1e 080c9810 13969 08eec790 libz.so.1`zcalloc+0x1e 080d1a10 11 08ece7a0 libz.so.1`zcalloc+0x1e 080d1a10 12430 08f95300 libz.so.1`zcalloc+0x1e ------------------------------------------------------------------------ Total 40577 buffers, 154448784 bytes
I traced this problem to a memory leak in zlib 1.1.4. Installing zlib 1.2.3 fixes the problem on Solaris.
Great!, closing as not gnome then.