|
From: Paul M. <pau...@us...> - 2015-03-26 06:31:30
|
Dear Valgrind folks,
please CC me as I am not subscribed.
With Debian Jessie/testing and Valgrind 3.10.0 (package 1:3.10.0-4) to
debug a segmentation fault in wkhtmltopdf [1][2][3], running the
following command,
# G_SLICE=always-malloc G_DEBUG=gc-friendly xvfb-run valgrind -v --tool=memcheck --leak-check=full --num-callers=40 --log-file=/tmp/20150325--wkhtmltopdf.log wkhtmltopdf http://giantmonkey.de giantmonkey.pdf
Loading page (1/2)
[===========================================> ] 73%
it stays at this place for over 24 hours now while one CPU core is
constantly running at 100 %.
The log is still written to and the end looks as below.
[…]
==1908== TO DEBUG THIS PROCESS USING GDB: start GDB like this
==1908== /path/to/gdb wkhtmltopdf
==1908== and then give GDB the following command
==1908== target remote | /usr/lib/valgrind/../../bin/vgdb --pid=1908
==1908== --pid is optional if only one valgrind process is running
==1908==
--1892-- memcheck GC: 6249 nodes, 4986 survivors ( 79.7%)
--1892-- memcheck GC: 8837 new table size (stepup)
--1892-- memcheck GC: 8837 nodes, 5101 survivors ( 57.7%)
--1892-- memcheck GC: 12497 new table size (stepup)
--1892-- memcheck GC: 12497 nodes, 5654 survivors ( 45.2%)
--1892-- memcheck GC: 12684 new table size (driftup)
--1892-- memcheck GC: 12684 nodes, 5657 survivors ( 44.5%)
--1892-- memcheck GC: 12874 new table size (driftup)
--1892-- memcheck GC: 12874 nodes, 5657 survivors ( 43.9%)
--1892-- memcheck GC: 13067 new table size (driftup)
--1892-- memcheck GC: 13067 nodes, 5657 survivors ( 43.2%)
--1892-- memcheck GC: 13263 new table size (driftup)
--1892-- memcheck GC: 13263 nodes, 5657 survivors ( 42.6%)
--1892-- memcheck GC: 13461 new table size (driftup)
--1892-- memcheck GC: 13461 nodes, 5657 survivors ( 42.0%)
--1892-- memcheck GC: 13662 new table size (driftup)
--1892-- memcheck GC: 13662 nodes, 5657 survivors ( 41.4%)
--1892-- memcheck GC: 13866 new table size (driftup)
--1892-- memcheck GC: 13866 nodes, 5657 survivors ( 40.7%)
--1892-- memcheck GC: 14073 new table size (driftup)
--1892-- memcheck GC: 14073 nodes, 5657 survivors ( 40.1%)
--1892-- memcheck GC: 14284 new table size (driftup)
--1892-- memcheck GC: 14284 nodes, 5657 survivors ( 39.6%)
--1892-- memcheck GC: 14498 new table size (driftup)
--1892-- memcheck GC: 14498 nodes, 5657 survivors ( 39.0%)
--1892-- memcheck GC: 14715 new table size (driftup)
--1892-- memcheck GC: 14715 nodes, 5657 survivors ( 38.4%)
--1892-- memcheck GC: 14935 new table size (driftup)
--1892-- memcheck GC: 14935 nodes, 5657 survivors ( 37.8%)
--1892-- memcheck GC: 15159 new table size (driftup)
--1892-- memcheck GC: 15159 nodes, 5657 survivors ( 37.3%)
--1892-- memcheck GC: 15386 new table size (driftup)
--1892-- memcheck GC: 15386 nodes, 5657 survivors ( 36.7%)
--1892-- memcheck GC: 15616 new table size (driftup)
So the table size is increasing as do the nodes, but the survivors
remain constant at 5657.
Is there a chance that this run will give anything useful, so that I
should leave it running? Or is it in a kind of infinite loop and I can
abort it?
Thanks,
Paul
[1] http://wkhtmltopdf.org/
[2] https://github.com/wkhtmltopdf/wkhtmltopdf
[3] https://bugreports.qt.io/browse/QTBUG-41360
|