Re: GDB loading incorrect version library

[Simon Marchi <simon.marchi@polymtl.ca>]

On 2021-01-15 2:30 a.m., Jeffrey Walton via Gdb wrote:
> Hi Everyone,
> 
> I'm trying to investigate a Bash crash when Bash is instrumented with
> Asan. I've got Bash and all of its dependencies built/installed at
> ~/ok2delete-asan. All of them are built with Asan.
> 
> GDB startup shows:
> 
>     $ gdb ~/ok2delete-asan/bin/bash
>     gdb: /usr/local/lib/libncursesw.so.6: no version information
> available (required by gdb)
> 
> It appears GDB is not loading the proper version of Ncurses:
> 
>     (gdb) shell readelf -d ~/ok2delete-asan/bin/bash | grep -E 'RPATH|RUNPATH'
>      0x000000000000001d (RUNPATH)            Library runpath:
> [$ORIGIN/../lib:/home/jwalton/ok2delete-asan/lib]
> 
> And (slightly trimmed):
> 
> (gdb) shell ldd ~/ok2delete-asan/bin/bash
>     linux-vdso.so.1 (0x00007ffde6bfc000)
>     libasan.so.5 => /usr/lib/x86_64-linux-gnu/libasan.so.5
>     libiconv.so.2 => /home/jwalton/ok2delete-asan/bin/../lib/libiconv.so.2
>     libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2
>     libtinfow.so.6 => /home/jwalton/ok2delete-asan/bin/../lib/libtinfow.so.6
>     libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
>     libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6
>     librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1
>     libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6
>     libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
>     /lib64/ld-linux-x86-64.so.2
> 
> All of the warez built use the same RUNPATH.
> 
> How do I tell GDB to use the RUNPATH set in the binary?
> 
> Thanks in advance.
> 

From what I understand, the problem appears to be with the library
required by GDB itself (GDB uses ncurses to implement the text user
interface, or TUI) and not with ncurses loaded by your bash
executable.  As we can see by your ldd command, your bash doesn't
even require ncurses.

So maybe you built GDB against some ncurses library (the one in
/usr/lib perhaps) but now there's another, incompatible ncurses
library in the library path (in /usr/local/lib).

Additionally, you get the error message just when loading the bash
executable in GDB.  At this point, GDB makes no attempt to load
any of the shared libraries, that only happens when you run, and
the process actually loads the shared libraries.  And when this
happens, GDB simply gets the absolute path of the library that the
process actually loaded from the dynamic loader.  As a result, GDB
doesn't need to implement any RPATH / LD_LIBRARY_PATH / whatever
logic to find libraries.

Simon