Bug 1090505 - perl-Test-Valgrind arch-specific failures (i686, ppc ok; x86_64, ppc64, armv7hl fail)
Summary: perl-Test-Valgrind arch-specific failures (i686, ppc ok; x86_64, ppc64, armv7...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: valgrind
Version: 22
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Mark Wielaard
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 1358709
TreeView+ depends on / blocked
 
Reported: 2014-04-23 13:37 UTC by Paul Howarth
Modified: 2016-07-21 10:17 UTC (History)
3 users (show)

Fixed In Version:
Clone Of:
: 1358709 (view as bug list)
Environment:
Last Closed: 2016-07-19 11:24:03 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
armv7hl build log (18.01 KB, text/x-log)
2014-04-23 13:37 UTC, Paul Howarth
no flags Details
i686 build log (20.47 KB, text/plain)
2014-04-23 13:38 UTC, Paul Howarth
no flags Details
ppc build log (20.31 KB, text/plain)
2014-04-23 13:38 UTC, Paul Howarth
no flags Details
ppc64 build log (320.98 KB, text/plain)
2014-04-23 13:39 UTC, Paul Howarth
no flags Details
x86_64 build log (17.98 KB, text/plain)
2014-04-23 13:39 UTC, Paul Howarth
no flags Details


Links
System ID Private Priority Status Summary Last Updated
CPAN 101934 0 None None None Never

Description Paul Howarth 2014-04-23 13:37:34 UTC
Created attachment 888913 [details]
armv7hl build log

I'm seeing build failures for perl-Test-Valgrind in some architectures in Rawhide, where the same builds in F20 complete successfully.

It appears that i686 and ppc builds still work OK in Rawhide.

For x86_64 and armv7hl, the test suite fails to detect a deliberately malloc-ed but not free-d 10000 byte chunk of memory.

For ppc64, the leak is detected but other (false positive?) errors are detected in both the expected-good and expected-bad tests (accesses to uninitialised data). It might possibly be that this case is a side-effect of a glibc ABI change in Rawhide coupled with out-of-order rebuilding of packages in the perl stack for a secondary architecture, like Bug #1064271, but that's speculation on my part.

I'm able to reproduce the x86_64 failure locally, and have tried running the f20 valgrind rebuilt for Rawhide, which didn't prevent the failure, so I don't think the problem is in valgrind itself. I don't know how to proceed with debugging this though - any ideas?

Comment 1 Paul Howarth 2014-04-23 13:38:13 UTC
Created attachment 888914 [details]
i686 build log

Comment 2 Paul Howarth 2014-04-23 13:38:47 UTC
Created attachment 888915 [details]
ppc build log

Comment 3 Paul Howarth 2014-04-23 13:39:17 UTC
Created attachment 888916 [details]
ppc64 build log

Comment 4 Paul Howarth 2014-04-23 13:39:59 UTC
Created attachment 888917 [details]
x86_64 build log

Comment 5 Mark Wielaard 2014-09-11 11:41:48 UTC
Sorry I missed this report before.

I tried to do a mock rebuild of perl-Test-Valgrind/perl-Test-Valgrind-1.14-3.fc22.src.rpm against the latest rawhide version of valgrind (valgrind-3.10.0.BETA2) and that seems to pass. The build.log has:

# Testing Test::Valgrind 1.14, Perl 5.020000, /usr/bin/perl
t/00-load.t ................... ok
# Using valgrind 3.10.0 located at /usr/bin/valgrind
# Generating suppressions...
# Suppressions for this perl stored in /builddir/.perl/Test-Valgrind/suppressions/1.14/memcheck-3.10.0-40ae5dc21acf78bf5a92a5091b633e26.supp
# Using suppression file /builddir/.perl/Test-Valgrind/suppressions/1.14/memcheck-3.10.0-40ae5dc21acf78bf5a92a5091b633e26.supp
t/10-good.t ................... ok
# Using valgrind 3.10.0 located at /usr/bin/valgrind
# Using suppression file /builddir/.perl/Test-Valgrind/suppressions/1.14/memcheck-3.10.0-40ae5dc21acf78bf5a92a5091b633e26.supp
# The subsequent report was correctly caught:
#   10,000 bytes in 1 blocks are still reachable in loss record 6 of 6
#     malloc (/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) [?:?]
#     tv_leak (/builddir/build/BUILD/Test-Valgrind-1.14/blib/arch/auto/Test/Valgrind/Valgrind.so) [Valgrind.xs:22]
#     XS_Test__Valgrind_leak (/builddir/build/BUILD/Test-Valgrind-1.14/blib/arch/auto/Test/Valgrind/Valgrind.so) [Valgrind.xs:42]
#     Perl_pp_entersub (/usr/lib64/libperl.so.5.20.0) [?:?]
#     Perl_runops_standard (/usr/lib64/libperl.so.5.20.0) [?:?]
#     perl_run (/usr/lib64/libperl.so.5.20.0) [?:?]
#     ? (/usr/bin/perl) [?:?]
#     (below main) (/usr/lib64/libc-2.20.90.so) [?:?]
t/20-bad.t .................... ok
t/70-session.t ................ ok
# 18 suppressions, of which 18 are not empty
t/80-suppressions.t ........... ok
t/81-suppressions-demangle.t .. ok
All tests successful.
Files=6, Tests=58, 11 wallclock secs ( 0.02 usr  0.00 sys +  9.03 cusr  0.14 csys =  9.19 CPU)
Result: PASS
+ exit 0

Are you still seeing the issue?

Comment 6 Paul Howarth 2014-09-11 13:26:51 UTC
ppc64 build still fails:

http://ppc.koji.fedoraproject.org/kojifiles/work/tasks/1210/2101210/build.log

aarch64 also fails but that looks to be unrelated to valgrind:

http://arm.koji.fedoraproject.org//work/tasks/8698/2658698/build.log

Comment 7 Mark Wielaard 2014-09-11 14:14:42 UTC
(In reply to Paul Howarth from comment #6)
> ppc64 build still fails:
> 
> http://ppc.koji.fedoraproject.org/kojifiles/work/tasks/1210/2101210/build.log

Thanks, that looks like it missed the intercept of the ifunc version of strlen. That was supposed to be fixed in 3.10.0. I'll investigate.

Did you happen to have a build on ppc64le too?

Comment 8 Paul Howarth 2014-09-11 14:21:32 UTC
I tried that but it couldn't find valgrind >= 3.1.0 to build with:

http://ppc.koji.fedoraproject.org/kojifiles/work/tasks/1262/2101262/root.log

Comment 9 Mark Wielaard 2014-09-11 15:00:16 UTC
(In reply to Paul Howarth from comment #8)
> I tried that but it couldn't find valgrind >= 3.1.0 to build with:
> 
> http://ppc.koji.fedoraproject.org/kojifiles/work/tasks/1262/2101262/root.log

That is odd. And now that I am looking at the root.log of the ppc64 build I see it used valgrind.ppc64 1:3.9.0-16.svn20140513r13961.fc21
That is a very old (pre-release) version. Only after 3.9.0-18.svn20140715r14165 was the ppc64-ifunc bug fixed (that was July 15 2014). I'll ping the ppc koji hackers to see if we can get something newer in the build roots.

Comment 10 Mark Wielaard 2014-09-18 13:59:26 UTC
The ppc hackers were nice enough to do a fresh valgrind-3.10.0-1.fc21 build for ppc64/ppc64le: http://ppc.koji.fedoraproject.org/koji/buildinfo?buildID=265823

That should also be in the f21-overrides for now (because of the alpha freeze no packages get updated atm).

Could you try doing a build against f21 ppc now to see if that solves the issue?

Comment 12 Paul Howarth 2014-09-19 15:37:02 UTC
Another data point: use of Test::Valgrind in perl-Test-LeakTrace's test suite fails on f22 ppc64 (f21 builds OK):

http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=2111720
http://ppc.koji.fedoraproject.org/kojifiles/work/tasks/1721/2111721/build.log

Also there seems to be no ppc64le valgrind for f22, though the f21 version seems OK.

Comment 13 Mark Wielaard 2014-09-19 19:11:36 UTC
(In reply to Paul Howarth from comment #12)
> Another data point: use of Test::Valgrind in perl-Test-LeakTrace's test
> suite fails on f22 ppc64 (f21 builds OK):
> 
> http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=2111720
> http://ppc.koji.fedoraproject.org/kojifiles/work/tasks/1721/2111721/build.log
> 
> Also there seems to be no ppc64le valgrind for f22, though the f21 version
> seems OK.

yeah, note that on ppc f22/rawhide seems to come with a really old version (or none at all for ppc64le). The root.log says it installed 3.9.0-16.svn20140513r13961.fc21 which is a known bad version for ppc64[be] because of a change in glibc to use ifuncs (which weren't properly supported in that version of valgrind). So till f22/rawhide gets updated I wouldn't worry about that.

We should figure out the arm issue though. I haven't yet had time to try and build it in a mock setup.

Comment 14 Mark Wielaard 2014-09-19 21:16:51 UTC
(In reply to Mark Wielaard from comment #13)
> We should figure out the arm issue though. I haven't yet had time to try and
> build it in a mock setup.

I can replicate the failure in a mock setup on arm:

[root@trimslice Test-Valgrind-1.14]# make test
PERL_DL_NONLAZY=1 /usr/bin/perl "-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef *Test::Harness::Switches; test_harness(0, 'blib/lib', 'blib/arch')" t/*.t
t/00-load.t ................... 1/1 # Testing Test::Valgrind 1.14, Perl 5.018002, /usr/bin/perl
t/00-load.t ................... ok   
t/10-good.t ................... # Using valgrind 3.10.0 located at /usr/bin/valgrind
# Using suppression file /builddir/.perl/Test-Valgrind/suppressions/1.14/memcheck-3.10.0-7e79e7ee027fc3eab543608c997d8318.supp
t/10-good.t ................... ok     
t/20-bad.t .................... # Using valgrind 3.10.0 located at /usr/bin/valgrind
# Using suppression file /builddir/.perl/Test-Valgrind/suppressions/1.14/memcheck-3.10.0-7e79e7ee027fc3eab543608c997d8318.supp
t/20-bad.t .................... 1/17 # Looks like you planned 17 tests but ran 15.
t/20-bad.t .................... Dubious, test returned 255 (wstat 65280, 0xff00)
Failed 2/17 subtests 
t/70-session.t ................ ok   
t/80-suppressions.t ........... 1/4 # 36 suppressions, of which 36 are not empty
t/80-suppressions.t ........... ok   
t/81-suppressions-demangle.t .. ok     

Test Summary Report
-------------------
t/20-bad.t                  (Wstat: 65280 Tests: 15 Failed: 0)
  Non-zero exit status: 255
  Parse errors: Bad plan.  You planned 17 tests but ran 15.
Files=6, Tests=56, 43 wallclock secs ( 0.20 usr  0.04 sys + 40.74 cusr  1.83 csys = 42.81 CPU)
Result: FAIL
Failed 1/6 test programs. 0/56 subtests failed.
Makefile:1061: recipe for target 'test_dynamic' failed
make: *** [test_dynamic] Error 255


But I don't know where to look see what really went wrong.
Are there log files that would give a bit more output?

Comment 15 Paul Howarth 2014-09-20 12:52:55 UTC
I did a build with TEST_VERBOSE=1 but that didn't help much. It seems it's expecting to run an extra two tests at the end of 20-bad.t but doesn't actually run them:

https://kojipkgs.fedoraproject.org//work/tasks/9902/7639902/build.log

Don't really know why that's happening.

Comment 16 Mark Wielaard 2014-09-20 19:02:09 UTC
Sorry, my perl foo is too weak to fully understand what is going on in this test framework. Could you contact upstream to ask if they can help us figure out what really is failing?

Comment 17 Jaroslav Reznik 2015-03-03 15:43:29 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle.
Changing version to '22'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22

Comment 18 Paul Howarth 2015-11-03 14:34:56 UTC
Got a response from upstream:

  "It appears that the suppression file generated by the module only contains
   generic stack frames and no reference whatsoever to any perl related symbol.
   This is why the malloc() call in the test XS code is ignored by valgrind,
   hence t/20-bad.t fails."

  "This probably happens because your perl binary was stripped. The module has
   no chance to work with such a perl, because either it ignores the
   suppressions but reports perl internal leaks, or it uses the bogus
   suppression file and will never report anything (what happens now)."

This can be seen in the following builds, where I did a "cat" of the generated suppression files:

armv7hl build:
https://kojipkgs.fedoraproject.org//work/tasks/3180/11653180/build.log

same package build on x86_64 for comparison:
https://kojipkgs.fedoraproject.org//work/tasks/3181/11653181/build.log

Any ideas why the arm build should be different?

Comment 19 Paul Howarth 2015-11-10 14:07:51 UTC
Here's an illustration on a working arch (x86_64):
$/usr/bin/valgrind --leak-check=full --show-reachable=yes --leak-resolution=high /usr/bin/perl -Mblib -e 'use Perl::Destruct::Level level => 3; use XSLoader; XSLoader::load("Test::Valgrind", "1.15"); Test::Valgrind::leak()'
==26482== Memcheck, a memory error detector
==26482== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==26482== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==26482== Command: /usr/bin/perl -Mblib -e use\ Perl::Destruct::Level\ level\ =\>\ 3;\ use\ XSLoader;\ XSLoader::load("Test::Valgrind",\ "1.15");\ Test::Valgrind::leak()
==26482== 
==26482== 
==26482== HEAP SUMMARY:
==26482==     in use at exit: 14,394 bytes in 14 blocks
==26482==   total heap usage: 16,020 allocs, 16,006 frees, 4,685,078 bytes allocated
==26482== 
==26482== 32 bytes in 1 blocks are still reachable in loss record 1 of 6
==26482==    at 0x4C2F9C7: calloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==26482==    by 0x58716E6: _dlerror_run (in /usr/lib64/libdl-2.22.90.so)
==26482==    by 0x5871060: dlopen@@GLIBC_2.2.5 (in /usr/lib64/libdl-2.22.90.so)
==26482==    by 0x4FA7CEB: XS_DynaLoader_dl_load_file (in /usr/lib64/libperl.so.5.22.0)
==26482==    by 0x4F0FDF9: Perl_pp_entersub (in /usr/lib64/libperl.so.5.22.0)
==26482==    by 0x4F08B35: Perl_runops_standard (in /usr/lib64/libperl.so.5.22.0)
==26482==    by 0x4E8DC65: Perl_call_sv (in /usr/lib64/libperl.so.5.22.0)
==26482==    by 0x4E8FFC2: Perl_call_list (in /usr/lib64/libperl.so.5.22.0)
==26482==    by 0x4E6F6EA: ??? (in /usr/lib64/libperl.so.5.22.0)
==26482==    by 0x4E8675B: Perl_newATTRSUB_x (in /usr/lib64/libperl.so.5.22.0)
==26482==    by 0x4E8A2AB: Perl_utilize (in /usr/lib64/libperl.so.5.22.0)
==26482==    by 0x4EBE286: Perl_yyparse (in /usr/lib64/libperl.so.5.22.0)
==26482== 
==26482== 190 bytes in 3 blocks are still reachable in loss record 2 of 6
==26482==    at 0x4C2DC50: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==26482==    by 0x401CB79: strdup (in /usr/lib64/ld-2.22.90.so)
==26482==    by 0x4008AEE: _dl_map_object (in /usr/lib64/ld-2.22.90.so)
==26482==    by 0x40153F9: dl_open_worker (in /usr/lib64/ld-2.22.90.so)
==26482==    by 0x40103C3: _dl_catch_error (in /usr/lib64/ld-2.22.90.so)
==26482==    by 0x4014C28: _dl_open (in /usr/lib64/ld-2.22.90.so)
==26482==    by 0x5870FC8: dlopen_doit (in /usr/lib64/libdl-2.22.90.so)
==26482==    by 0x40103C3: _dl_catch_error (in /usr/lib64/ld-2.22.90.so)
==26482==    by 0x5871630: _dlerror_run (in /usr/lib64/libdl-2.22.90.so)
==26482==    by 0x5871060: dlopen@@GLIBC_2.2.5 (in /usr/lib64/libdl-2.22.90.so)
==26482==    by 0x4FA7CEB: XS_DynaLoader_dl_load_file (in /usr/lib64/libperl.so.5.22.0)
==26482==    by 0x4F0FDF9: Perl_pp_entersub (in /usr/lib64/libperl.so.5.22.0)
==26482== 
==26482== 190 bytes in 3 blocks are still reachable in loss record 3 of 6
==26482==    at 0x4C2DC50: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==26482==    by 0x400BDD3: _dl_new_object (in /usr/lib64/ld-2.22.90.so)
==26482==    by 0x400627C: _dl_map_object_from_fd (in /usr/lib64/ld-2.22.90.so)
==26482==    by 0x4008B6D: _dl_map_object (in /usr/lib64/ld-2.22.90.so)
==26482==    by 0x40153F9: dl_open_worker (in /usr/lib64/ld-2.22.90.so)
==26482==    by 0x40103C3: _dl_catch_error (in /usr/lib64/ld-2.22.90.so)
==26482==    by 0x4014C28: _dl_open (in /usr/lib64/ld-2.22.90.so)
==26482==    by 0x5870FC8: dlopen_doit (in /usr/lib64/libdl-2.22.90.so)
==26482==    by 0x40103C3: _dl_catch_error (in /usr/lib64/ld-2.22.90.so)
==26482==    by 0x5871630: _dlerror_run (in /usr/lib64/libdl-2.22.90.so)
==26482==    by 0x5871060: dlopen@@GLIBC_2.2.5 (in /usr/lib64/libdl-2.22.90.so)
==26482==    by 0x4FA7CEB: XS_DynaLoader_dl_load_file (in /usr/lib64/libperl.so.5.22.0)
==26482== 
==26482== 288 bytes in 3 blocks are still reachable in loss record 4 of 6
==26482==    at 0x4C2F9C7: calloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==26482==    by 0x4011F3D: _dl_check_map_versions (in /usr/lib64/ld-2.22.90.so)
==26482==    by 0x40159A8: dl_open_worker (in /usr/lib64/ld-2.22.90.so)
==26482==    by 0x40103C3: _dl_catch_error (in /usr/lib64/ld-2.22.90.so)
==26482==    by 0x4014C28: _dl_open (in /usr/lib64/ld-2.22.90.so)
==26482==    by 0x5870FC8: dlopen_doit (in /usr/lib64/libdl-2.22.90.so)
==26482==    by 0x40103C3: _dl_catch_error (in /usr/lib64/ld-2.22.90.so)
==26482==    by 0x5871630: _dlerror_run (in /usr/lib64/libdl-2.22.90.so)
==26482==    by 0x5871060: dlopen@@GLIBC_2.2.5 (in /usr/lib64/libdl-2.22.90.so)
==26482==    by 0x4FA7CEB: XS_DynaLoader_dl_load_file (in /usr/lib64/libperl.so.5.22.0)
==26482==    by 0x4F0FDF9: Perl_pp_entersub (in /usr/lib64/libperl.so.5.22.0)
==26482==    by 0x4F08B35: Perl_runops_standard (in /usr/lib64/libperl.so.5.22.0)
==26482== 
==26482== 3,694 bytes in 3 blocks are still reachable in loss record 5 of 6
==26482==    at 0x4C2F9C7: calloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==26482==    by 0x400BAD5: _dl_new_object (in /usr/lib64/ld-2.22.90.so)
==26482==    by 0x400627C: _dl_map_object_from_fd (in /usr/lib64/ld-2.22.90.so)
==26482==    by 0x4008B6D: _dl_map_object (in /usr/lib64/ld-2.22.90.so)
==26482==    by 0x40153F9: dl_open_worker (in /usr/lib64/ld-2.22.90.so)
==26482==    by 0x40103C3: _dl_catch_error (in /usr/lib64/ld-2.22.90.so)
==26482==    by 0x4014C28: _dl_open (in /usr/lib64/ld-2.22.90.so)
==26482==    by 0x5870FC8: dlopen_doit (in /usr/lib64/libdl-2.22.90.so)
==26482==    by 0x40103C3: _dl_catch_error (in /usr/lib64/ld-2.22.90.so)
==26482==    by 0x5871630: _dlerror_run (in /usr/lib64/libdl-2.22.90.so)
==26482==    by 0x5871060: dlopen@@GLIBC_2.2.5 (in /usr/lib64/libdl-2.22.90.so)
==26482==    by 0x4FA7CEB: XS_DynaLoader_dl_load_file (in /usr/lib64/libperl.so.5.22.0)
==26482== 
==26482== 10,000 bytes in 1 blocks are still reachable in loss record 6 of 6
==26482==    at 0x4C2DC50: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==26482==    by 0x7400BCD: tv_leak (Valgrind.xs:34)
==26482==    by 0x7400C1B: XS_Test__Valgrind_leak (Valgrind.xs:54)
==26482==    by 0x4F0FDF9: Perl_pp_entersub (in /usr/lib64/libperl.so.5.22.0)
==26482==    by 0x4F08B35: Perl_runops_standard (in /usr/lib64/libperl.so.5.22.0)
==26482==    by 0x4E95412: perl_run (in /usr/lib64/libperl.so.5.22.0)
==26482==    by 0x400D78: ??? (in /usr/bin/perl)
==26482==    by 0x61D477F: (below main) (in /usr/lib64/libc-2.22.90.so)
==26482== 
==26482== LEAK SUMMARY:
==26482==    definitely lost: 0 bytes in 0 blocks
==26482==    indirectly lost: 0 bytes in 0 blocks
==26482==      possibly lost: 0 bytes in 0 blocks
==26482==    still reachable: 14,394 bytes in 14 blocks
==26482==         suppressed: 0 bytes in 0 blocks
==26482== 
==26482== For counts of detected and suppressed errors, rerun with: -v
==26482== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

And the same thing on armv7hl:
$ /usr/bin/valgrind --leak-check=full --show-reachable=yes --leak-resolution=high /usr/bin/perl -Mblib -e 'use Perl::Destruct::Level level => 3; use XSLoader; XSLoader::load("Test::Valgrind", "1.15"); Test::Valgrind::leak()'
==28714== Memcheck, a memory error detector
==28714== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==28714== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==28714== Command: /usr/bin/perl -Mblib -e use\ Perl::Destruct::Level\ level\ =\>\ 3;\ use\ XSLoader;\ XSLoader::load("Test::Valgrind",\ "1.15");\ Test::Valgrind::leak()
==28714== 
==28714== Invalid read of size 4
==28714==    at 0x401C504: index (in /usr/lib/ld-2.22.90.so)
==28714==  Address 0x4ed4c74 is 0 bytes after a block of size 44 alloc'd
==28714==    at 0x484BC98: realloc (in /usr/lib/valgrind/vgpreload_memcheck-arm-linux.so)
==28714== 
==28714== Conditional jump or move depends on uninitialised value(s)
==28714==    at 0x401C504: index (in /usr/lib/ld-2.22.90.so)
==28714== 
==28714== Conditional jump or move depends on uninitialised value(s)
==28714==    at 0x401C508: index (in /usr/lib/ld-2.22.90.so)
==28714== 
==28714== Conditional jump or move depends on uninitialised value(s)
==28714==    at 0x4016B00: dl_open_worker (in /usr/lib/ld-2.22.90.so)
==28714== 
==28714== Conditional jump or move depends on uninitialised value(s)
==28714==    at 0x400972C: _dl_map_object (in /usr/lib/ld-2.22.90.so)
==28714==    by 0x4016B5B: dl_open_worker (in /usr/lib/ld-2.22.90.so)
==28714== 
==28714== 
==28714== HEAP SUMMARY:
==28714==     in use at exit: 12,634 bytes in 14 blocks
==28714==   total heap usage: 15,994 allocs, 15,980 frees, 2,722,468 bytes allocated
==28714== 
==28714== 2,262 bytes in 7 blocks are still reachable in loss record 1 of 2
==28714==    at 0x484BA38: calloc (in /usr/lib/valgrind/vgpreload_memcheck-arm-linux.so)
==28714== 
==28714== 10,372 bytes in 7 blocks are still reachable in loss record 2 of 2
==28714==    at 0x4849498: malloc (in /usr/lib/valgrind/vgpreload_memcheck-arm-linux.so)
==28714== 
==28714== LEAK SUMMARY:
==28714==    definitely lost: 0 bytes in 0 blocks
==28714==    indirectly lost: 0 bytes in 0 blocks
==28714==      possibly lost: 0 bytes in 0 blocks
==28714==    still reachable: 12,634 bytes in 14 blocks
==28714==         suppressed: 0 bytes in 0 blocks
==28714== 
==28714== For counts of detected and suppressed errors, rerun with: -v
==28714== Use --track-origins=yes to see where uninitialised values come from
==28714== ERROR SUMMARY: 14 errors from 5 contexts (suppressed: 0 from 0)

Nothing detected from perl there. Any idea why that should be?

Comment 20 Mark Wielaard 2015-11-12 10:34:41 UTC
Looking at the generated suppression files the x86_64 one is very specific about the leaks being suppressed with a long stack trace all starting at XS_DynaLoader_dl_load_file. Which makes sense. There are some expected leaks for the dynamicly loaded library.

The arm7hl one however is very generic missing most/all of the stack trace. I guess valgrind is unable to properly unwind on this architecture and so cannot generate a proper suppression file. The suppressions being so generic (basically ignore any leak caused by malloc...) probably explain why there is no output at all.

So the real bug is that valgrind is unable to unwind properly on arm.

I am also surprised by that Invalid read of size 4 at 0x401C504: index (in /usr/lib/ld-2.22.90.so). I believe that is a new issue on rawhide with newer glibc/ld.so.

Comment 21 Paul Howarth 2015-11-12 10:48:26 UTC
(In reply to Mark Wielaard from comment #20)
> I am also surprised by that Invalid read of size 4 at 0x401C504: index (in
> /usr/lib/ld-2.22.90.so). I believe that is a new issue on rawhide with newer
> glibc/ld.so.

Not just rawhide - same thing on F-23:
https://kojipkgs.fedoraproject.org//work/tasks/1686/11801686/build.log

$ /usr/bin/valgrind --leak-check=full --show-reachable=yes --leak-resolution=high /usr/bin/perl -Mblib -e 'use Perl::Destruct::Level level => 3; use XSLoader; XSLoader::load("Test::Valgrind", "1.15"); Test::Valgrind::leak()'
==23281== Memcheck, a memory error detector
==23281== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==23281== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==23281== Command: /usr/bin/perl -Mblib -e use\ Perl::Destruct::Level\ level\ =\>\ 3;\ use\ XSLoader;\ XSLoader::load("Test::Valgrind",\ "1.15");\ Test::Valgrind::leak()
==23281== 
==23281== Invalid read of size 4
==23281==    at 0x401A7A4: index (in /usr/lib/ld-2.22.so)
==23281==  Address 0x4ec2c74 is 0 bytes after a block of size 44 alloc'd
==23281==    at 0x4848C98: realloc (in /usr/lib/valgrind/vgpreload_memcheck-arm-linux.so)
==23281== 
==23281== Conditional jump or move depends on uninitialised value(s)
==23281==    at 0x401A7A4: index (in /usr/lib/ld-2.22.so)
==23281== 
==23281== Conditional jump or move depends on uninitialised value(s)
==23281==    at 0x401A7A8: index (in /usr/lib/ld-2.22.so)
==23281== 
==23281== Conditional jump or move depends on uninitialised value(s)
==23281==    at 0x4014E98: dl_open_worker (in /usr/lib/ld-2.22.so)
==23281== 
==23281== Conditional jump or move depends on uninitialised value(s)
==23281==    at 0x4008B64: _dl_map_object (in /usr/lib/ld-2.22.so)
==23281==    by 0x4014F9F: dl_open_worker (in /usr/lib/ld-2.22.so)
==23281== 
==23281== 
==23281== HEAP SUMMARY:
==23281==     in use at exit: 12,634 bytes in 14 blocks
==23281==   total heap usage: 15,992 allocs, 15,978 frees, 2,722,438 bytes allocated
==23281== 
==23281== 2,262 bytes in 7 blocks are still reachable in loss record 1 of 2
==23281==    at 0x4848A38: calloc (in /usr/lib/valgrind/vgpreload_memcheck-arm-linux.so)
==23281== 
==23281== 10,372 bytes in 7 blocks are still reachable in loss record 2 of 2
==23281==    at 0x4846498: malloc (in /usr/lib/valgrind/vgpreload_memcheck-arm-linux.so)
==23281== 
==23281== LEAK SUMMARY:
==23281==    definitely lost: 0 bytes in 0 blocks
==23281==    indirectly lost: 0 bytes in 0 blocks
==23281==      possibly lost: 0 bytes in 0 blocks
==23281==    still reachable: 12,634 bytes in 14 blocks
==23281==         suppressed: 0 bytes in 0 blocks
==23281== 
==23281== For counts of detected and suppressed errors, rerun with: -v
==23281== Use --track-origins=yes to see where uninitialised values come from
==23281== ERROR SUMMARY: 14 errors from 5 contexts (suppressed: 0 from 0)

Comment 22 Paul Howarth 2015-11-12 10:57:21 UTC
And F22:
https://kojipkgs.fedoraproject.org//work/tasks/1872/11801872/build.log

$ /usr/bin/valgrind --leak-check=full --show-reachable=yes --leak-resolution=high /usr/bin/perl -Mblib -e 'use Perl::Destruct::Level level => 3; use XSLoader; XSLoader::load("Test::Valgrind", "1.15"); Test::Valgrind::leak()'
==14038== Memcheck, a memory error detector
==14038== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==14038== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==14038== Command: /usr/bin/perl -Mblib -e use\ Perl::Destruct::Level\ level\ =\>\ 3;\ use\ XSLoader;\ XSLoader::load("Test::Valgrind",\ "1.15");\ Test::Valgrind::leak()
==14038== 
==14038== Invalid read of size 4
==14038==    at 0x401A0E4: index (in /usr/lib/ld-2.21.so)
==14038==  Address 0x4e71c34 is 0 bytes after a block of size 44 alloc'd
==14038==    at 0x4847C98: realloc (in /usr/lib/valgrind/vgpreload_memcheck-arm-linux.so)
==14038== 
==14038== Conditional jump or move depends on uninitialised value(s)
==14038==    at 0x401A0E4: index (in /usr/lib/ld-2.21.so)
==14038== 
==14038== Conditional jump or move depends on uninitialised value(s)
==14038==    at 0x401A0E8: index (in /usr/lib/ld-2.21.so)
==14038== 
==14038== Conditional jump or move depends on uninitialised value(s)
==14038==    at 0x4014AD4: dl_open_worker (in /usr/lib/ld-2.21.so)
==14038== 
==14038== Conditional jump or move depends on uninitialised value(s)
==14038==    at 0x4008AAC: _dl_map_object (in /usr/lib/ld-2.21.so)
==14038==    by 0x4014BDB: dl_open_worker (in /usr/lib/ld-2.21.so)
==14038== 
==14038== 
==14038== HEAP SUMMARY:
==14038==     in use at exit: 12,634 bytes in 14 blocks
==14038==   total heap usage: 14,260 allocs, 14,246 frees, 2,438,349 bytes allocated
==14038== 
==14038== 2,262 bytes in 7 blocks are still reachable in loss record 1 of 2
==14038==    at 0x4847A38: calloc (in /usr/lib/valgrind/vgpreload_memcheck-arm-linux.so)
==14038== 
==14038== 10,372 bytes in 7 blocks are still reachable in loss record 2 of 2
==14038==    at 0x4845498: malloc (in /usr/lib/valgrind/vgpreload_memcheck-arm-linux.so)
==14038== 
==14038== LEAK SUMMARY:
==14038==    definitely lost: 0 bytes in 0 blocks
==14038==    indirectly lost: 0 bytes in 0 blocks
==14038==      possibly lost: 0 bytes in 0 blocks
==14038==    still reachable: 12,634 bytes in 14 blocks
==14038==         suppressed: 0 bytes in 0 blocks
==14038== 
==14038== For counts of detected and suppressed errors, rerun with: -v
==14038== Use --track-origins=yes to see where uninitialised values come from
==14038== ERROR SUMMARY: 14 errors from 5 contexts (suppressed: 0 from 0)

Comment 23 Mark Wielaard 2015-11-12 11:02:56 UTC
> Not just rawhide - same thing on F-23:
> https://kojipkgs.fedoraproject.org//work/tasks/1686/11801686/build.log

(In reply to Paul Howarth from comment #22)
> And F22:
> https://kojipkgs.fedoraproject.org//work/tasks/1872/11801872/build.log

hohum. Thanks for checking. That is bad :{
It isn't helped by the fact that valgrind clearly doesn't generate a proper backtrace, so it isn't exactly clear where this index call originated from. But it seems we have at least two bugs on arm then. I'll investigate deeper once I have access to an arm setup.

Comment 24 Fedora End Of Life 2016-07-19 11:24:03 UTC
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Comment 25 Paul Howarth 2016-07-19 12:43:02 UTC
Just had a quick look at this and it appears that we're still not getting proper backtraces on arm, but the test suite has been modified to make it more robust against this and hence it no longer causes build failures.

So I'll leave it closed, and maybe a separate bug could be opened for the arm backtrace issue?


Note You need to log in before you can comment on or make changes to this bug.