[Valgrind-users] memcheck GC: Increasing nodes, but constant survivors
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 signature.asc Description: This is a digitally signed message part -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
[Valgrind-users] Unsubscribe request of Rahul (was: List test)
Dear Rahul, please read the netiquette, next time you deal with lists [1]. No HTML in message or no unrelated replies to threads and descriptive subject lines! Am Mittwoch, den 06.03.2013, 18:26 +0800 schrieb rahul.si...@continental-corporation.com: plz remove me from the list As you subscribed yourself, please also do this yourself. Every message you received has the following signature. ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users Go to that site and search for »unsubscribe«. To unsubscribe from Valgrind-users, get a password reminder, or change your subscription options enter your subscription email address: Enter your email address there. Alternatively, you can send a message to valgrind-users-requ...@lists.sourceforge.net with the word `unsubscribe` in the message body. Thanks, Paul [1] http://en.opensuse.org/openSUSE:Mailing_list_netiquette signature.asc Description: This is a digitally signed message part -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Valgrind does not show the source file with line numbers for some programs, but GDB does
Dear Valgrind users, Am Montag, den 11.02.2013, 12:32 +0100 schrieb Paul Menzel: first a big thank you to the developers for this great program. I am using Valgrind 3.8.1-1 from Debian Sid/unstable. Despite having the debug packages of some packages installed for the debug symbols and Valgrind finding them, it does not give the line number. The strange thing is, that GDB has no problems with this and is able to display the source file and file name just fine. Two programs this happened with are Evolution [1][2] and HPLIP while running Simple Scan under Valgrind. Here Valgrind seems to find the file with debugging symbols. --19364-- Reading syms from /usr/lib/libhpip.so.0.0.1 --19364-- Considering /usr/lib/debug/.build-id/84/1c797c37116c1c9365f12b531eec5dc65ebab1.debug .. --19364-- .. build-id is valid But it does not give me the line number in the source file. ==19364== Conditional jump or move depends on uninitialised value(s) ==19364==at 0x20ED4E25: ipConvert (in /usr/lib/libhpip.so.0.0.1) ==19364==by 0x20EB7595: sclpml_read (in /usr/lib/sane/libsane-hpaio.so.1.0.0) ==19364==by 0x424595: _scanner_scan_thread_gthread_func (scanner.c:7155) I read the entry in the FAQ [3], but I have the debugging symbols installed. If Valgrind is using some different mechanism than GDB to find out the source file and line number, how can I check that the files containing debugging symbols adhere to Valgrind’s requirements? I submitted a report to the Debian BTS and it was assigned the number #701480. Thanks, Paul [1] https://mail.gnome.org/archives/evolution-hackers/2013-January/msg00020.html [2] https://bugzilla.gnome.org/show_bug.cgi?id=691303 [3] http://valgrind.org/docs/manual/faq.html#faq.unhelpful [4] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=701480 signature.asc Description: This is a digitally signed message part -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
[Valgrind-users] How to figure out if binary was built with `-fomit-frame-pointers`?
Dear Valgrind users, how can I find out if a binary was compiled with `-fomit-frame-pointers` or not? Thanks, Paul signature.asc Description: This is a digitally signed message part -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] [PATCH] Improve errors for use-after-free on memory pools
Dear Matthias, I am new to Valgrind too. Reading the Mailing Lists and IRC Web page [1] there is also a developer list, where your patch might get more attention. Am Dienstag, den 12.02.2013, 07:13 +0100 schrieb Matthias Schwarzott: Currently the valgrind-message for use-after-free for a memory pool consists of the execution callstack and the callstack, where the superblock was allocated. To better diagnose it I wanted to get also the callstack of the place where MEMPOOL_FREE was called. Sounds like a nice idea to me. The attached patch uses the new fields added for use-after-free messages that show two callstacks. It is just a proof of concept. How could it be improved? Could you show a trace without and with your patch applied? Thanks, Paul [1] http://valgrind.org/support/ signature.asc Description: This is a digitally signed message part -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
[Valgrind-users] Valgrind does not show the source file with line numbers for some programs, but GDB does
Dear Valgrind users, first a big thank you to the developers for this great program. I am using Valgrind 3.8.1-1 from Debian Sid/unstable. Despite having the debug packages of some packages installed for the debug symbols and Valgrind finding them, it does not give the line number. The strange thing is, that GDB has no problems with this and is able to display the source file and file name just fine. Two programs this happened with are Evolution [1][2] and HPLIP while running Simple Scan under Valgrind. Here Valgrind seems to find the file with debugging symbols. --19364-- Reading syms from /usr/lib/libhpip.so.0.0.1 --19364-- Considering /usr/lib/debug/.build-id/84/1c797c37116c1c9365f12b531eec5dc65ebab1.debug .. --19364-- .. build-id is valid But it does not give me the line number in the source file. ==19364== Conditional jump or move depends on uninitialised value(s) ==19364==at 0x20ED4E25: ipConvert (in /usr/lib/libhpip.so.0.0.1) ==19364==by 0x20EB7595: sclpml_read (in /usr/lib/sane/libsane-hpaio.so.1.0.0) ==19364==by 0x424595: _scanner_scan_thread_gthread_func (scanner.c:7155) I read the entry in the FAQ [3], but I have the debugging symbols installed. If Valgrind is using some different mechanism than GDB to find out the source file and line number, how can I check that the files containing debugging symbols adhere to Valgrind’s requirements? Thanks, Paul [1] https://mail.gnome.org/archives/evolution-hackers/2013-January/msg00020.html [2] https://bugzilla.gnome.org/show_bug.cgi?id=691303 [3] http://valgrind.org/docs/manual/faq.html#faq.unhelpful signature.asc Description: This is a digitally signed message part -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
