[Bug gdb/31207] New: info proc mappings returns no maps when the main thread exitted

[Bug gdb/31207] New: info proc mappings returns no maps when the main thread exitted

[dominik.b.czarnota+bugzilla at gmail dot com]

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

            Bug ID: 31207
           Summary: info proc mappings returns no maps when the main
                    thread exitted
           Product: gdb
           Version: HEAD
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: gdb
          Assignee: unassigned at sourceware dot org
          Reporter: dominik.b.czarnota+bugzilla at gmail dot com
  Target Milestone: ---

Hi,

There is a case where the /proc/$pid/maps file may return no data when the main
thread of a process exitted but other threads are still running and being
debugged.

This can be reproduced with the following program:

```
#include <pthread.h>
#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>

void *thread_function(void *arg) {
  sleep(2);
  // trigger a crash and so a GDB stop :)
  *(int*)(0xdeadbeef) = 0x1234;
  return NULL;
}

int main(void) {
  pthread_t thread;
  pthread_create(&thread, NULL, thread_function, NULL);
  pthread_exit(NULL);
  return 0;
}
```

And then compiled and run the following way:

```
root@pwndbg:~/pwndbg# gcc a.c -lpthread
root@pwndbg:~/pwndbg# gdb --nx --quiet ./a.out
Reading symbols from ./a.out...
(No debugging symbols found in ./a.out)
(gdb) version
Undefined command: "version".  Try "help".
(gdb)
quit
root@pwndbg:~/pwndbg# gdb --nx ./a.out
GNU gdb (Ubuntu 12.1-0ubuntu1~22.04) 12.1
Copyright (C) 2022 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 "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://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 ./a.out...
(No debugging symbols found in ./a.out)
(gdb) run
Starting program: /root/pwndbg/a.out
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff7d84640 (LWP 3392368)]
[Thread 0x7ffff7d85740 (LWP 3392365) exited]

Thread 2 "a.out" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff7d84640 (LWP 3392368)]
0x00005555555551a8 in thread_function ()
(gdb) info proc mappings
process 3392365
Mapped address spaces:

          Start Addr           End Addr       Size     Offset  Perms  objfile
(gdb) !cat /proc/3392365/maps
(gdb) !ls -lah /proc/3392365/maps
-r--r--r-- 1 root root 0 Jan  2 16:58 /proc/3392365/maps
(gdb) !cat /proc/3392368/maps
555555554000-555555555000 r--p 00000000 fc:01 277317                    
/root/pwndbg/a.out
555555555000-555555556000 r-xp 00001000 fc:01 277317                    
/root/pwndbg/a.out
555555556000-555555557000 r--p 00002000 fc:01 277317                    
/root/pwndbg/a.out
555555557000-555555558000 r--p 00002000 fc:01 277317                    
/root/pwndbg/a.out
555555558000-555555559000 rw-p 00003000 fc:01 277317                    
/root/pwndbg/a.out
555555559000-55555557a000 rw-p 00000000 00:00 0                          [heap]
7ffff7564000-7ffff7567000 r--p 00000000 fc:01 18111                     
/usr/lib/x86_64-linux-gnu/libgcc_s.so.1
7ffff7567000-7ffff757e000 r-xp 00003000 fc:01 18111                     
/usr/lib/x86_64-linux-gnu/libgcc_s.so.1
7ffff757e000-7ffff7582000 r--p 0001a000 fc:01 18111                     
/usr/lib/x86_64-linux-gnu/libgcc_s.so.1
7ffff7582000-7ffff7583000 r--p 0001d000 fc:01 18111                     
/usr/lib/x86_64-linux-gnu/libgcc_s.so.1
7ffff7583000-7ffff7584000 rw-p 0001e000 fc:01 18111                     
/usr/lib/x86_64-linux-gnu/libgcc_s.so.1
7ffff7584000-7ffff7585000 ---p 00000000 00:00 0
7ffff7585000-7ffff7d88000 rw-p 00000000 00:00 0
7ffff7d88000-7ffff7db0000 r--p 00000000 fc:01 8934                      
/usr/lib/x86_64-linux-gnu/libc.so.6
7ffff7db0000-7ffff7f45000 r-xp 00028000 fc:01 8934                      
/usr/lib/x86_64-linux-gnu/libc.so.6
7ffff7f45000-7ffff7f9d000 r--p 001bd000 fc:01 8934                      
/usr/lib/x86_64-linux-gnu/libc.so.6
7ffff7f9d000-7ffff7fa1000 r--p 00214000 fc:01 8934                      
/usr/lib/x86_64-linux-gnu/libc.so.6
7ffff7fa1000-7ffff7fa3000 rw-p 00218000 fc:01 8934                      
/usr/lib/x86_64-linux-gnu/libc.so.6
7ffff7fa3000-7ffff7fb0000 rw-p 00000000 00:00 0
7ffff7fbb000-7ffff7fbd000 rw-p 00000000 00:00 0
7ffff7fbd000-7ffff7fc1000 r--p 00000000 00:00 0                          [vvar]
7ffff7fc1000-7ffff7fc3000 r-xp 00000000 00:00 0                          [vdso]
7ffff7fc3000-7ffff7fc5000 r--p 00000000 fc:01 8929                      
/usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
7ffff7fc5000-7ffff7fef000 r-xp 00002000 fc:01 8929                      
/usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
7ffff7fef000-7ffff7ffa000 r--p 0002c000 fc:01 8929                      
/usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
7ffff7ffb000-7ffff7ffd000 r--p 00037000 fc:01 8929                      
/usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
7ffff7ffd000-7ffff7fff000 rw-p 00039000 fc:01 8929                      
/usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
7ffffffde000-7ffffffff000 rw-p 00000000 00:00 0                         
[stack]
ffffffffff600000-ffffffffff601000 --xp 00000000 00:00 0                 
[vsyscall]
(gdb)
```

As we can see, the `info proc mappings` command returns no memory mappings.
This is because the kernel does not render any content of the /proc/$pid/maps
file since the main thread has exitted already.

However, the kernel still allows us to read the memory mappings of the process
from the /proc/$tid/maps file.

I believe GDB should by default read that file instead and return the memory
mappings of the current thread instead of always referring to current PID.

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