Follow-up Comment #3, bug #66158 (group screen):

Thank you for your answer!

_What OS do you use?_
[http://archlinux.org/ Arch Linux]

_How did you build screen?_
I didn't because I used the precompiled Arch package. According to
[https://bbs.archlinux.org/viewtopic.php?pid=2189095#p2189095 this Arch forum
post], the compile flags are on the default makepkg.conf file. Here is an
excerpt from my:


#########################################################################
# ARCHITECTURE, COMPILE FLAGS
#########################################################################
#
CARCH="x86_64"
CHOST="x86_64-pc-linux-gnu"

#-- Compiler and Linker Flags
#CPPFLAGS=""
CFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions \
        -Wp,-D_FORTIFY_SOURCE=3 -Wformat -Werror=format-security \
        -fstack-clash-protection -fcf-protection \
        -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer"
CXXFLAGS="$CFLAGS -Wp,-D_GLIBCXX_ASSERTIONS"
LDFLAGS="-Wl,-O1 -Wl,--sort-common -Wl,--as-needed -Wl,-z,relro -Wl,-z,now \
         -Wl,-z,pack-relative-relocs"
LTOFLAGS="-flto=auto"
RUSTFLAGS="-Cforce-frame-pointers=yes"
#-- Make Flags: change this for DistCC/SMP systems
#MAKEFLAGS="-j2"
#-- Debugging flags
DEBUG_CFLAGS="-g"
DEBUG_CXXFLAGS="$DEBUG_CFLAGS"
DEBUG_RUSTFLAGS="-C debuginfo=2"


_Can you try to get the gdb stack from this segfault?_
Following the tips on the
[https://wiki.archlinux.org/title/Core_dump#Analyzing_a_core_dump Arch wiki]:


$ coredumpctl info 3097
...
                Stack trace of thread 3097:
                #0  0x00007bd200d773f4 n/a (libc.so.6 + 0x963f4)
                #1  0x00007bd200d1e120 raise (libc.so.6 + 0x3d120)
                #2  0x00007bd200d054c3 abort (libc.so.6 + 0x244c3)
                #3  0x00007bd200d06354 n/a (libc.so.6 + 0x25354)
                #4  0x00007bd200e06799 __fortify_fail (libc.so.6 + 0x125799)
                #5  0x00007bd200e06124 __chk_fail (libc.so.6 + 0x125124)
                #6  0x00007bd200e07d39 __strncpy_chk (libc.so.6 + 0x126d39)
                #7  0x000059af9ec82190 n/a (screen-5.0.0 + 0x5190)
                #8  0x00007bd200d06e08 n/a (libc.so.6 + 0x25e08)
                #9  0x00007bd200d06ecc __libc_start_main (libc.so.6 +
0x25ecc)
                #10 0x000059af9ec83bd5 n/a (screen-5.0.0 + 0x6bd5)
                ELF object binary architecture: AMD x86-64

There are per default no symbols in the binaries. Starting screen with the
program downloads the debug information (I'm impressed about that btw), but
running the program just hangs the terminal, "Ctrl-C", "Ctrl-Z", "q" doesn't
do anything and I have to kill gdb by sending TERM.

$ gdb --args screen -X source /tmp/screenrc
Reading symbols from screen...

This GDB supports auto-downloading debuginfo from the following URLs:
  <https://debuginfod.archlinux.org>
Enable debuginfod for this session? (y or [n]) y
Debuginfod has been enabled.
To make this setting permanent, add 'set debuginfod enabled on' to .gdbinit.
Reading symbols from
/home/user/.cache/debuginfod_client/9d742cd03e4f4867744f279b3b229c18bd9f8e65/debuginfo...
(gdb) r
Starting program: /usr/bin/screen -X source /tmp/screenrc
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".

It seems to me the started process does not crash then, but I don't know how
to check that or interact with it. Do you have a hint, maybe?

_Can you try to reproduce it without existing screen sessions?_
Could you point me what command I should execute then?

As background information: In my default setup, I want to
* always have a screen session running
* reattach to the previous screen session when (accidentally) closing the
terminal emulator
so I added the line `screen -xRR autoscreen` to my ~/.bashrc. The bug occurs
in this setup.

When I remove the line from my bashrc, Ctrl-D the screen and terminal
emulator, restart and

$ screen -ls
No Sockets found in /home/user/.screen.

$ screen -xRR autoscreen -c /tmp/screenrc
$ screen -ls
There is a screen on:
        5516.autoscreen (Attached)
1 Socket in /home/user/.screen.
$ 

a new screen session is successfully started.


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?66158>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/

Attachment: signature.asc
Description: PGP signature

Reply via email to