The problem is in interaction between libdwfl and libelf.  For non-native core dumps, dwfl_segment_report_module issues elf32_xlatetom on data of each note.  elf32_xlatetom checks, whether the data contains an integer number of records.  But I don't think it is right to do that for notes, as the payload bytes follow the header bytes, it's not an array of records as is the case otherwise.  So how about this?

diff -up elfutils-0.154/libelf/elf32_xlatetom.c\~ elfutils-0.154/libelf/elf32_xlatetom.c
--- elfutils-0.154/libelf/elf32_xlatetom.c~	2012-06-22 14:25:41 +0200
+++ elfutils-0.154/libelf/elf32_xlatetom.c	2012-06-28 14:59:37 +0200
@@ -59,7 +59,8 @@ elfw2(LIBELFBITS, xlatetom) (dest, src, 
 #endif
 
 
-  if (src->d_size % recsize != 0)
+  if (src->d_type != ELF_T_NHDR
+      && src->d_size % recsize != 0)
     {
       __libelf_seterrno (ELF_E_INVALID_DATA);
       return NULL;

Maybe with an explanatory comment.

*** Bug 836297 has been marked as a duplicate of this bug. ***

any updates here as this is blocking quite a few builds on s390* and ppc* ?

(In reply to comment #3)
> any updates here as this is blocking quite a few builds on s390* and ppc* ?

Sorry, I hadn't realized this was blocking. Currently on vacation without access to real development machines (will go the GNU Tools Cauldron afterwards). If you need a build of 0.154 for an architecture that doesn't have a clean test result flip the %global nocheck to true in elfutils.spec (or make a special patch for the particular test in question like elfutils-0.154-binutils-pr-ld-13621.patch).

Note that the testcase is new and checks whether the fix for RHBZ#805447 is correct. So it isn't really a regression.

no problem, I'll exclude that particular test on the failing arches.
Enjoy your vacation!

(In reply to comment #5)
> no problem, I'll exclude that particular test on the failing arches.
> Enjoy your vacation!

thanks, I also prefer disable just the particular test

elfutils-0.154-1.1.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/elfutils-0.154-1.1.fc17

(In reply to comment #1)

The change looks fine to me if it gets a comment.
But as a general thing, I think patch review should be done over the mailing list rather than bugzilla.

Petr's patch was committed upstream. I created packages with it backported (and enabled the testcase again) as elfutils-0.154-2.fc18. Do the ppc and s390 koji builders pick that one up automagically?

(In reply to comment #9)
> Petr's patch was committed upstream. I created packages with it backported
> (and enabled the testcase again) as elfutils-0.154-2.fc18. Do the ppc and
> s390 koji builders pick that one up automagically?

yes, they will pick the new build automagically

(In reply to comment #10)
> (In reply to comment #9)
> > Petr's patch was committed upstream. I created packages with it backported
> > (and enabled the testcase again) as elfutils-0.154-2.fc18. Do the ppc and
> > s390 koji builders pick that one up automagically?
> 
> yes, they will pick the new build automagically

So 154-2 build and test were fine on i686, x86_64, ppc, ppc64 and s390.
But s390x saw a strange failure:
http://s390.koji.fedoraproject.org/koji/getfile?taskID=732847&name=build.log

Extracting symbols... File `elf32_checksum.o' not found in archive
FAIL: run-arextract.sh
Cannot get archive index: no index available
FAIL: run-arsymtest.sh

This is probably completely unrelated. But strange. Anybody with a s390x around that could investigate?

Dan Horák is usually willing to let me play on one of his Fedora/s390 machines, so I'll take a look.

(I also reassigned the component back from 0xFFFF.  Not sure why that happened.)

(In reply to comment #11)
> (In reply to comment #10)
> > (In reply to comment #9)
> > > Petr's patch was committed upstream. I created packages with it backported
> > > (and enabled the testcase again) as elfutils-0.154-2.fc18. Do the ppc and
> > > s390 koji builders pick that one up automagically?
> > 
> > yes, they will pick the new build automagically
> 
> So 154-2 build and test were fine on i686, x86_64, ppc, ppc64 and s390.
> But s390x saw a strange failure:
> http://s390.koji.fedoraproject.org/koji/getfile?taskID=732847&name=build.log
> 
> Extracting symbols... File `elf32_checksum.o' not found in archive
> FAIL: run-arextract.sh
> Cannot get archive index: no index available
> FAIL: run-arsymtest.sh

the second failure can be related to the recent change in binutils to support static library archives larger than 4GB, see bug #835957 for details

After looking inside, I think that both are related to 64-bit archives.  __libelf_next_arhdr_wrlock is rejecting archives because of the unknown special entry /SYM64/.

(In reply to comment #14)
> After looking inside, I think that both are related to 64-bit archives. 
> __libelf_next_arhdr_wrlock is rejecting archives because of the unknown
> special entry /SYM64/.

Thanks for looking. Lets open a new bug report for this issue then.

elfutils-0.154-2.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/elfutils-0.154-2.fc17

elfutils-0.154-2.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/elfutils-0.154-2.fc16

Package elfutils-0.154-2.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing elfutils-0.154-2.fc17'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-11095/elfutils-0.154-2.fc17
then log in and leave karma (feedback).

elfutils-0.154-2.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.

elfutils-0.154-2.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.