...but I don't think it's a problem with x3270, as it was last updated on Jun 1 and I've updated sever times since then and used x3270 repratedly without problems. Here's the bt: [ftg@ftglap ~]$ gdb x3270 GNU gdb (GDB) 9.1-3.mga8 (Mageia release 8) Copyright (C) 2020 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-mageia-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://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 x3270... Reading symbols from .gnu_debugdata for /usr/bin/x3270... (No debugging symbols found in .gnu_debugdata for /usr/bin/x3270) Missing separate debuginfos, use: debuginfo-install x3270-4.0ga9-3.mga8.x86_64 (gdb) r Starting program: /usr/bin/x3270 [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. 0x00007ffff7943ae1 in __strlen_avx2 () from /lib64/libc.so.6 (gdb) bt #0 0x00007ffff7943ae1 in __strlen_avx2 () from /lib64/libc.so.6 #1 0x0000000000431e32 in relabel () #2 0x000000000043c85b in st_changed () #3 0x00000000004097a8 in main () (gdb) quit I'm guessing this has to do with the latest glibc update.
Thank you Frank for this report. From what you say, that x3270 worked after its last update 1 June, but now crashes - can you confirm that glibc was updated just before the crashes started? $ rpm -qa --last | grep glibc for example.
CC: (none) => lewyssmith
No, that's not it: [root@ftglap tgz]# rpm -qa --last | grep glibc glibc-profile-2.31-12.mga8.x86_64 Thu 21 May 2020 08:39:09 PM EDT glibc-devel-2.31-12.mga8.x86_64 Thu 21 May 2020 08:12:14 PM EDT glibc-2.31-12.mga8.x86_64 Thu 21 May 2020 08:12:11 PM EDT lib64glibc_lsb-2.4.7-14.mga8.x86_64 Thu 13 Feb 2020 02:14:06 PM EST [root@ftglap tgz]# But I could have sworn I saw some sort of libc update go by in recent days. However, the latest timestamp for any *libc* package is May 23, so no luck there either. Here's a possibility: it is x3270, but since Jun 1 I may have kept an x3270 window open although at times unconnected to a mainframe. So it would have been using the x3270 module from before Jun 1, and I only got the current module when I recently reboted and had to re-execute x3270.
Thanks for the glibc check. > I could have sworn I saw some sort of libc update go by in recent days The last update I can see in Cauldron is Wed May 20. x3270 was, as you say, updated 1 June. This problem could theoretically be due to the subsequent update of another package, now difficult to identify. Or, as you suggest, that the program was left running during & after its update, and the fault only manifested itself when it was re-started for the first time subsequently. Assigning this to DavidG, its maintainer.
Assignee: bugsquad => geiger.david68210CC: lewyssmith => (none)
Backleveling to x3270-3.6ga6-1.mga7.x86_64.rpm works fine. The problem apears to be with x3270-4.
Is this issue still valid on current cauldron?
Nope, I just tested and it's working again.
Resolution: (none) => FIXEDStatus: NEW => RESOLVED