valgrind-users

[Valgrind-users] Strange warning: Ignoring non-Dwarf2/3/4 block in .debug_info

[ISHIKAWA,chiaki <ish...@yk...>]

Hi,

First of all, thank you for sharing this great package.

I encountered a strange bug (?) while trying to use valgrind to
validate the operation of a binary produced when I was testing Mozilla
Thunderbird operation.

The observation is with valgrind -3.12.0 SVN which was compiled last
November.  the copyright header shows this.

==11405== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==11405== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for 
copyright info

Now the problem.
As soon as the binary is run under valgrind, valgrind printed many 
warnings like the following.


--11405-- WARNING: Serious error when reading debug info
--11405-- When reading debug info from 
/usr/lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0.3200.3:
--11405-- Ignoring non-Dwarf2/3/4 block in .debug_info
--11405-- WARNING: Serious error when reading debug info
--11405-- When reading debug info from 
/usr/lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0.3200.3:
--11405-- Last block truncated in .debug_info; ignoring
--11405-- WARNING: Serious error when reading debug info
--11405-- When reading debug info from 
/usr/lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0.3200.3:
--11405-- parse_CU_Header: is neither DWARF2 nor DWARF3 nor DWARF4
--11405-- WARNING: Serious error when reading debug info
--11405-- When reading debug info from 
/usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.4600.2:
--11405-- Ignoring non-Dwarf2/3/4 block in .debug_info
--11405-- WARNING: Serious error when reading debug info
--11405-- When reading debug info from 
/usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.4600.2:
--11405-- Last block truncated in .debug_info; ignoring
--11405-- WARNING: Serious error when reading debug info
--11405-- When reading debug info from 
/usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.4600.2:

           There are  more repetitions for different libraries

This is under Debian GNU/Linux 64-bit version.

uname -a outoup:
Linux ip030 3.19.5 #1 SMP Mon Apr 20 08:50:21 JST 2015 x86_64 GNU/Linux

Say, for the last library file in the warning lines, |file| command 
printed something like this.
/usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.4600.2: ELF 64-bit LSB shared 
object, x86-64, version 1 (SYSV), dynamically linked, 
BuildID[sha1]=f7cf7ddb040d36cb8709e6403bc19be4570754d6, stripped

Since I could link the binary using GNU LD (gold) without an obvious
issue to compile and build mozilla thunderbird locally under linux
64-bit on this PC, the library is not completely broken, I suppose.

Now using google and search for hits with the string "Ignoring
non-Dwarf2/3/4 block in .debug_info"
I immediately find a few hits:

The first one is about valgrind operation on ARM CPU.
http://sourceforge.net/p/valgrind/mailman/valgrind-users/thread/4E8...@bi.../
It mentions something about unaligned access.
But mine is x86_64 CPU and hugely popular one. Beside, I think x86 can 
read at any
octet boundary albeit minor performance loss if alignment is not perfect.
So I doubt anything like the ARM issue may exist. Correct ?

Second hit is from Feb 2015.
https://bugs.kde.org/show_bug.cgi?id=338781
which explains maybe "--read-var-info=yes" can be a problem (Is it on by 
default?)
and "--read-var-info=no" may solve the issue.
But it turns out it is an OSX issue. And maybe the compiler is from llvm.

The next three entries are from the same Debian bug entry.

Anyway, I tried to add --read-var-info=no, but it did not help.

The following is an excerpt from the log:
E.g.: Please understand that the invocation of valgrind is part of
a test harness and so I have to show the log line which showed how the
valgrind is invoked:

  0:01.09 PROCESS_OUTPUT: Thread-1 (pid:12190) Full command: 
['/usr/local/bin/valgrind', '--read-var-info=no', 
'--read-inline-info=no', 
'/NREF-COMM-CENTRAL/objdir-tb3/dist/bin/xpcshell', '-g', 
'/NREF-COMM-CENTRAL/objdir-tb3/dist/bin', '-a', 
'/NREF-COMM-CENTRAL/objdir-tb3/dist/bin', '-r', 
'/NREF-COMM-CENTRAL/objdir-tb3/dist/bin/components/httpd.manifest', 
'-m', '-s', '-e', 'const _HEAD_JS_PATH = 
"/NREF-COMM-CENTRAL/comm-central/mozilla/testing/xpcshell/head.js";', 
'-e', 'const _MOZINFO_JS_PATH = 
"/tmp/xpc-profile-fcjmuR/mozinfo.json";', '-e', 'const 
_TESTING_MODULES_DIR = 
"/NREF-COMM-CENTRAL/objdir-tb3/_tests/modules/";', '-f', 
'/NREF-COMM-CENTRAL/comm-central/mozilla/testing/xpcshell/head.js', 
'-p', '/tmp/xpc-plugins-wGKRGS', '-e', 'const _SERVER_ADDR = 
"localhost"', '-e', 'const _HEAD_FILES = [];', '-e', 'const _TAIL_FILES 
= [];', '-e', 'const _JSDEBUGGER_PORT = 0;', '-e', 'const _TEST_FILE = 
["/NREF-COMM-CENTRAL/objdir-tb3/_tests/xpcshell/caps/tests/unit/test_origin.js"];', 
'-e', 'const _TEST_NAME = "caps/tests/unit/test_origin.js"', '-e', 
'_execute_test(); quit(0);']
(pid:12190) "==12190== Memcheck, a memory error detector"
  0:01.09 PROCESS_OUTPUT: Thread-1 (pid:12190) "==12190== Copyright (C) 
2002-2015, and GNU GPL'd, by Julian Seward et al."
  0:01.09 PROCESS_OUTPUT: Thread-1 (pid:12190) "==12190== Using 
Valgrind-3.12.0.SVN and LibVEX; rerun with -h for copyright info"
  0:01.09 PROCESS_OUTPUT: Thread-1 (pid:12190) "==12190== Command: 
/NREF-COMM-CENTRAL/objdir-tb3/dist/bin/xpcshell -g 
/NREF-COMM-CENTRAL/objdir-tb3/dist/bin -a 
/NREF-COMM-CENTRAL/objdir-tb3/dist/bin -r 
/NREF-COMM-CENTRAL/objdir-tb3/dist/bin/components/httpd.manifest -m -s 
-e const\\ _HEAD_JS_PATH\\ =\\ 
"/NREF-COMM-CENTRAL/comm-central/mozilla/testing/xpcshell/head.js"; -e 
const\\ _MOZINFO_JS_PATH\\ =\\ "/tmp/xpc-profile-fcjmuR/mozinfo.json"; 
-e const\\ _TESTING_MODULES_DIR\\ =\\ 
"/NREF-COMM-CENTRAL/objdir-tb3/_tests/modules/"; -f 
/NREF-COMM-CENTRAL/comm-central/mozilla/testing/xpcshell/head.js -p 
/tmp/xpc-plugins-wGKRGS -e const\\ _SERVER_ADDR\\ =\\ "localhost" -e 
const\\ _HEAD_FILES\\ =\\ []; -e const\\ _TAIL_FILES\\ =\\ []; -e 
const\\ _JSDEBUGGER_PORT\\ =\\ 0; -e const\\ _TEST_FILE\\ =\\ 
["/NREF-COMM-CENTRAL/objdir-tb3/_tests/xpcshell/caps/tests/unit/test_origin.js"]; 
-e const\\ _TEST_NAME\\ =\\ "caps/tests/unit/test_origin.js" -e 
_execute_test();\\ quit(0);"
  0:01.09 PROCESS_OUTPUT: Thread-1 (pid:12190) "==12190== "
  0:10.66 PROCESS_OUTPUT: Thread-1 (pid:12190) "--12190-- WARNING: 
Serious error when reading debug info"
  0:10.66 PROCESS_OUTPUT: Thread-1 (pid:12190) "--12190-- When reading 
debug info from /usr/lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0.3200.3:"
  0:10.66 PROCESS_OUTPUT: Thread-1 (pid:12190) "--12190-- Ignoring 
non-Dwarf2/3/4 block in .debug_info"
  0:10.66 PROCESS_OUTPUT: Thread-1 (pid:12190) "--12190-- WARNING: 
Serious error when reading debug info"
  0:10.66 PROCESS_OUTPUT: Thread-1 (pid:12190) "--12190-- When reading 
debug info from /usr/lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0.3200.3:"
  0:10.66 PROCESS_OUTPUT: Thread-1 (pid:12190) "--12190-- Last block 
truncated in .debug_info; ignoring"
  0:10.68 PROCESS_OUTPUT: Thread-1 (pid:12190) "--12190-- WARNING: 
Serious error when reading debug info"

  ...


So it seems that the latest compiler/linker combination has produced the 
library
may not be producing library which valgrind expects to see.

What can I do to alert the GNU binutils and/or GCC people (does Debian 
use llvm compiler lately?) about this issue? And in what manner. I am 
not sure if I understand the cause of the issue completely.
All I can say is that the format is not compatible or something.
I can send the offending library on request.

Thank you in advance for your attention.

CI

Re: [Valgrind-users] Strange warning: Ignoring non-Dwarf2/3/4 block in .debug_info

[Julian S. <js...@ac...>]

Chiaki,

> First of all, thank you for sharing this great package.

First of all, thank you for supporting Thunderbird.  I use it all the time.

> --11405-- WARNING: Serious error when reading debug info
> --11405-- When reading debug info from 
> /usr/lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0.3200.3:
> --11405-- Ignoring non-Dwarf2/3/4 block in .debug_info

Hmm.  That is pretty strange.  Can you send by email (not to the
list) a copy of this libgdk_pixbuf-2.0.so.0.3200.3, for investigation?

J

Re: [Valgrind-users] Strange warning: Ignoring non-Dwarf2/3/4 block in .debug_info

[ISHIKAWA,chiaki <ish...@yk...>]

On 2016/01/18 23:32, Julian Seward wrote:
> Chiaki,
>
>> First of all, thank you for sharing this great package.
> First of all, thank you for supporting Thunderbird.  I use it all the time.
>
>> --11405-- WARNING: Serious error when reading debug info
>> --11405-- When reading debug info from
>> /usr/lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0.3200.3:
>> --11405-- Ignoring non-Dwarf2/3/4 block in .debug_info
> Hmm.  That is pretty strange.  Can you send by email (not to the
> list) a copy of this libgdk_pixbuf-2.0.so.0.3200.3, for investigation?
>
> J

Yes, I will.

Chiaki

Re: [Valgrind-users] Strange warning: Ignoring non-Dwarf2/3/4 block in .debug_info

[ISHIKAWA,chiaki <ish...@yk...>]

This is an observation from a Debian user.

I use Debian 64bit on my home PC.

Between the end of December/beginning of January and now, something
in the Debian repository which I fetched, probably during the update
to gcc 5.3 branch, caused a significant change from the viewpoint of 
valgrind/memcheck.
Most notably c11++ runtime (or is it spelled c++11 ?) seems to have been 
introduced and
this caused massive reports of mismatched new vs free from 
valgrind/memcheck.
c++11 runtime seems to use |new| operation to create some data in a very 
primitive internal string handling function, and these string data are 
"free"ed by many other functions that my application (mozilla 
thunderbird) use. So delete vs free issues are reported. I suspect c++11 
ought to use "malloc()" for the internal string operation, but then 
maybe other parts of c++11 library may complain about malloc vs delete 
mismatch then :-(

I think those who want to move on to newer GCC (g++) and its runtime may 
want to get prepared for a surprise. I wish the developers of c++11 
runtime use valgrind/memcheck during their development cycle. Maybe they 
use addresssanitizer and don't pay attention to the free vs delete issue 
much.

Just my two cents worth.

CI



On 2016/01/19 7:13, ISHIKAWA,chiaki wrote:
> On 2016/01/18 23:32, Julian Seward wrote:
>> Chiaki,
>>
>>> First of all, thank you for sharing this great package.
>> First of all, thank you for supporting Thunderbird.  I use it all the time.
>>
>>> --11405-- WARNING: Serious error when reading debug info
>>> --11405-- When reading debug info from
>>> /usr/lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0.3200.3:
>>> --11405-- Ignoring non-Dwarf2/3/4 block in .debug_info
>> Hmm.  That is pretty strange.  Can you send by email (not to the
>> list) a copy of this libgdk_pixbuf-2.0.so.0.3200.3, for investigation?
>>
>> J
> Yes, I will.
>
> Chiaki
>
>
>
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>
>

Re: [Valgrind-users] Strange warning: Ignoring non-Dwarf2/3/4 block in .debug_info

[Philippe W. <phi...@sk...>]

On Thu, 2016-01-28 at 02:19 +0900, ISHIKAWA,chiaki wrote:
> c++11 runtime seems to use |new| operation to create some data in a very 
> primitive internal string handling function, and these string data are 
> "free"ed by many other functions that my application (mozilla 
> thunderbird) use. So delete vs free issues are reported. I suspect c++11 
> ought to use "malloc()" for the internal string operation, but then 
> maybe other parts of c++11 library may complain about malloc vs delete 
> mismatch then :-(
Some such false positive of 'mismatched malloc/free/new/delete'
were found in the past due to one operation being inlined
(e.g. the new) but the delete not being inlined.
The matching code does not understand inlining, and so the false
positive.

Maybe that is your case ?
(you might check this by showing the stacktrace for the allocation
and deallocation using e.g. gdb+vgdb, and see if inlining enters in
the game).

Philippe

Re: [Valgrind-users] Strange warning: Ignoring non-Dwarf2/3/4 block in .debug_info

[ISHIKAWA,chiaki <ish...@yk...>]

On 2016/01/28 7:06, Philippe Waroquiers wrote:
> On Thu, 2016-01-28 at 02:19 +0900, ISHIKAWA,chiaki wrote:
>> c++11 runtime seems to use |new| operation to create some data in a very
>> primitive internal string handling function, and these string data are
>> "free"ed by many other functions that my application (mozilla
>> thunderbird) use. So delete vs free issues are reported. I suspect c++11
>> ought to use "malloc()" for the internal string operation, but then
>> maybe other parts of c++11 library may complain about malloc vs delete
>> mismatch then :-(
> Some such false positive of 'mismatched malloc/free/new/delete'
> were found in the past due to one operation being inlined
> (e.g. the new) but the delete not being inlined.
> The matching code does not understand inlining, and so the false
> positive.
>
> Maybe that is your case ?
> (you might check this by showing the stacktrace for the allocation
> and deallocation using e.g. gdb+vgdb, and see if inlining enters in
> the game).
>
> Philippe

Thank you for the tips.

I will investigate this issue further along your suggestions.
I can whitelist typical noises by using suppression file, but
to think the valgrind/memcheck needs to check this and notice the 
anomaly, check the
backtrace of calls to malloc/new to report it and only then learns it is 
whitelisted, and moves on to the original execution: such a waste of 
runtime CPU (!).
Actually, I think I already notice a significant slowdown due to this 
added mismatches.
Or maybe I am hallucinating and in need of a faster CPU :-)

But if the issue is the unbalanced inlining, there is a hope that I can 
either fix the
local build environment to inline both new/delete, etc., or try 
contacting the library builders to fix their
toolchain setup.

CI