Re: Interesting readelf failures from lintian.d.o
On Tue, 2008-08-12 at 23:28 +0100, Adam D. Barratt wrote:
> On Tue, 2008-08-12 at 14:00 -0700, Russ Allbery wrote:
> > "Adam D. Barratt" <adam@adam-barratt.org.uk> writes:
> > > On Tue, 2008-08-12 at 13:27 -0700, Russ Allbery wrote:
> >
> > >> readelf: Warning: Virtual address 0x970c not located in any PT_LOAD segment.
> > >> readelf: Error: Out of memory allocating 0xffff8c1f bytes for symbols
> [...]
> > > Is there any easy way of narrowing down which packages / files are
> > > affected?
> [...]
> > Unfortunately, no, because the harness doesn't trap the output from
> > lintian and do something useful with it.
>
> I'm (slowly, as the most powerful etch machine I can easily (ab)use for
> testing is a PII 400) working through the obvious suspects, namely those
> for which lintian.d.o currently reports apparently-corrupted-elf-binary.
Which unfortunately yielded no results other than a bug in the objdump
collection script and another possible bug in the symbols file parsing
in checks/shared-libs.
Unless "readelf -l" is failing, the only other set of packages which
should be calling readelf at all are those for which we issue
binary-with-bad-dynamic-section, which all appear to be "misplaced"
debug libraries. Of the packages for which the tag is currently
recorded, only one produced errors in my testing:
/usr/share/crystalspace-1.2/bindings/python/_cspace.so.dbg (from the
crystalspace package)
readelf: Error: Unable to read in 0xf8 bytes of dynamic section
At the expense of another call to objdump, we could restrict the readelf
fallback code to only running in the case where the the objdump error
was "File format not recognised", rather than also handling "Invalid
operation".
I'm not sure whether this is the correct approach, however. According to
#249435, the most common cause of the "invalid operation" error is that
the object declares a dynamic section but the section is empty. This
isn't the case for /usr/lib/libQtXmlPatterns.so.4.4.1.debug - objdump
returns "invalid operation" but there is a dynamic section which readelf
is happy to display; we therefore currently have inconsistent results
for the libqt4-xmlpatterns-dbg package, depending on whether lintian is
being run on sid or etch.
Adam
Reply to: