[Bug general/24000] New: couple of testsuite fails with uclibc library

[Bug general/24000] New: couple of testsuite fails with uclibc library

[ksd.selvakumar at yahoo dot in]

https://sourceware.org/bugzilla/show_bug.cgi?id=24000

            Bug ID: 24000
           Summary: couple of testsuite fails with uclibc library
           Product: elfutils
           Version: unspecified
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: general
          Assignee: unassigned at sourceware dot org
          Reporter: ksd.selvakumar at yahoo dot in
                CC: elfutils-devel at sourceware dot org
  Target Milestone: ---

When elfutils is compiled against uclibc i got the below memory exhaust with
eu-elflint

eu-elflint src/nm.o 
invalid machine flags: 0x5000000
eu-elflint: memory exhausted

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug general/24000] couple of testsuite fails with uclibc library

[mark at klomp dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=24000

Mark Wielaard <mark at klomp dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mark at klomp dot org

--- Comment #1 from Mark Wielaard <mark at klomp dot org> ---
Could you attach the src/nm.o file?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug general/24000] couple of testsuite fails with uclibc library

[ksd.selvakumar at yahoo dot in]

https://sourceware.org/bugzilla/show_bug.cgi?id=24000

--- Comment #2 from selva <ksd.selvakumar at yahoo dot in> ---
Created attachment 11512
  --> https://sourceware.org/bugzilla/attachment.cgi?id=11512&action=edit
Attached nm.o file

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug general/24000] couple of testsuite fails with uclibc library

[mark at klomp dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=24000

--- Comment #3 from Mark Wielaard <mark at klomp dot org> ---
Sorry, I have no idea what is going on.
It looks like a normal arm ELF file:

$ eu-readelf -h nm.o
ELF Header:
  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
  Class:                             ELF32
  Data:                              2's complement, little endian
  Ident Version:                     1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              REL (Relocatable file)
  Machine:                           ARM
  Version:                           1 (current)
  Entry point address:               0
  Start of program headers:          0 (bytes into file)
  Start of section headers:          106424 (bytes into file)
  Flags:                             0x5000000
  Size of this header:               52 (bytes)
  Size of program header entries:    0 (bytes)
  Number of program headers entries: 0
  Size of section header entries:    40 (bytes)
  Number of section headers entries: 31
  Section header string table index: 28

0x5000000 (which your eu-elflint complains about) is EF_ARM_EABI_VER5, which
the arm backend hook machine_flag_check knows about. So eu-elflint really
should have no complaints:

$ eu-elflint nm.o 
No errors

Maybe your installation isn't able to correctly load the ebl backends?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug general/24000] couple of testsuite fails with uclibc library

[ksd.selvakumar at yahoo dot in]

https://sourceware.org/bugzilla/show_bug.cgi?id=24000

--- Comment #4 from selva <ksd.selvakumar at yahoo dot in> ---
Created attachment 11548
  --> https://sourceware.org/bugzilla/attachment.cgi?id=11548&action=edit
Uclibc full testsuite log

Attaching the full test suite log.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug general/24000] couple of testsuite fails with uclibc library

[mark at klomp dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=24000

--- Comment #5 from Mark Wielaard <mark at klomp dot org> ---
(In reply to selva from comment #4)
> Created attachment 11548 [details]
> Uclibc full testsuite log
> 
> Attaching the full test suite log.

BTW. It is easier to just attache the tests/test-suite.log.
But I am afraid there still isn't enough to figure out what is going wrong.
Maybe the config.log could show a bit more.

Please run one of the segfaulting tests under gdb and get a backtrace to show
what is really going on.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug general/24000] couple of testsuite fails with uclibc library

[ksd.selvakumar at yahoo dot in]

https://sourceware.org/bugzilla/show_bug.cgi?id=24000

--- Comment #6 from selva <ksd.selvakumar at yahoo dot in> ---
(In reply to Mark Wielaard from comment #5)
> (In reply to selva from comment #4)
> > Created attachment 11548 [details]
> > Uclibc full testsuite log
> > 
> > Attaching the full test suite log.
> 
> BTW. It is easier to just attache the tests/test-suite.log.
> But I am afraid there still isn't enough to figure out what is going wrong.
> Maybe the config.log could show a bit more.
> 
> Please run one of the segfaulting tests under gdb and get a backtrace to
> show what is really going on.

Mmm., Tried to run the test with gdb but i get "no stack" Please share me the
steps to get the backtrace if you have any.

# ./run-elfputzdata.sh 
Segmentation fault
# 
# gdb --args bash ./run-elfputzdata.sh 
GNU gdb (GDB) 7.10.1
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "armv7l-unkown-linux-uclibcgnueabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from bash...done.
(gdb) run
Starting program: /bin/bash ./run-elfputzdata.sh
/root/elfutils-0.173/tests/test-subr.sh: line 64:  3679 Segmentation fault     
diff -u $outfile -
[Inferior 1 (process 3670) exited with code 0213]
(gdb) 
(gdb) backtrace 
No stack.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug general/24000] couple of testsuite fails with uclibc library

[ksd.selvakumar at yahoo dot in]

https://sourceware.org/bugzilla/show_bug.cgi?id=24000

--- Comment #7 from selva <ksd.selvakumar at yahoo dot in> ---
Created attachment 11582
  --> https://sourceware.org/bugzilla/attachment.cgi?id=11582&action=edit
config.log

Attached the config.log.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug general/24000] couple of testsuite fails with uclibc library

[mark at klomp dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=24000

--- Comment #8 from Mark Wielaard <mark at klomp dot org> ---
(In reply to selva from comment #6)
> (In reply to Mark Wielaard from comment #5)
> > (In reply to selva from comment #4)
> > > Created attachment 11548 [details]
> > > Uclibc full testsuite log
> > > 
> > > Attaching the full test suite log.
> > 
> > BTW. It is easier to just attache the tests/test-suite.log.
> > But I am afraid there still isn't enough to figure out what is going wrong.
> > Maybe the config.log could show a bit more.
> > 
> > Please run one of the segfaulting tests under gdb and get a backtrace to
> > show what is really going on.
> 
> Mmm., Tried to run the test with gdb but i get "no stack" Please share me
> the steps to get the backtrace if you have any.

Best to figure out which of the tests in run-elfputzdata.sh actually fails and
then run that by hand on the failing test file (bunzip2ed first).

e.g.

cp tests/testfile4.bz2 .
bunzip2 testfile4.bz2
LD_LIBRARY_PATH=backends:libelf:libdw gdb --args tests/elfputzdata gnu
testfile4
(gdb) run

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug general/24000] couple of testsuite fails with uclibc library

[mark at klomp dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=24000

--- Comment #9 from Mark Wielaard <mark at klomp dot org> ---
(In reply to selva from comment #7)
> Created attachment 11582 [details]
> config.log
> 
> Attached the config.log.

>  $ ./configure --target=armv7l-unkown-linux-uclibcgnueabi --host=armv7l-unkown-linux-uclibcgnueabi --build=x86_64-linux-gnu --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --libdir=/usr/lib --libexecdir=/usr/lib --sysconfdir=/etc --datadir=/usr/share --localstatedir=/var --mandir=/usr/share/man --infodir=/usr/share/info --includedir=/usr/include --disable-nls --disable-Werror --enable-largefile --with-biarch --disable-symbol-versioning

That looks like a cross build. It might work, but I never tried myself.
It might be easier to make sure a native build works first.

> =====================================================================
>         elfutils: 0.173 (eu_version: 173)
> =====================================================================

Please try with the latest release: 0.175 

>  RECOMMENDED FEATURES (should all be yes)
>    gzip support                       : yes
>    bzip2 support                      : yes
>    lzma/xz support                    : no
>    libstdc++ demangle support         : yes
>    File textrel check                 : yes
>    Symbol versioning                  : no

Please enable lzma/xz support by installing xz-devel.
Don't disable symbol versioning, without it binary compatibility is broken.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug general/24000] couple of testsuite fails with uclibc library

[ksd.selvakumar at yahoo dot in]

https://sourceware.org/bugzilla/show_bug.cgi?id=24000

--- Comment #10 from selva <ksd.selvakumar at yahoo dot in> ---
(In reply to Mark Wielaard from comment #8)
> (In reply to selva from comment #6)
> > (In reply to Mark Wielaard from comment #5)
> > > (In reply to selva from comment #4)
> > > > Created attachment 11548 [details]
> > > > Uclibc full testsuite log
> > > > 
> > > > Attaching the full test suite log.
> > > 
> > > BTW. It is easier to just attache the tests/test-suite.log.
> > > But I am afraid there still isn't enough to figure out what is going wrong.
> > > Maybe the config.log could show a bit more.
> > > 
> > > Please run one of the segfaulting tests under gdb and get a backtrace to
> > > show what is really going on.
> > 
> > Mmm., Tried to run the test with gdb but i get "no stack" Please share me
> > the steps to get the backtrace if you have any.
> 
> Best to figure out which of the tests in run-elfputzdata.sh actually fails
> and then run that by hand on the failing test file (bunzip2ed first).
> 
> e.g.
> 
> cp tests/testfile4.bz2 .
> bunzip2 testfile4.bz2
> LD_LIBRARY_PATH=backends:libelf:libdw gdb --args tests/elfputzdata gnu
> testfile4
> (gdb) run

Thanks a lot for sharing testing steps.
I got "out of memory" error for testfile4 only 
other tests like testfile12,testfileppc64,testfileppc32 are okay.


# cp tests/testfile4.bz2 ./
# bunzip2 testfile4.bz2 
# 
# LD_LIBRARY_PATH=backends:libelf:libdw gdb --args tests/elfputzdata gnu
testfil
e4
GNU gdb (GDB) 7.10.1
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "armv7l-unkown-linux-uclibcgnueabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from tests/elfputzdata...done.
(gdb) run
Starting program: /root/elfutils-0.173/tests/elfputzdata gnu testfile4
Cannot compress 1 .interp
Cannot compress 2 .note.ABI-tag
Cannot compress 3 .hash
Cannot compress 4 .dynsym
Cannot compress 5 .dynstr
Cannot compress 6 .gnu.version
Cannot compress 7 .gnu.version_r
Cannot compress 8 .rel.got
Cannot compress 9 .rel.plt
Cannot compress 10 .init
Cannot compress 11 .plt
Cannot compress 12 .text
Cannot compress 13 .fini
Cannot compress 14 .rodata
Cannot compress 15 .data
Cannot compress 16 .eh_frame
Cannot compress 17 .gcc_except_table
Cannot compress 18 .ctors
Cannot compress 19 .dtors
Cannot compress 20 .got
Cannot compress 21 .dynamic
Lets compress 22 .sbss, size: 0
elf_[un]compress_gnu failed for section 22: out of memory
[Inferior 1 (process 5398) exited with code 0377]
(gdb) backtrace 
No stack.
(gdb) quit
# 
# 
# LD_LIBRARY_PATH=backends:libelf:libdw gdb --args tests/elfputzdata elf
testfil
e4
GNU gdb (GDB) 7.10.1
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "armv7l-unkown-linux-uclibcgnueabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from tests/elfputzdata...done.
(gdb) run       
Starting program: /root/elfutils-0.173/tests/elfputzdata elf testfile4
Cannot compress 1 .interp
Cannot compress 2 .note.ABI-tag
Cannot compress 3 .hash
Cannot compress 4 .dynsym
Cannot compress 5 .dynstr
Cannot compress 6 .gnu.version
Cannot compress 7 .gnu.version_r
Cannot compress 8 .rel.got
Cannot compress 9 .rel.plt
Cannot compress 10 .init
Cannot compress 11 .plt
Cannot compress 12 .text
Cannot compress 13 .fini
Cannot compress 14 .rodata
Cannot compress 15 .data
Cannot compress 16 .eh_frame
Cannot compress 17 .gcc_except_table
Cannot compress 18 .ctors
Cannot compress 19 .dtors
Cannot compress 20 .got
Cannot compress 21 .dynamic
Lets compress 22 .sbss, size: 0
elf_[un]compress failed for section 22: out of memory
[Inferior 1 (process 5403) exited with code 0377]
(gdb) backtrace 
No stack.
(gdb) quit
#

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug general/24000] couple of testsuite fails with uclibc library

[ksd.selvakumar at yahoo dot in]

https://sourceware.org/bugzilla/show_bug.cgi?id=24000

--- Comment #11 from selva <ksd.selvakumar at yahoo dot in> ---
(In reply to Mark Wielaard from comment #9)
> (In reply to selva from comment #7)
> > Created attachment 11582 [details]
> > config.log
> > 
> > Attached the config.log.
> 
> >  $ ./configure --target=armv7l-unkown-linux-uclibcgnueabi --host=armv7l-unkown-linux-uclibcgnueabi --build=x86_64-linux-gnu --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --libdir=/usr/lib --libexecdir=/usr/lib --sysconfdir=/etc --datadir=/usr/share --localstatedir=/var --mandir=/usr/share/man --infodir=/usr/share/info --includedir=/usr/include --disable-nls --disable-Werror --enable-largefile --with-biarch --disable-symbol-versioning
> 
> That looks like a cross build. It might work, but I never tried myself.
> It might be easier to make sure a native build works first.
> 
> > =====================================================================
> >         elfutils: 0.173 (eu_version: 173)
> > =====================================================================
> 
> Please try with the latest release: 0.175 
> 
> >  RECOMMENDED FEATURES (should all be yes)
> >    gzip support                       : yes
> >    bzip2 support                      : yes
> >    lzma/xz support                    : no
> >    libstdc++ demangle support         : yes
> >    File textrel check                 : yes
> >    Symbol versioning                  : no
> 
> Please enable lzma/xz support by installing xz-devel.
> Don't disable symbol versioning, without it binary compatibility is broken.


As per the following commit disabled symbol versioning for uclibc
https://sourceware.org/git/?p=elfutils.git;a=commit;h=bafacacaf7659a4933604662daba26a480b29a8d

with uclibc,the test suite hangs in middle when compiled with Symbol versioning

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug general/24000] couple of testsuite fails with uclibc library

[mark at klomp dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=24000

Mark Wielaard <mark at klomp dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2019-02-18
           Assignee|unassigned at sourceware dot org   |mark at klomp dot org
     Ever confirmed|0                           |1

--- Comment #12 from Mark Wielaard <mark at klomp dot org> ---
Created attachment 11613
  --> https://sourceware.org/bugzilla/attachment.cgi?id=11613&action=edit
Handle malloc(0) specially when decompressing

(In reply to selva from comment #10)
> Lets compress 22 .sbss, size: 0
> elf_[un]compress failed for section 22: out of memory

That is interesting. It looks like your malloc implementation returns NULL when
calling malloc (0). That seems valid, but somewhat unfortunate.

Could you try the following patch?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug general/24000] couple of testsuite fails with uclibc library

[mark at klomp dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=24000

--- Comment #13 from Mark Wielaard <mark at klomp dot org> ---
(In reply to selva from comment #11)
> (In reply to Mark Wielaard from comment #9)
> > Don't disable symbol versioning, without it binary compatibility is broken.
> 
> As per the following commit disabled symbol versioning for uclibc
> https://sourceware.org/git/?p=elfutils.git;a=commit;
> h=bafacacaf7659a4933604662daba26a480b29a8d
> 
> with uclibc,the test suite hangs in middle when compiled with Symbol
> versioning

hmmm. I think that commit might have been a mistake in hindsight.
But lets first see what happens with the special malloc (0) patch.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Re: [Bug general/24000] couple of testsuite fails with uclibc library

[Ulf Hermann]

Hi,

>>> Don't disable symbol versioning, without it binary compatibility is broken.
>>
>> As per the following commit disabled symbol versioning for uclibc
>> https://sourceware.org/git/?p=elfutils.git;a=commit;
>> h=bafacacaf7659a4933604662daba26a480b29a8d
>>
>> with uclibc,the test suite hangs in middle when compiled with Symbol
>> versioning
> 
> hmmm. I think that commit might have been a mistake in hindsight.

The option to disable symbol versioning is appreciated here. I don't 
think it's a mistake. There are platforms which don't support symbol 
versioning at all.

best,
Ulf

Symbol versioning (Was: [Bug general/24000] couple of testsuite fails with uclibc library)

[Mark Wielaard]

On Tue, Feb 19, 2019 at 07:59:53AM +0000, Ulf Hermann wrote:
> >>> Don't disable symbol versioning, without it binary compatibility is broken.
> >> As per the following commit disabled symbol versioning for uclibc
> >> https://sourceware.org/git/?p=elfutils.git;a=commit;
> >> h=bafacacaf7659a4933604662daba26a480b29a8d
> >>
> >> with uclibc,the test suite hangs in middle when compiled with Symbol
> >> versioning
> > 
> > hmmm. I think that commit might have been a mistake in hindsight.
> 
> The option to disable symbol versioning is appreciated here. I don't 
> think it's a mistake. There are platforms which don't support symbol 
> versioning at all.

The problem is that without it every elfutils release would (possibly)
break the ABI between the shared libraries and programs using them.
And we don't have/use a different mechanism to indicate symbols/ABI
changed. How do you prevent things breaking when upgrading the
elfutils libraries?

Cheers,

Mark

Re: Symbol versioning (Was: [Bug general/24000] couple of testsuite fails with uclibc library)

[Ulf Hermann]

> The problem is that without it every elfutils release would (possibly)
> break the ABI between the shared libraries and programs using them.
> And we don't have/use a different mechanism to indicate symbols/ABI
> changed. How do you prevent things breaking when upgrading the
> elfutils libraries?

I ship the version of elfutils the application links against with the 
application. That is common practice on windows (and also on e.g. 
macOS). The concept of package management only exist on some platforms 
and only in this context symbol versioning makes sense. Even on linux, 
with things like flatpak, binary compatibility between different 
versions of a library becomes less important.

best,
Ulf

Re: Symbol versioning (Was: [Bug general/24000] couple of testsuite fails with uclibc library)

[Mark Wielaard]

On Tue, Feb 19, 2019 at 11:30:08AM +0000, Ulf Hermann wrote:
> > The problem is that without it every elfutils release would (possibly)
> > break the ABI between the shared libraries and programs using them.
> > And we don't have/use a different mechanism to indicate symbols/ABI
> > changed. How do you prevent things breaking when upgrading the
> > elfutils libraries?
> 
> I ship the version of elfutils the application links against with the 
> application. That is common practice on windows (and also on e.g. 
> macOS). The concept of package management only exist on some platforms 
> and only in this context symbol versioning makes sense. Even on linux, 
> with things like flatpak, binary compatibility between different 
> versions of a library becomes less important.

It might work if you always compile everything from source (but even
then you need to at least keep API source compatible) and link
statically. But even things like flatpak support runtimes/libraries.
As it turns out elfutils is part of the freedesktop base sdk, so even
when using such packaging setup it still is important for elfutils to
keep ABI.

My point is more that if we disable symbol versioning we have to make
it much more clear that the resulting shared libaries aren't really
usable as "normal".

Cheers,

Mark

[Bug general/24000] couple of testsuite fails with uclibc library

[mark at klomp dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=24000

Mark Wielaard <mark at klomp dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #11613|0                           |1
        is obsolete|                            |

--- Comment #14 from Mark Wielaard <mark at klomp dot org> ---
Created attachment 11614
  --> https://sourceware.org/bugzilla/attachment.cgi?id=11614&action=edit
Handle malloc(0) specially when decompressing

Sorry, that patch was clearly untested. This one is.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug general/24000] couple of testsuite fails with uclibc library

[ksd.selvakumar at yahoo dot in]

https://sourceware.org/bugzilla/show_bug.cgi?id=24000

--- Comment #15 from selva <ksd.selvakumar at yahoo dot in> ---
(In reply to Mark Wielaard from comment #14)
> Created attachment 11614 [details]
> Handle malloc(0) specially when decompressing
> 
> Sorry, that patch was clearly untested. This one is.

Thanks,With this patch test passed.

PASS: run-elfputzdata.sh

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug general/24000] couple of ELF compression testsuite fails with uclibc library

[mark at klomp dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=24000

Mark Wielaard <mark at klomp dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED
            Summary|couple of testsuite fails   |couple of ELF compression
                   |with uclibc library         |testsuite fails with uclibc
                   |                            |library

--- Comment #16 from Mark Wielaard <mark at klomp dot org> ---
Thanks for testing. I pushed this:

commit ff7fe986679b0811591ef6e40cf485fa9f037e07
Author: Mark Wielaard <mark@klomp.org>
Date:   Tue Feb 19 16:27:40 2019 +0100

    libelf: Handle zero size decompressed data.

    This is a corner case that will most likely never occur in practice,
    but we have several testcases that compress and decompress zero sized
    data. In that case during decompression we might malloc a buffer of
    size zero. It is allowed for malloc to return NULL in that case. But
    we do need a non-NULL buffer to return and set as result. So make sure
    to always at least allocate one byte. Also make sure that we don't
    allocate a zero sized conversion buffer for the data.

    https://sourceware.org/bugzilla/show_bug.cgi?id=24000

    Signed-off-by: Mark Wielaard <mark@klomp.org>

Lets close this bug.

Could you please open a new bug in case you still see other testsuite failures?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug general/24000] couple of ELF compression testsuite fails with uclibc library

[ksd.selvakumar at yahoo dot in]

https://sourceware.org/bugzilla/show_bug.cgi?id=24000

--- Comment #17 from selva <ksd.selvakumar at yahoo dot in> ---
(In reply to Mark Wielaard from comment #16)
> Thanks for testing. I pushed this:
> 
> commit ff7fe986679b0811591ef6e40cf485fa9f037e07
> Author: Mark Wielaard <mark@klomp.org>
> Date:   Tue Feb 19 16:27:40 2019 +0100
> 
>     libelf: Handle zero size decompressed data.
>     
>     This is a corner case that will most likely never occur in practice,
>     but we have several testcases that compress and decompress zero sized
>     data. In that case during decompression we might malloc a buffer of
>     size zero. It is allowed for malloc to return NULL in that case. But
>     we do need a non-NULL buffer to return and set as result. So make sure
>     to always at least allocate one byte. Also make sure that we don't
>     allocate a zero sized conversion buffer for the data.
>     
>     https://sourceware.org/bugzilla/show_bug.cgi?id=24000
>     
>     Signed-off-by: Mark Wielaard <mark@klomp.org>
> 
> Lets close this bug.
> 
> Could you please open a new bug in case you still see other testsuite
> failures?

Thanks, opened new one.
https://sourceware.org/bugzilla/show_bug.cgi?id=24240

-- 
You are receiving this mail because:
You are on the CC list for the bug.