On 06-Nov-2021, Ben Finney wrote: > When I invoke GDB on the core dump, this is the session: > > ===== > $ coredumpctl gdb > […] > PID: 45094 (bash) > UID: 1000 (bignose) > GID: 1000 (bignose) > Signal: 11 (SEGV) > Timestamp: Sat 2021-11-06 23:01:32 AEDT (54s ago) > Command Line: -/bin/bash -c $'/usr/bin/gnome-session -l ' > Executable: /usr/bin/bash > […] > #62 0x000055c7801d075b execute_command_internal (bash + > 0x4a75b) > #63 0x000055c780222bd9 parse_and_execute (bash + 0x9cbd9)
After a lot of narrowing down what in this user's session could cause Bash to segmentation fault, I've found that this makes the difference: * When the user's home directory contains ‘$HOME/.gnomerc’, the Bash segmentation fault occurs. The content of ‘$HOME/.gnomerc’ is: ===== # $HOME/.gnomerc # Roaming profile: User specific configuration for GNOME session. . ~/.profile ===== which simply “sources” the user's shell profile script. This file (and the ‘$HOME/.profile’) has been present for years with the same content, without incident on previous Gnome or Bash versions. * When the user's home directory does not contain ‘$HOME/.gnomerc’, the user login works fine, as it did a month ago. So the Gnome session is (I assume) invoking that script, which in turn sources the ‘$HOME/.profile’ script; and somehow that causes Bash to segfault. This same ‘$HOME/.profile’ script is large and somewhat sensitive; but it should never cause Bash to crash, and never does cause it to crash when logging in outside Gnome. -- \ “In any great organization it is far, far safer to be wrong | `\ with the majority than to be right alone.” —John Kenneth | _o__) Galbraith, 1989-07-28 | Ben Finney <bign...@debian.org>
signature.asc
Description: PGP signature
