[Slackbuilds-users] pdftk: Repeated allocation of very large block (appr. size 1048576000): May lead to memory leak and poor performance.

[Robby Workman]

On Wed, 2 Dec 2009 12:28:53 -0500
Chad Parker <parker.charles at gmail.com> wrote:

> Attempting to build pdftk from the 13.0 repository on a
> slackware64-current system resulted in gcj attempting to allocate
> over 3GB of memory.
> 
> Google only seems to know about one other report of this:
> http://gcc.gnu.org/ml/gcc-bugs/2009-10/msg01960.html
> 
> while the build doesn't actually crash, the machine becomes unusable
> while the build process waits on disk IO
> 
> I installed the jdk package as suggested in the readme. Same problem
> both before and after.
> 
> There's nothing interesting in the archive verification or extraction
> portions of the log. Here's the tail end of the log:
> 
> patching file java_libs/Makefile
> patching file pdftk/Makefile.Base
> patching file pdftk/Makefile.Generic
> patching file pdftk/Makefile.Generic
> Hunk #1 succeeded at 27 (offset 4 lines).
> make -C ../java_libs
> make[1]: Entering directory `/tmp/SBo/pdftk-1.41/java_libs'
> make -C "/tmp/SBo/pdftk-1.41/java_libs/com/lowagie/text";
> make[2]: Entering directory
> `/tmp/SBo/pdftk-1.41/java_libs/com/lowagie/text' gcj -O2 -fPIC -w
> --encoding=UTF-8 --classpath="/tmp/SBo/pdftk-1.41/java_libs" -c
> Anchor.java -o Anchor.o GC Warning: Repeated allocation of very large
> block (appr. size 1048576000): May lead to memory leak and poor
> performance. ^C


Hrm, interesting...  I don't get that on my -current box with
gcc-4.4.2 from /testing.  Maybe that bug is fixed in later gcc.

-RW
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.slackbuilds.org/pipermail/slackbuilds-users/attachments/20091202/2d421af3/attachment-0001.asc>