[Bug gdb/31093] New: Random failures in gdb.gdb/index-file.exp (too much memory?)

[Bug gdb/31093] New: Random failures in gdb.gdb/index-file.exp (too much memory?)

[simark at simark dot ca]

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

            Bug ID: 31093
           Summary: Random failures in gdb.gdb/index-file.exp (too much
                    memory?)
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: gdb
          Assignee: unassigned at sourceware dot org
          Reporter: simark at simark dot ca
  Target Milestone: ---

On my CI, I've seen twice failures in gdb.gdb/index-file.exp.  I did not figure
out the reason, and have not been able to reproduce locally.

~~~
Using /usr/share/dejagnu/baseboards/unix.exp as board description file for
target.
Using /usr/share/dejagnu/config/unix.exp as generic interface file for target.
Using
/home/jenkins/workspace/binutils-gdb_master_linuxbuild/platform/deb12-amd64/target_board/unix/src/binutils-gdb/gdb/testsuite/config/unix.exp
as tool-and-target-specific interface file.
Running
/home/jenkins/workspace/binutils-gdb_master_linuxbuild/platform/deb12-amd64/target_board/unix/src/binutils-gdb/gdb/testsuite/gdb.gdb/index-file.exp
...
Downloading on host to
/home/jenkins/workspace/binutils-gdb_master_linuxbuild/platform/deb12-amd64/target_board/unix/tmp/tmp.8a1kZQUJPh/gdb/testsuite/outputs/gdb.gdb/index-file/xgdb:
/home/jenkins/workspace/binutils-gdb_master_linuxbuild/platform/deb12-amd64/target_board/unix/tmp/tmp.8a1kZQUJPh/gdb/testsuite/../../gdb/gdb
builtin_spawn
/home/jenkins/workspace/binutils-gdb_master_linuxbuild/platform/deb12-amd64/target_board/unix/tmp/tmp.8a1kZQUJPh/gdb/testsuite/../../gdb/gdb
-nw -nx -q -iex set height 0 -iex set width 0 -data-directory
/home/jenkins/workspace/binutils-gdb_master_linuxbuild/platform/deb12-amd64/target_board/unix/tmp/tmp.8a1kZQUJPh/gdb/data-directory
(gdb) set height 0
(gdb) set width 0
(gdb) dir
Reinitialize source path to empty? (y or n) y
Source directories searched: $cdir:$cwd
(gdb) dir
/home/jenkins/workspace/binutils-gdb_master_linuxbuild/platform/deb12-amd64/target_board/unix/src/binutils-gdb/gdb/testsuite/gdb.gdb
Source directories searched:
/home/jenkins/workspace/binutils-gdb_master_linuxbuild/platform/deb12-amd64/target_board/unix/src/binutils-gdb/gdb/testsuite/gdb.gdb:$cdir:$cwd
(gdb) kill
The program is not being run.
(gdb) file
/home/jenkins/workspace/binutils-gdb_master_linuxbuild/platform/deb12-amd64/target_board/unix/tmp/tmp.8a1kZQUJPh/gdb/testsuite/outputs/gdb.gdb/index-file/xgdb
Reading symbols from
/home/jenkins/workspace/binutils-gdb_master_linuxbuild/platform/deb12-amd64/target_board/unix/tmp/tmp.8a1kZQUJPh/gdb/testsuite/outputs/gdb.gdb/index-file/xgdb...
(gdb) maintenance show worker-threads
The number of worker threads GDB can use is unlimited (currently 8).
(gdb) Executing on host: mkdir -p
/home/jenkins/workspace/binutils-gdb_master_linuxbuild/platform/deb12-amd64/target_board/unix/tmp/tmp.8a1kZQUJPh/gdb/testsuite/outputs/gdb.gdb/index-file/index_1
   (timeout = 300)
builtin_spawn -ignore SIGHUP mkdir -p
/home/jenkins/workspace/binutils-gdb_master_linuxbuild/platform/deb12-amd64/target_board/unix/tmp/tmp.8a1kZQUJPh/gdb/testsuite/outputs/gdb.gdb/index-file/index_1
save gdb-index
/home/jenkins/workspace/binutils-gdb_master_linuxbuild/platform/deb12-amd64/target_board/unix/tmp/tmp.8a1kZQUJPh/gdb/testsuite/outputs/gdb.gdb/index-file/index_1
ERROR: GDB process no longer exists
GDB process exited with wait status 402279 exp6 0 0 CHILDKILLED SIGKILL {kill
signal}
UNRESOLVED: gdb.gdb/index-file.exp: create gdb-index file
~~~

Notice that GDB gets killed with SIGKILL.  dmesg shows that a process was
killed by the Linux OOM killer at the exact time, so I'm pretty sure that this
is what sent SIGKILL to the GDB process.  My CI runs the testsuite in parallel,
so that can explain the randomness, depending on what runs alongside that test,
we might or might not exhaust the memory.

Perhaps that's just the way it is and this operation needs to take a lot of
memory, but it would be good to check if there is anything obvious that can be
done about it (like plugging a memory leak).

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