2

I am having problem when executing majority of 32bit software on my Linux.

This problem happens when running any dynamically linked c++ software and also dynamic linked c programs that uses any libs outside standard c libs. Only statically linked programs on both languages and the simplest c programs are able to execute.

For instance, this is what happens when executing a simple 32bit, dynamically linked c++ hello word on gdb:

(gdb) run
Starting program: /media/34GB/ciencias exatas/test-32bit 

Program received signal SIGSEGV, Segmentation fault.
0x000044ae in ?? ()

also:

(gdb) backtrace
#0  0x000044ae in ?? ()
#1  0xf7eb5854 in ?? ()
#2  0xf7fde66e in dl_main (phdr=0x8048034, phnum=8,    user_entry=0xffffd3cc, auxv=0xffffd50c) at rtld.c:2203
#3  0xf7fefb89 in _dl_sysdep_start (start_argptr=0xffffd460, dl_main=0xf7fdc490 <dl_main>) at ../elf/dl-sysdep.c:241
#4  0xf7fdf6fe in _dl_start_final (arg=0xffffd460) at rtld.c:331
#5  _dl_start (arg=<optimized out>) at rtld.c:557
#6  0xf7fdba87 in _start () from /usr/lib32/ld-2.17.so

I did compile it with:

g++ -m32 -o test-32bit test-32bit.cpp -Wl,--dynamic-link=/usr/lib32/ld-2.17.so

and executed it with:

LD_LIBRARY_PATH=/media/34GB/Arquivos-de-Programas-Linux/Gcc-4.9.4/lib32/ gdb ./test-32bit

The same output is obtained when running 32bit programs that I built from the source, such as Dosbox and Snes9x.

I believe this might be caused by mixing auxiliary 64bit and 32bit libraries, such as rtld.

The likely reason for this is that I decided to add 32bit support on my system. From the scratch.

First I built a 32bit glibc and installed it outside system tree of standard directories. Then I created a /usr/lib32 and put symbolic links there to everything in glibc's libdir. I also compiled a new gcc with multilib support (don't remember if that preceded glibc's install or not) and then created a symbolic link to libstdc++.so.6 also on /usr/lib/32.

Then I created sym links in /usr/local/bin to gcc and g++. Finally, I executed ldconfig.

So, what I need right now, are suggestions of ways to debug this test example (or the other 32bit software) as to figure out the cause and then try to fix it.

Thanks for the input.

Edit1: "info shared" output:

Program received signal SIGSEGV, Segmentation fault.
0x000044ae in ?? ()
(gdb) info shared
From        To          Syms Read   Shared Object Library
0xf7fdb7e0  0xf7ff342c  Yes         /usr/lib32/ld-2.17.so
0xf7f24d70  0xf7f98aa8  No          /media/34GB/Arquivos-de-Programas-Linux/Gcc-4.9.4/lib32/libstdc++.so.6
0xf7e9c550  0xf7ec7c88  No          /media/34GB/Arquivos-de-Programas-Linux-32bit/Glibc-2.17/lib/libm.so.6
0xf7e7f000  0xf7e92ca8  No          /media/34GB/Arquivos-de-Programas-Linux/Gcc-4.9.4/lib32/libgcc_s.so.1
0xf7cd2280  0xf7dffa0c  No          /media/34GB/Arquivos-de-Programas-Linux-32bit/Glibc-2.17/lib/libc.so.6

EDIT2: info proc mappings output

process 2087
Mapped address spaces:

Start Addr   End Addr       Size     Offset objfile
 0x8048000  0x8049000     0x1000        0x0 /media/34GB/demos/test-32bit
 0x8049000  0x804a000     0x1000        0x0 /media/34GB/demos/test-32bit
0xf7cb9000 0xf7cbb000     0x2000        0x0 
0xf7cbb000 0xf7e76000   0x1bb000        0x0 /media/34GB/Arquivos-de-Programas-Linux-32bit/Glibc-2.17/lib/libc-2.17.so
0xf7e76000 0xf7e79000     0x3000   0x1ba000 /media/34GB/Arquivos-de-Programas-Linux-32bit/Glibc-2.17/lib/libc-2.17.so
0xf7e79000 0xf7e7b000     0x2000   0x1bd000 /media/34GB/Arquivos-de-Programas-Linux-32bit/Glibc-2.17/lib/libc-2.17.so
0xf7e7b000 0xf7e7d000     0x2000        0x0 
0xf7e7d000 0xf7e97000    0x1a000        0x0 /media/34GB/Arquivos-de-Programas-Linux/Gcc-4.9.4/lib32/libgcc_s.so.1
0xf7e97000 0xf7e98000     0x1000    0x19000 /media/34GB/Arquivos-de-Programas-Linux/Gcc-4.9.4/lib32/libgcc_s.so.1
0xf7e98000 0xf7edd000    0x45000        0x0 /media/34GB/Arquivos-de-Programas-Linux-32bit/Glibc-2.17/lib/libm-2.17.so
0xf7edd000 0xf7edf000     0x2000    0x45000 /media/34GB/Arquivos-de-Programas-Linux-32bit/Glibc-2.17/lib/libm-2.17.so
0xf7edf000 0xf7fcc000    0xed000        0x0 /media/34GB/Arquivos-de-Programas-Linux/Gcc-4.9.4/lib32/libstdc++.so.6.0.20
0xf7fcc000 0xf7fd1000     0x5000    0xed000 /media/34GB/Arquivos-de-Programas-Linux/Gcc-4.9.4/lib32/libstdc++.so.6.0.20
0xf7fd1000 0xf7fda000     0x9000        0x0 
0xf7fda000 0xf7fdb000     0x1000        0x0 [vdso]
0xf7fdb000 0xf7ffc000    0x21000        0x0 /media/34GB/Arquivos-de-Programas-Linux-32bit/Glibc-2.17/lib/ld-2.17.so
0xf7ffc000 0xf7ffe000     0x2000    0x20000 /media/34GB/Arquivos-de-Programas-Linux-32bit/Glibc-2.17/lib/ld-2.17.so
0xfffe9000 0xffffe000    0x15000        0x0 [stack]

EDIT3: How I (probably compiled) glibc:

CC="gcc -m32 -march=core2 -mtune=core2 -O2" ../configure --prefix=/media/34GB/Arquivos-de-Programas-Linux-32bit/Glibc-2.17/ --build=x86_64-linux-gnu --host=i686-gnu-linux --enable-kernel-2.6.32 --enable-profile
user2752471
  • 444
  • 1
  • 6
  • 14
  • [What is a debugger and how can it help me diagnose problems?](https://stackoverflow.com/questions/25385173/what-is-a-debugger-and-how-can-it-help-me-diagnose-problems) - segfaults are usually pretty easy to catch In a debugger and figure out. – Jesper Juhl May 15 '23 at 00:13
  • 1
    "Then I created sym links in /usr/local/bin" - aww don't do that. – Jesper Juhl May 15 '23 at 00:22
  • 2
    Please edit your question with the output from `(gdb) info shared` at crash point. Mixing 32-bit and 64-bit libraries is _not_ your problem. – Employed Russian May 15 '23 at 01:05
  • GCC 4.9.4 was released seven years ago. Have you considered using a newer compiler, preferably the one that matches what the rest of your system was built again? – Botje May 15 '23 at 08:32
  • This jumps out at me: `#0 0x000044ae in ?? ()` That looks like something in `ld-2.17.so` thinks the initial executable code should be mapped to a page at zero offset instead of the "normal" `00400000` offset on Linux. What's the address space map of the process look like? – Andrew Henle May 15 '23 at 12:06
  • See [**allocating address zero on Linux with mmap fails**](https://stackoverflow.com/questions/63790813/allocating-address-zero-on-linux-with-mmap-fails). Does your processes run as `root`, which *can* map a page at a zero offset? – Andrew Henle May 15 '23 at 12:08
  • Or you could set `/proc/sys/vm/mmap_min_addr` to zero. Be aware that can compromise security as your process and the kernel share the same address space on Linux, so it's possible to exploit a kernel NULL-pointer dereference to run arbitrary code in kernel mode when mapping to a zero address is allowed. – Andrew Henle May 15 '23 at 12:27
  • @Botje This gcc is far newer than the rest of my system, so it wouldn't change anything. – user2752471 May 15 '23 at 23:47
  • @EmployedRussian. I edited the question with the result of info shared – user2752471 May 15 '23 at 23:47
  • @AndrewHenle. Hi. I edited the question with the output of gdb: "info proc mappings". To answer your question, no I am executing my little test program as an ordinary program. From the link you posted, it should have worked as root, right? Unfortunately, it didn't change anything running it as root under gdb – user2752471 May 16 '23 at 00:03
  • @JesperJuhl. What's the problem with putting sym links to gcc on /usr/local/bin? Anyway, is there an alternative to it? (that isn't to install it to /usr/local/bin?. Latter I will give a deeper look in your link to see what I can learn about diagnosing segfaults – user2752471 May 16 '23 at 00:06
  • I added the command that I (likely) used to build Glibc, in case it might be related with it starting my process in the incorrect memory area. – user2752471 May 16 '23 at 00:07
  • @user2752471 It *might* have worked as root - if `ld-2.17.so` was trying to both load your code at a zero address and run it from there. It appears it's loading executables at `0x8048000` but expecting to run `main()` at some offset from the zero address. One way to check if that's what's actually happening is to use `gdb` to get the address of `main()` and subtract `0x8048000` from it and see if that matches the `SIGSEGV` fault address. – Andrew Henle May 16 '23 at 00:38
  • @AndrewHenle "info address main" returned 0x80486ec. Doing 0x80486ec - 0x8048000 gave me 6EC. So not very useful, I guess? – user2752471 May 20 '23 at 17:42

0 Answers0