[Bug dynamic-link/20105] bad version variable in elf_dynamic_do_Rel() elf/do-rel.h (2.23) causes coredump in dl-machine.h elf_machine_rela()

["jason.vas.dias at gmail dot com" <sourceware-bugzilla at sourceware dot org>]

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

--- Comment #10 from Jason Vas Dias <jason.vas.dias at gmail dot com> ---
Oops, it appears "comments cannot be longer that 65536 characters". Resending
last posts with attachments ...

First post:

Aha - thanks for the info, Carlos ! But please could you append / send me the
output of 'cat /proc/$PID/maps' where PID is the process ID of a running
instance of soffice.bin on your system ? It must be some library dependency
that it is OK on your system but bad on mine - I'd like to get to the bottom
of precisely what this is, because I still think glibc should detect
and complain
about such problems instead of core-dumping .

I did actually get it working on my LFS system under the same
glibc-2.23,  albeit
borrowing a few libraries from a mounted RHEL7 clone partition :
in my ~/.aliases I have:
alias ooow='LD_PRELOAD=$(sed s_^_/mnt/oel7/usr/lib64/_ <
$OOO_HOME/oel.libs | tr \\n :) LD_LIBRARY_PATH=${OOO_HOME}
PID_FILE=${HOME}/ooof.pid daemon ${OOO_HOME}/soffice.bin -writer'

with 'daemon' being a shell function that forks off an init (process 1) child
without a controlling TTY at a specified priority .

$ cat $OOO_HOME/oel.libs

libavahi-client.so.3
libavahi-common.so.3
libavahi-glib.so.1
libcom_err.so.2
libcrypto.so.10
libgconf-2.so.4
libgnomevfs-2.so.0
libgssapi_krb5.so
libgssapi_krb5.so.2
libk5crypto.so.3
libkeyutils.so.1
libkrb5.so.3
libkrb5support.so.0
libpcre.so
libpcre.so.1
libssl.so.10

Presumably, if I built all this ancient cruft ( libgnome-vfs2,
libavahi, OpenSSL 0.9.8x ...) into my new system,  which I have no
intention of doing, the application might
load on my system without  these external RHEL7 clone libraries.

Its link map is attached.

But I still think glibc should be detecting link-time problems and
reporting them
rather than core dumping - this was meant to be the point of this bug report,
rather than "I can't run OpenOffice-4.1.2" .

If you would please be so kind as to send me the link map on your system, I can
find exactly which of the libraries I built is causing the glibc
dynamic linker to coredump when these external libraries are not
loaded .

I do not think the glibc dynamic linker should be capable of coredumping in
any circumstances - I understand this may be an unattainable goal,
but I nevertheless think we should aim for it .


On 18/05/2016, carlos at redhat dot com
<sourceware-bugzilla@sourceware.org> wrote:
> https://sourceware.org/bugzilla/show_bug.cgi?id=20105
>
> Carlos O'Donell <carlos at redhat dot com> changed:
>
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>              Status|UNCONFIRMED                 |RESOLVED
>          Resolution|---                         |WORKSFORME
>
> --- Comment #7 from Carlos O'Donell <carlos at redhat dot com> ---
> (In reply to Carlos O'Donell from comment #6)
>> I've just downloaded the package and I'll have a look at the DSOs to see
>> if
>> anything is weird with them.
>
> Apache_OpenOffice_4.1.2_Linux_x86-64_install-rpm_en-US.tar.gz works
> perfectly
> fine under glibc master (e2cd73a2ccabe8acae28719a0c3c1c03f2b5f9fb).
>
> --
> You are receiving this mail because:
> You reported the bug.

Second post:

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