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

[Chad Parker]

This appears to be the case. After upgrading to the gcc packages in testing
it now appears to be compiling without issue and a much more reasonable
memory usage of less then 60 MB.

Perhaps a note of this should be made in the slackbuild readme...? I guess
it seems like it's a bug with gcj, not the anything to do with the
slackbuild, but it seems that if the slackbuild is going to be in a
repository for 13.0 that a note should be made for users running a stock
installation.

Thanks for the suggestion/resolution!
--Chad

On Wed, Dec 2, 2009 at 13:12, Robby Workman <rworkman at slackbuilds.org>wrote:

> 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 --------------
An HTML attachment was scrubbed...
URL: <http://lists.slackbuilds.org/pipermail/slackbuilds-users/attachments/20091202/fa06c89b/attachment.htm>