Bug#860751: win32-loader: FTBFS on i386: segmentation fault
Control: fixed -1 1.3.4.20200120-1 Dear Maintainer, I just wondered why this bug not gets archived. Due to [1], it is fixed in unstable and testing, is installed for all architectures [2], and is not release-critical. So I guess it might be the version that existed just in experimental, therefore adding the fixed version 1.3.4.20200120-1. Kind regards, Bernhard [1] https://wiki.debian.org/HowtoUseBTS#Version_tracking [2] https://buildd.debian.org/status/package.php?p=mawk
Bug#992721: hplip: Scanning with Deskjet 3050A J611 crash
Am 21.09.21 um 18:36 schrieb Florence Birée: Hi, I applied the patch and try it on hplip 3.21.6+dfsg0-1. No more stack smashing. But at a random point during the scan, simple-scan stop and display a message : « Failed to scan - Error communicating with scanner ». Nothing in the terminal nor in journald. The random point where it failed is random in the sense of when I scan, I can show the beginning of the scanned picture appear in simple-scan, and at one point (sometimes at the begining, sometimes near the end), the error message appear. Cheers, Florence Hello Florence, so the patch helps for the stack smashing, but the error message might have other reasons. The message itself is located in one of these lines [1] in simple-scan. You could try to run simple-scan with some environment variables, to active some more verbose debugging output. I think these in [2] coult already be quite verbose. [1] https://sources.debian.org/src/simple-scan/40.5-1/src/scanner.vala/#L1368 https://sources.debian.org/src/simple-scan/40.5-1/src/scanner.vala/#L1479 [2] script -c "SANE_DEBUG_DLL=255 SANE_DEBUG_ESCL=255 SANE_DEBUG_SANEI_TCP=255 simple-scan" -a ~/simple-scan-debug-output.txt
Bug#992721: hplip: Scanning with Deskjet 3050A J611 crash
Hello Florence, dear Maintainer,
then attached patch is growing this buffer from 6
to 10 usable bytes, making a size around 1 TB possible.
And tries to break the loop before overrunning the buffer.
Unfortunately I cannot test this patch,
so it is completely untested, just compiles...
Kind regards,
Bernhard
Description: Resize buffer and try not to overrun it
Author: Bernhard Übelacker
Bug-Debian: https://bugs.debian.org/992721
Forwarded: no
Last-Update: 2021-09-20
Index: hplip-3.21.6+dfsg0/scan/sane/bb_ledm.c
===
--- hplip-3.21.6+dfsg0.orig/scan/sane/bb_ledm.c
+++ hplip-3.21.6+dfsg0/scan/sane/bb_ledm.c
@@ -1085,7 +1085,7 @@ bugout:
int get_size(struct ledm_session* ps)
{
struct bb_ledm_session *pbb = ps->bb_session;
- char buffer[7];
+ char buffer[11];
int i=0, tmo=50, len;
if(ps->currentResolution >= 1200) tmo *= 5;
@@ -1093,7 +1093,11 @@ int get_size(struct ledm_session* ps)
while(1)
{
if(http_read_size(pbb->http_handle, buffer+i, 1, tmo, ) == 2) return 0;
-if( i && *(buffer+i) == '\n' && *(buffer+i-1) == '\r') break;
+if( (i && *(buffer+i) == '\n' && *(buffer+i-1) == '\r') ||
+(i >= sizeof(buffer)-1) )
+{
+ break;
+}
i++;
}
*(buffer+i+1)='\0';
Bug#992871: darkplaces: Segfault when using custom texturepack
Dear Maintainer,
I found now another way to get it working by removing the
intermediate function my_setjmp, like in attached patch.
It looks like the compiler needs to be aware of the setjmp.
Before this patch, I tried defining my_setjmp with attribute
returns_twice, but that was not enough.
Kind regards,
Bernhard
Description: Replace my_setjmp by original setjmp
Author: Bernhard Übelacker
Bug-Debian: https://bugs.debian.org/992871
Forwarded: no
Last-Update: 2021-09-18
Index: darkplaces-0~20180908~beta1/image_png.c
===
--- darkplaces-0~20180908~beta1.orig/image_png.c
+++ darkplaces-0~20180908~beta1/image_png.c
@@ -36,16 +36,6 @@
// implementations of setjmp()/longjmp() (it either does or doesn't save the
// signal mask), acting on different definitions of the jmp_buf struct.
# include
-
-// libpng calls longjmp() internally, and expects its callers to call the
-// version of setjmp() corresponding to the longjmp() call that libpng would
-// make. Set this up before including any other headers that might
-// change which flavour of setjmp() we get.
-static inline int
-my_setjmp (jmp_buf env)
-{
- return setjmp (env);
-}
#endif
#include "quakedef.h"
@@ -54,7 +44,7 @@ my_setjmp (jmp_buf env)
#ifdef LINK_TO_PNG
-#define qpng_setjmp(png) my_setjmp (png_jmpbuf (png))
+#define qpng_setjmp(png) (setjmp (png_jmpbuf (png)))
#define qpng_set_sig_bytes png_set_sig_bytes
#define qpng_sig_cmp png_sig_cmp
Bug#993471: mc crashes if ftp server specified on cmdline requires authentication
Dear Maintainer, I tried to have a look and received the backtrace below [3]. As far as I see is 4.8.27 in current testing not affected. And a 'git bisect' led to the upstream commit [1], which is tracked in upstream bug [2]. A package 4.8.26 built with this commit is also working as expected (see attached patch). Kind regards, Bernhard [1] https://github.com/MidnightCommander/mc/commit/0375997c789eef9b6355aadd80aaf4aced68c560 [2] https://midnight-commander.org/ticket/4244 [3] Program terminated with signal SIGSEGV, Segmentation fault. #0 widget_set_size (w=0x0, y=y@entry=59, x=, lines=lines@entry=1, cols=cols@entry=19) at widget-common.c:450 450 if (w->owner != NULL && widget_get_state (WIDGET (w->owner), WST_ACTIVE)) (gdb) set width 0 (gdb) set pagination off (gdb) bt #0 widget_set_size (w=0x0, y=y@entry=59, x=, lines=lines@entry=1, cols=cols@entry=19) at widget-common.c:450 #1 0x55d9c539ae14 in setup_cmdline () at layout.c:999 #2 0x55d9c53f54d0 in set_prompt_string () at common.c:728 #3 set_prompt_string () at common.c:720 #4 read_subshell_prompt () at common.c:1575 #5 0x55d9c539be56 in do_load_prompt () at layout.c:1473 #6 0x55d9c539bee6 in load_prompt (fd=, unused=) at layout.c:1502 #7 0x55d9c5397a4a in check_selects (select_set=select_set@entry=0x7ffe62e65cd0) at key.c:618 #8 0x55d9c53998e1 in tty_get_event (event=event@entry=0x7ffe62e65da0, redo_event=0, block=block@entry=1) at key.c:2055 #9 0x55d9c5380d01 in frontend_dlg_run (h=0x55d9c66744c0) at dialog.c:318 #10 dlg_run (h=h@entry=0x55d9c66744c0) at dialog.c:575 #11 0x55d9c53ad165 in quick_dialog_skip (quick_dlg=quick_dlg@entry=0x7ffe62e65ed0, nskip=, nskip@entry=1) at quick.c:581 #12 0x55d9c53c01c6 in quick_dialog (quick_dlg=0x7ffe62e65ed0) at ../../lib/widget/quick.h:353 #13 fg_input_dialog_help (header=0x55d9c66732c0 "FTP: Passwort benötigt für ftpuser", text=, help=0x55d9c5428833 "[Input Line Keys]", history_name=, def_text=0x55d9c542e960 "", strip_password=0, completion_flags=INPUT_COMPLETE_NONE) at wtools.c:226 #14 0x55d9c53c0eeb in input_dialog (header=header@entry=0x55d9c66732c0 "FTP: Passwort benötigt für ftpuser", text=, history_name=history_name@entry=0x55d9c542872a "mc.vfs.password", def_text=def_text@entry=0x , completion_flags=completion_flags@entry=INPUT_COMPLETE_NONE) at wtools.c:506 #15 0x55d9c53be3f4 in vfs_get_password (msg=msg@entry=0x55d9c66732c0 "FTP: Passwort benötigt für ftpuser") at utilvfs.c:365 #16 0x55d9c53c5d21 in ftpfs_login_server (me=me@entry=0x55d9c5479e60 , super=super@entry=0x55d9c6673210, netrcpass=netrcpass@entry=0x0) at ftpfs.c:643 #17 0x55d9c53c7bb8 in ftpfs_open_archive_int (super=0x55d9c6673210, me=0x55d9c5479e60 ) at ftpfs.c:973 #18 ftpfs_open_archive (super=0x55d9c6673210, vpath=, vpath_element=) at ftpfs.c:1028 #19 0x55d9c53ccb1b in vfs_s_get_path (vpath=vpath@entry=0x55d9c6672f10, archive=archive@entry=0x7ffe62e66450, flags=flags@entry=0) at direntry.c:1207 #20 0x55d9c53ccc29 in vfs_s_inode_from_path (vpath=vpath@entry=0x55d9c6672f10, flags=flags@entry=5) at direntry.c:398 #21 0x55d9c53cce01 in vfs_s_opendir (vpath=0x55d9c6672f10) at direntry.c:426 #22 0x55d9c53cce86 in vfs_s_chdir (vpath=) at direntry.c:496 #23 0x55d9c5397167 in mc_chdir (vpath=vpath@entry=0x55d9c6672d20) at interface.c:678 #24 0x55d9c5387f95 in create_panels () at filemanager.c:665 #25 create_file_manager () at filemanager.c:924 #26 do_nc () at filemanager.c:1836 #27 0x55d9c53754d1 in main (argc=, argv=) at main.c:463 commit 0375997c789eef9b6355aadd80aaf4aced68c560 Author: Andrew Borodin Date: Tue May 18 10:09:33 2021 +0300 Ticket #4244: fix segfault on dialog before panels get visible. If some small dialog (error message or password request) is displayed before main mc window gets visible, the segfault occures. The cause of segfault is update of prompt that is not created yet. (setup_mc, create_file_manager): move creation of event channel from setup_mc() to create_file_manager(), make that after creation of all file manager widgets. Signed-off-by: Andrew Borodin Index: mc-4.8.26/src/filemanager/filemanager.c === --- mc-4.8.26.orig/src/filemanager/filemanager.c +++ mc-4.8.26/src/filemanager/filemanager.c @@ -858,11 +858,6 @@ setup_mc (void) #endif /* HAVE_CHARSET */ #endif /* HAVE_SLANG */ -#ifdef ENABLE_SUBSHELL -if (mc_global.tty.use_subshell) -add_select_channel (mc_global.tty.subshell_pty, load_prompt, NULL); -#endif /* !ENABLE_SUBSHELL */ - if ((tty_baudrate () < 9600) || mc_global.tty.slow_terminal) verbose = FALSE; } @@ -941,6 +936,13 @@ create_file_manager (void) the_bar = buttonbar_new (mc_global.keybar_visible); group_add_widget (g, the_bar); midnight_set_buttonbar (the_bar); + +#ifdef ENABLE_SUBSHELL +/* Must
Bug#994429: gimp: missing SANE option under File > Create menu
Dear Maintainer, this might be the same as reported in #993293 against the xsane package. Kind regards, Bernhard https://bugs.debian.org/993293
Bug#992721: hplip: Scanning with Deskjet 3050A J611 crash
Am 16.09.21 um 00:29 schrieb Bernhard Übelacker: exceeds what is with these 7 places possible (would be 268 MB ?) Short correction: 6 bytes for the hex number and 1 byte termination. Would just give something around 16 MB as a maximum? Kind regards, Bernhard
Bug#992721: hplip: Scanning with Deskjet 3050A J611 crash
Hello Florence, dear Maintainer,
Stack trace of thread 113079:
#0 0x7f858b12ae71 raise
(libc.so.6 + 0x3ce71)
#1 0x7f858b114536 abort
(libc.so.6 + 0x26536)
#2 0x7f858b16c2b8 n/a
(libc.so.6 + 0x7e2b8)
#3 0x7f858b1fad42
__fortify_fail (libc.so.6 + 0x10cd42)
#4 0x7f858b1fad20
__stack_chk_fail (libc.so.6 + 0x10cd20)
#5 0x7f857c763146
get_size (libsane-hpaio.so.1 + 0x14146)
#6 0x n/a
(n/a + 0x0)
Thanks for the fast response.
From looking at this stack trace I assume a stack variable in
function "get_size" gets overwritten. At the end of this function
the stack check gets triggered.
From looking at [1] I _think_ the issue might be with the
variable "char buffer[7]".
It looks like this buffer gets some hexadecimal size
information written to from a http connection.
Therefore my hypothesis is that either this "size" exceeds what
is with these 7 places possible (would be 268 MB ?),
or some unexpected input is read from the connection and
therefore the loop is not left before the buffer is overrun.
One easy thing might be to test if the resolution could be
changed to some lower value in the hope to get this "size" to
a lower value, does the scan then succeed ?
Kind regards,
Bernhard
[1]
https://sources.debian.org/src/hplip/3.21.6+dfsg0-1/scan/sane/bb_ledm.c/#L1086
1084
1085int get_size(struct ledm_session* ps)
1086{
1087 struct bb_ledm_session *pbb = ps->bb_session;
1088 char buffer[7];
1089 int i=0, tmo=50, len;
1090
1091 if(ps->currentResolution >= 1200) tmo *= 5;
1092
1093 while(1)
1094 {
1095if(http_read_size(pbb->http_handle, buffer+i, 1, tmo, ) ==
2) return 0;
1096if( i && *(buffer+i) == '\n' && *(buffer+i-1) == '\r') break;
1097i++;
1098 }
1099 *(buffer+i+1)='\0';
1100 return strtol(buffer, NULL, 16);
1101}
1102
[2] https://sources.debian.org/src/hplip/3.21.6+dfsg0-1/scan/sane/http.c/#L513
# Bullseye/stable amd64 qemu VM 2021-09-15
echo "set enable-bracketed-paste off" >> /etc/inputrc; bash
apt update
apt dist-upgrade
apt install mc gdb simple-scan hplip
apt install simple-scan-dbgsym libsane-hpaio-dbgsym
apt build-dep libsane-hpaio
mkdir /home/benutzer/source/libsane-hpaio/orig -p
cd/home/benutzer/source/libsane-hpaio/orig
apt source libsane-hpaio
cd
benutzer@debian:~$ gdb -q
(gdb) set width 0
(gdb) set pagination off
(gdb) file /usr/bin/simple-scan
Reading symbols from /usr/bin/simple-scan...
Reading symbols from
/usr/lib/debug/.build-id/31/8e835860dafff5fa45c03cb758e8cae5a11fa0.debug...
(gdb) tb main
Temporary breakpoint 1 at 0xe160: file src/simple-scan.p/simple-scan.c, line
2434.
(gdb) run
Starting program: /usr/bin/simple-scan
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Temporary breakpoint 1, main (argc=1, argv=0x7fffe618) at
src/simple-scan.p/simple-scan.c:2434
2434src/simple-scan.p/simple-scan.c: Datei oder Verzeichnis nicht gefunden.
(gdb) call dlopen("/usr/lib/x86_64-linux-gnu/sane/libsane-hpaio.so.1",0x102)
$1 = (void *) 0x555da300
(gdb) b get_size
Breakpoint 2 at 0x73618080: file scan/sane/bb_ledm.c, line 1086.
(gdb) disassemble get_size,get_size+200
Dump of assembler code from 0x73618080 to 0x73618148:
0x73618080 : push %r15
0x73618082 : push %r14
0x73618084 : push %r13
0x73618086 : push %r12
0x73618088 : mov$0x32,%r12d
0x7361808e :push %rbp
0x7361808f :push %rbx
0x73618090 :sub$0x28,%rsp
0x73618094 :mov0x89b0(%rdi),%r15
0x7361809b :mov%fs:0x28,%rax
0x736180a4 :mov%rax,0x18(%rsp)
0x736180a9 :xor%eax,%eax
0x736180ab :lea0x11(%rsp),%r13
0x736180b0 :mov$0xfa,%eax
0x736180b5 :cmpl $0x4b0,0x744(%rdi)
0x736180bf :cmovge %eax,%r12d
0x736180c3 :mov%r13,%rbx
0x736180c6 :lea0xc(%rsp),%r14
0x736180cb :xor%ebp,%ebp
0x736180cd :jmp0x736180d8
0x736180cf :nop
0x736180d0 :add$0x1,%rbp
0x736180d4 :add$0x1,%rbx
0x736180d8 :mov0x1f0(%r15),%rdi
0x736180df :mov%r14,%r8
Bug#993210: mate-session-manager: mate-settings-daemon crashed
Dear Maintainer, hello Mihai, I tried to reconstruct the source line information of the top frames, how they should look like if the packages libgtk-3-0-dbgsym libglib2.0-0-dbgsym would have been installed. #0 0x7fec909d1ce1 in __libc_signal_restore_set at ../sysdeps/unix/sysv/linux/internal-signals.h:86 #1 0x7fec909bb537 in __GI_abort at abort.c:79 #2 0x7fec90b99dcc in g_assertion_message at ../../../glib/gtestutils.c:2937 #3 0x7fec90bf72fb in g_assertion_message_expr at ../../../glib/gtestutils.c:2963 #4 0x7fec91288c36 in gtk_widget_get_frame_clock at ../../../../gtk/gtkwidget.c:5871 #5 0x7fec9129748a in gtk_widget_realize at ../../../../gtk/gtkwidget.c:5541 #6 0x7fec91297668 in gtk_widget_map at ../../../../gtk/gtkwidget.c:5045 ... https://sources.debian.org/src/gtk+3.0/3.24.24-4/gtk/gtkwidget.c/#L5871 Kind regards, Bernhard
Bug#992721: hplip: Scanning with Deskjet 3050A J611 crash
Hello Florence, there might be still something that could be done to retrieve some more information (if you have still the versions installed that show the issue). The easiest first thing might be to install the package systemd-coredump, if possible. Then open in another terminal 'journalctl -f'. And reproduce one of the "stack smashings". Then in the other terminal a "Stack trace" should appear - this should point out the library and maybe function where the issue is. Kind regards, Bernhard
Bug#992997: milter-greylist: segfault in libGeoIP
Hello Bjørn, hello Sudip,
I just tried to locate the line where the crash happens from
the dmesg output and got to this location [1].
Unfortunately the CVS tree seems not up to date or I was using the wrong one.
At least there was a change in geoip.c in line 166 [2] [3].
Kind regards,
Bernhard
[1] https://sources.debian.org/src/geoip/1.6.12-7/libGeoIP/GeoIP.c/#L2038
[2] https://sources.debian.org/src/milter-greylist/4.6.2-3/geoip.c/#L166
[3] https://sources.debian.org/src/milter-greylist/4.6.4-1/geoip.c/#L166
From submitter:
Aug 23 22:12:23 louie kernel: milter-greylist[192919]: segfault at 28 ip
7fbaf22fe8d9 sp 7fbaee77c670 error 4 in
libGeoIP.so.1.6.12[7fbaf22fc000+1b000]
Aug 23 22:12:23 louie kernel: Code: 90 e9 6b d8 ff ff 66 66 2e 0f 1f 84 00
00 00 00 00 48 85 f6 0f 84 8f 00 00 00 41 54 49 89 d4 53 48 89 fb 48 89 f7 48
83 ec 08 <0f> be 43 28 3c 0c 74 4f 3c 12 74 4b 48 8b 3d cc 26 03 00 48 8d 35
# https://wiki.debian.org/InterpretingKernelOutputAtProcessCrash
"error 4" == 0b0100
0: no page found
0: read access
1: user-mode access
echo -n "find /b ..., ..., 0x" && \
echo "90 e9 6b d8 ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 48 85 f6 0f 84 8f 00
00 00 41 54 49 89 d4 53 48 89 fb 48 89 f7 48 83 ec 08 <0f> be 43 28 3c 0c 74 4f
3c 12 74 4b 48 8b 3d cc 26 03 00 48 8d 35" \
| sed 's/[<>]//g' | sed 's/ /, 0x/g'
# Bullseye/stable amd64 qemu VM 2021-09-13
echo "set enable-bracketed-paste off" >> /etc/inputrc; bash
apt update
apt dist-upgrade
apt install mc git git-cvs devscripts rsync rsyncgdb milter-greylist
apt install milter-greylist-dbgsym libgeoip1-dbgsym
apt build-dep libgeoip1
mkdir /home/benutzer/source/libgeoip1/orig -p
cd/home/benutzer/source/libgeoip1/orig
apt source libgeoip1
cd
gdb -q
set width 0
set pagination off
directory /home/benutzer/source/libgeoip1/orig/geoip-1.6.12/libGeoIP
file /usr/sbin/milter-greylist
tb main
run
pipe info target | grep "text.*Geo"
find /b ..., ..., 0x90, 0xe9, 0x6b, 0xd8, 0xff, 0xff, 0x66, 0x66, 0x2e, 0x0f,
0x1f, 0x84, 0x00, 0x00, 0x00, 0x00, 0x00, 0x48, 0x85, 0xf6, 0x0f, 0x84, 0x8f,
0x00, 0x00, 0x00, 0x41, 0x54, 0x49, 0x89, 0xd4, 0x53, 0x48, 0x89, 0xfb, 0x48,
0x89, 0xf7, 0x48, 0x83, 0xec, 0x08, 0x0f, 0xbe, 0x43, 0x28, 0x3c, 0x0c, 0x74,
0x4f, 0x3c, 0x12, 0x74, 0x4b, 0x48, 0x8b, 0x3d, 0xcc, 0x26, 0x03, 0x00, 0x48,
0x8d, 0x35
b * (0x77f908af + 42)
benutzer@debian:~$ gdb -q
(gdb) set width 0
(gdb) set pagination off
(gdb) directory /home/benutzer/source/libgeoip1/orig/geoip-1.6.12/libGeoIP
Source directories searched:
/home/benutzer/source/libgeoip1/orig/geoip-1.6.12/libGeoIP:$cdir:$cwd
(gdb) file /usr/sbin/milter-greylist
Reading symbols from /usr/sbin/milter-greylist...
Reading symbols from
/usr/lib/debug/.build-id/26/9d1dfedbfac4bcaccb58f1c1312cfbcf2b27a9.debug...
(gdb) tb main
Temporary breakpoint 1 at 0x6cc0: file milter-greylist.c, line 1617.
(gdb) run
Starting program: /usr/sbin/milter-greylist
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Temporary breakpoint 1, main (argc=1, argv=0x7fffe608) at
milter-greylist.c:1617
1617milter-greylist.c: Datei oder Verzeichnis nicht gefunden.
(gdb) pipe info target | grep "text.*Geo"
0x77f8e5f0 - 0x77fa8cac is .text in
/lib/x86_64-linux-gnu/libGeoIP.so.1
(gdb) find /b 0x77f8e5f0, 0x77fa8cac, 0x90, 0xe9, 0x6b, 0xd8,
0xff, 0xff, 0x66, 0x66, 0x2e, 0x0f, 0x1f, 0x84, 0x00, 0x00, 0x00, 0x00, 0x00,
0x48, 0x85, 0xf6, 0x0f, 0x84, 0x8f, 0x00, 0x00, 0x00, 0x41, 0x54, 0x49, 0x89,
0xd4, 0x53, 0x48, 0x89, 0xfb, 0x48, 0x89, 0xf7, 0x48, 0x83, 0xec, 0x08, 0x0f,
0xbe, 0x43, 0x28, 0x3c, 0x0c, 0x74, 0x4f, 0x3c, 0x12, 0x74, 0x4b, 0x48, 0x8b,
0x3d, 0xcc, 0x26, 0x03, 0x00, 0x48, 0x8d, 0x35
0x77f908af
1 pattern found.
(gdb) b * (0x77f908af + 42)
Breakpoint 2 at 0x77f908d9: file GeoIP.c, line 2038.
(gdb) info b
Num Type Disp Enb AddressWhat
2 breakpoint keep y 0x77f908d9 in GeoIP_id_by_addr_v6_gl at
GeoIP.c:2038
(gdb) display/i 0x77f908af + 42
1: x/i 0x77f908af + 42
0x77f908d9 : movsbl 0x28(%rbx),%eax
(gdb) list GeoIP.c:2036
2031
2032int GeoIP_id_by_addr_v6_gl(GeoIP *gi, const char *addr, GeoIPLookup
*gl) {
2033geoipv6_t ipnum;
2034int ret;
2035if (addr == NULL) {
2036return 0;
2037}
2038if (gi->databaseType != GEOIP_COUNTRY_EDITION_V6 &&
2039gi->databaseType != GEOIP_LARGE_COUNTRY_EDITION_V6) {
2040printf("Invalid database type %s, expected %s\n",
(gdb)
https://sources.debian.org/src/geoip/1.6.12-7/libGeoIP/GeoIP.c/#L2038
# http://hcpnet.free.fr/milter-greylist/
mkdir /home/benutzer/source/milter-graylist/cvs -p
cd/home/benutzer/source/milter-graylist/cvs
export CVS_RSH=ssh; cvs -danon...@anoncvs.fr.netbsd.org:/milter-greylist co -P
milter-greylist
cvs log | head -n100
--
Bug#993018: valgrind: vgcore files unusable in gdb
Dear Maintainer,
and some more digging with the help of rr-debugger led me to the
functions svr4_relocate_main_executable/exec_set_section_address
in gdb.
The latter gets not called in the valgrind core case,
because the vgcore file lacks an ".auxv" section,
which does exist inside a regular core:
$ objdump -x core
...
Sections:
Idx Name Size VMA LMA File off
Algn
...
5 .auxv 0140 07b8 2**3
CONTENTS
So I came up with attached patch for valgrind
that adds the ".auxv" section to the vgcore
and with such a vgcore gdb is able to show
the proper source line and shared library information.
(This patch still contains some informational debug printfs.)
Kind regards,
Bernhard
gdb backtrace, where the ".auxv" sections is searched:
868 section = bfd_get_section_by_name (core_bfd, ".auxv");
(rr) bt
#0 core_target::xfer_partial (this=0x563cec758120, object=TARGET_OBJECT_AUXV,
annex=0x0, readbuf=0x563cec79d540 "\240Sa[J\177", writebuf=0x0, offset=0,
len=4096, xfered_len=0x7fff66a72fc8) at /build/gdb-Nav6Es/gdb-10.1/gdb/corelow.c:868
#1 0x563cebeee1be in target_xfer_partial (ops=0x563cec758120,
object=TARGET_OBJECT_AUXV, annex=0x0, readbuf=0x563cec79d540 "\240Sa[J\177",
writebuf=0x0, offset=0, len=, xfered_len=0x7fff66a72fc8) at
/build/gdb-Nav6Es/gdb-10.1/gdb/target.c:1160
#2 0x563cebef0863 in target_read_partial (xfered_len=0x7fff66a72fc8,
len=4096, offset=0, buf=, annex=0x0, object=TARGET_OBJECT_AUXV,
ops=0x563cec758120) at /build/gdb-Nav6Es/gdb-10.1/gdb/target.c:1387
#3 target_read_alloc_1 (ops=ops@entry=0x563cec758120,
object=object@entry=TARGET_OBJECT_AUXV, annex=annex@entry=0x0) at
/build/gdb-Nav6Es/gdb-10.1/gdb/target.c:1722
#4 0x563cebeeff6a in target_read_alloc (ops=ops@entry=0x563cec758120,
object=object@entry=TARGET_OBJECT_AUXV, annex=annex@entry=0x0) at
/build/gdb-Nav6Es/gdb-10.1/gdb/target.c:1751
#5 0x563cebc30630 in get_auxv_inferior_data (ops=0x563cec758120) at
/build/gdb-Nav6Es/gdb-10.1/gdb/auxv.c:368
#6 0x563cebc30c69 in target_auxv_search (ops=,
match=match@entry=9, valp=valp@entry=0x7fff66a73158) at
/build/gdb-Nav6Es/gdb-10.1/gdb/auxv.c:382
#7 0x563cebe97881 in svr4_exec_displacement (displacementp=) at /build/gdb-Nav6Es/gdb-10.1/gdb/solib-svr4.c:2577
#8 svr4_relocate_main_executable () at
/build/gdb-Nav6Es/gdb-10.1/gdb/solib-svr4.c:2960
...
Description: Add auxiliary vector to vgcore files
This enables gdb to get relocation and load debug information.
Author: Bernhard Übelacker
Bug-Debian: https://bugs.debian.org/993018
Forwarded: no
Last-Update: 2021-09-13
--- valgrind-3.16.1.orig/coregrind/m_coredump/coredump-elf.c
+++ valgrind-3.16.1/coregrind/m_coredump/coredump-elf.c
@@ -730,6 +730,19 @@ void make_elf_coredump(ThreadId tid, con
/* Second, work out their layout */
phdrs = VG_(malloc)("coredump-elf.mec.1", sizeof(*phdrs) * num_phdrs);
+ /* Auxiliary vector, from coregrind/m_gdbserver/server.c */
+ UWord *client_auxv = VG_(client_auxv);
+ unsigned int client_auxv_len = 0;
+ while (*client_auxv != 0) {
+ client_auxv++;
+ client_auxv++;
+ client_auxv_len += 2 * sizeof(UWord);
+ }
+ client_auxv_len += 2 * sizeof(UWord);
+ client_auxv = VG_(client_auxv);
+ VG_(umsg)("Adding NT_AUXV. %p/%u\n", client_auxv, client_auxv_len);
+ add_note(, "CORE", NT_AUXV, client_auxv, client_auxv_len);
+
/* Add details for all threads except the one that faulted */
for(i = 1; i < VG_N_THREADS; i++) {
--- valgrind-3.16.1.orig/coregrind/m_initimg/initimg-linux.c
+++ valgrind-3.16.1/coregrind/m_initimg/initimg-linux.c
@@ -674,6 +674,7 @@ Addr setup_client_stack( void* init_sp,
break;
case AT_ENTRY:
+VG_(printf)("AT_ENTRY=%lx auxv=%p info=%p client_auxv=%p\n", info->entry, auxv, info, *client_auxv);
auxv->u.a_val = info->entry;
break;
Bug#993018: valgrind: vgcore files unusable in gdb
Looking a little further, it looks like gdb does "just" not know where the executable was mapped in memory, therefore it gets mapped to 0x0 instead of 0x108000 in my example below. Debugging such a "pie vgcore" file would be possible if the debug symbols are loaded manually to the "right" address. Kind regards, Bernhard $ valgrind --vgdb=yes --vgdb-error=0 ./test $ gdb -q ./test (gdb) target remote | vgdb (gdb) cont (gdb) info target ... Local exec file: `/home/benutzer/test', file type elf64-x86-64. Entry point: 0x109040 0x001082a8 - 0x001082c4 is .interp ... 0x00109040 - 0x001091a1 is .text ... 0x04874320 - 0x049bd6b9 is .text in /lib/x86_64-linux-gnu/libc.so.6 ... (gdb) cont (gdb) cont $ gdb ./test vgcore* (gdb) bt #0 0x0010912e in ?? () #1 0x00109140 in ?? () #2 0x04875d0a in ?? () ... (gdb) info target Symbols from "/home/benutzer/test". Local core dump file: `/home/benutzer/vgcore.7308', file type elf64-x86-64. 0x00108000 - 0x00109000 is load1 ... Local exec file: `/home/benutzer/test', file type elf64-x86-64. Entry point: 0x1040 ... 0x1040 - 0x11a1 is .text ... (gdb) add-symbol-file ./test -s .text 0x00109040 add symbol table from file "./test" at .text_addr = 0x109040 (y or n) y Reading symbols from ./test... (gdb) add-symbol-file /lib/x86_64-linux-gnu/libc.so.6 -s .text 0x04874320 add symbol table from file "/lib/x86_64-linux-gnu/libc.so.6" at .text_addr = 0x4874320 (y or n) y Reading symbols from /lib/x86_64-linux-gnu/libc.so.6... Reading symbols from /usr/lib/debug/.build-id/b7/2adf59ac0a673d1eeb261e662364507cfc8615.debug... (gdb) bt #0 main () at test.c:2 #1 0x04875d0a in __libc_start_main (main=0x109125 , argc=1, argv=0x1fff000538, init=, fini=, rtld_fini=, stack_end=0x1fff000528) at ../csu/libc-start.c:308 #2 0x0010906a in _start () (gdb) up ... (gdb) down #0 main () at test.c:2 2 *(int*)0 = 0;
Bug#993018: valgrind: vgcore files unusable in gdb
Dear Maintainer, I tried to find out when this started to happen. And I found this issue in releases 11-bullseye, 10-buster and 9-stretch. In 8-jessie such a vgcore shows in gdb the correct line information. Further looking brought me to stretch/testing as of 29.10.2016, where the issue starts to be visible. At that date the gcc-6 version changed from 6.2.0-6 to 6.2.0-9. The changelog [1] entries between these versions mention a "--enable-default-pie". So I tested to build the executable with the option "-no-pie" in buster/stable which made the vgcore work. Therefore this PIE option might be related. Kind regards, Bernhard [1] https://metadata.ftp-master.debian.org/changelogs//main/g/gcc-6/gcc-6_6.3.0-18+deb9u1_changelog
Bug#990464: Kdump is unable to use NVME
Hello Kody, I had in the past also a working crash kernel setup. But that started to fail with and after kernel 5.5. Unfortunately I did not yet come to report this to debian. If that is also the case for you, a workaround could be to install the old 5.4.19 bpo kernel [1]. And modify /etc/default/kdump-tools like this: -KDUMP_KERNEL=/var/lib/kdump/vmlinuz -KDUMP_INITRD=/var/lib/kdump/initrd.img +KDUMP_KERNEL=/boot/vmlinuz-5.4.0-4-amd64 +KDUMP_INITRD=/var/lib/kdump/initrd.img-5.4.0-4-amd64 This is a workaround for me with a "Asus-PRIME-B350M-A", but for a plain SATA SSD, and running testing. I just looked in upstream tracker and found this bug [2], but that might show another issue. Kind regards, Bernhard [1] https://snapshot.debian.org/package/linux/5.4.19-1%7Ebpo10%2B1/ [2] https://bugzilla.kernel.org/show_bug.cgi?id=209351
Bug#990035: less dies with double free
Dear Maintainer, I tried to have a look and could reproduce the issue. It seems this got already fixed upstream in [1]. Also a related upstream issue exists [2]. A package built with this patch applied does not show the fault. Kind regards, Bernhard [1] https://github.com/gwsw/less/commit/520e5c6ea362 [2] https://github.com/gwsw/less/issues/78 # Bullseye/testing amd64 qemu VM 2021-07-09 echo "set enable-bracketed-paste off" >> /etc/inputrc; bash apt update apt dist-upgrade apt install systemd-coredump mc git gdb valgrind rr less-dbgsym fakeroot apt build-dep less mkdir /home/benutzer/source/less/orig -p cd/home/benutzer/source/less/orig apt source less cd dmesg > file cat file |less s /tmp D s /tmp double free or corruption (fasttop) Abgebrochen (Speicherabzug geschrieben) # coredumpctl list TIMEPID UID GID SIG COREFILE EXE Fri 2021-07-09 16:24:39 CEST984 0 0 6 present /usr/bin/less # journalctl -e # coredumpctl gdb 984 PID: 984 (less) UID: 0 (root) GID: 0 (root) Signal: 6 (ABRT) Timestamp: Fri 2021-07-09 16:24:39 CEST (2min 12s ago) Command Line: less Executable: /usr/bin/less Control Group: /user.slice/user-1000.slice/session-1.scope Unit: session-1.scope Slice: user-1000.slice Session: 1 Owner UID: 1000 (benutzer) Boot ID: a8a996b571bb4da1b0927f2faa539137 Machine ID: 33f18f39d2a9438eb75b0ed52848afcd Hostname: debian Storage: /var/lib/systemd/coredump/core.less.0.a8a996b571bb4da1b0927f2faa539137.984.162584067900.zst Message: Process 984 (less) of user 0 dumped core. Stack trace of thread 984: #0 0x7ff6b9082ce1 raise (libc.so.6 + 0x3bce1) #1 0x7ff6b906c537 abort (libc.so.6 + 0x25537) #2 0x7ff6b90c5768 n/a (libc.so.6 + 0x7e768) #3 0x7ff6b90cca5a n/a (libc.so.6 + 0x85a5a) #4 0x7ff6b90cdd55 n/a (libc.so.6 + 0x86d55) #5 0x557a43e773ab n/a (less + 0x143ab) #6 0x557a43e78bda n/a (less + 0x15bda) #7 0x557a43e6d97b n/a (less + 0xa97b) #8 0x557a43e6ef9f n/a (less + 0xbf9f) #9 0x557a43e677fe n/a (less + 0x47fe) #10 0x7ff6b906dd0a __libc_start_main (libc.so.6 + 0x26d0a) #11 0x557a43e6788a n/a (less + 0x488a) GNU gdb (Debian 10.1-1.7) 10.1.90.20210103-git ... Core was generated by `less'. Program terminated with signal SIGABRT, Aborted. #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 50 ../sysdeps/unix/sysv/linux/raise.c: Datei oder Verzeichnis nicht gefunden. (gdb) set width 0 (gdb) bt #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 #1 0x7ff6b906c537 in __GI_abort () at abort.c:79 #2 0x7ff6b90c5768 in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7ff6b91d3e2d "%s\n") at ../sysdeps/posix/libc_fatal.c:155 #3 0x7ff6b90cca5a in malloc_printerr (str=str@entry=0x7ff6b91d61c8 "double free or corruption (fasttop)") at malloc.c:5347 #4 0x7ff6b90cdd55 in _int_free (av=0x7ff6b9205b80 , p=0x557a45a52b10, have_lock=0) at malloc.c:4266 #5 0x557a43e773ab in ?? () #6 0x557a43e78bda in ?? () #7 0x557a43e6d97b in ?? () #8 0x557a43e6ef9f in ?? () #9 0x557a43e677fe in ?? () #10 0x7ff6b906dd0a in __libc_start_main (main=0x557a43e674e0, argc=1, argv=0x7ffc862ed9c8, init=, fini=, rtld_fini=, stack_end=0x7ffc862ed9b8) at ../csu/libc-start.c:308 #11 0x557a43e6788a in ?? () export DEBUGINFOD_URLS="https://debuginfod.debian.net; Core was generated by `less'. Program terminated with signal SIGABRT, Aborted. #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 Download failed: Das Argument ist ungültig. Continuing without source file ./signal/../sysdeps/unix/sysv/linux/raise.c. 50 ../sysdeps/unix/sysv/linux/raise.c: Datei oder Verzeichnis nicht gefunden. (gdb) bt #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 #1 0x7ff6b906c537 in __GI_abort () at abort.c:79 #2 0x7ff6b90c5768 in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7ff6b91d3e2d "%s\n") at ../sysdeps/posix/libc_fatal.c:155 #3 0x7ff6b90cca5a in malloc_printerr (str=str@entry=0x7ff6b91d61c8 "double free or corruption (fasttop)") at malloc.c:5347 #4 0x7ff6b90cdd55 in _int_free (av=0x7ff6b9205b80 , p=0x557a45a52b10, have_lock=0) at malloc.c:4266 #5 0x557a43e773ab in opt_o (type=, s=0x557a43e8eee0 "/tmp") at optfunc.c:118 #6 0x557a43e78bda in toggle_option (o=0x557a43e8db80 , lower=, s=, s@entry=0x557a43e8eee0 "/tmp", how_toggle=) at option.c:446 #7 0x557a43e6d97b in exec_mca () at command.c:262 #8 0x557a43e6ef9f in mca_char (c=10) at command.c:635 #9 commands ()
Bug#990309: gdbserver: i386 (-m32) program on amd64 crashes while being debbugged
Hello Simon, I guess #982049 is about the same issue. At least function name and address offset is equal. Kind regards, Bernhard
Bug#990167: gdb: dbgsym package contains no debug information libbfd library
Package: gdb
Version: 10.1-1.7
Severity: wishlist
X-Debbugs-Cc: bernha...@mailbox.org
Dear Maintainer,
while investigating an issue in the test suite of rr-debugger,
I found that the libbfd part of gdb is not built with debug information,
therefore the dbgsym package also lacks this information.
While rebuilding gdb is doable, maybe it would be nice to have this
debug information in the package available.
Below modification added globally the '-g' flag and built me
a package that contained the debug information for libbfd.
But I am certain there is a more targetted place to add this.
Kind regards,
Bernhard
-- System Information:
Debian Release: 11.0
APT prefers testing-security
APT policy: (500, 'testing-security'), (500, 'testing-debug'), (500,
'proposed-updates-debug'), (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-7-amd64 (SMP w/16 CPU threads)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE
not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages gdb depends on:
ii libbabeltrace1 1.5.8-1+b3
ii libc6 2.31-12
ii libdebuginfod1 0.183-1
ii libexpat1 2.2.10-2
ii libgcc-s1 10.2.1-6
ii libipt2 2.0.3-1
ii liblzma55.2.5-2
ii libmpfr64.1.0-3
ii libncursesw66.2+20201114-2
ii libpython3.93.9.2-1
ii libreadline88.1-1
ii libsource-highlight4v5 3.1.9-3+b1
ii libstdc++6 10.2.1-6
ii libtinfo6 6.2+20201114-2
ii libxxhash0 0.8.0-2
ii zlib1g 1:1.2.11.dfsg-2
Versions of packages gdb recommends:
ii libc6-dbg [libc-dbg] 2.31-12
Versions of packages gdb suggests:
pn gdb-doc
pn gdbserver
-- no debconf information
--- orig/gdb-10.1/debian/rules 2021-01-03 11:54:01.0 +0100
+++ try2/gdb-10.1/debian/rules 2021-06-20 23:09:52.391144630 +0200
@@ -8,6 +8,11 @@ include /usr/share/dpkg/architecture.mk
SOURCE_DATE_EPOCH ?= $(shell dpkg-parsechangelog -SDate | date -f- +%s)
deb_version := $(shell dpkg-parsechangelog | awk '/^Version:/ {print
$$2}')
+# Add -g globally (especially libbfd seems to get compiled without -g)
+CFLAGS += -g
+CPPFLAGS += -g
+LDFLAGS += -g
+
# The top-level configure script fails to pass these down properly ...
export CPPFLAGS
export LDFLAGS
Bug#989004: imagemagick-6.q16: Display terminates after ~ 3 seconds
Hello Helge, I just tried to collect some information for the Maintainer. Might this be the expected behaviour? This image seems to have a stored Delay and Duration value: $ identify -verbose 2006_08262.gif Image: Filename: 2006_08262.gif ... Delay: 20x100 Duration: 20 ... These 20 get get read here: (rr) bt #0 0x7fcdf0974404 in ReadGIFImage (image_info=, exception=) at ../../coders/gif.c:1098 #1 0x7fcdf0717c20 in ReadImage (image_info=image_info@entry=0x558dfa3c9680, exception=exception@entry=0x558dfa3c4c10) at ../../magick/constitute.c:563 #2 0x7fcdf05ce223 in DisplayImageCommand (image_info=0x558dfa3c9680, image_info@entry=0x558dfa3c54e0, argc=, argc@entry=2, argv=, argv@entry=0x7fff189926b8, wand_unused_metadata=wand_unused_metadata@entry=0x0, exception=exception@entry=0x558dfa3c4c10) at ../../wand/display.c:492 #3 0x7fcdf0616f80 in MagickCommandGenesis (image_info=image_info@entry=0x558dfa3c54e0, command=0x7fcdf05cd5b0 , argc=argc@entry=2, argv=argv@entry=0x7fff189926b8, metadata=metadata@entry=0x0, exception=exception@entry=0x558dfa3c4c10) at ../../wand/mogrify.c:173 #4 0x558df995d0fa in DisplayMain (argv=0x7fff189926b8, argc=2) at ../../utilities/display.c:89 #5 main (argc=2, argv=0x7fff189926b8) at ../../utilities/display.c:100 And get interpreted here, resulting in a delay of 0: 14934 delay=display_image->delay/MagickMax(display_image->ticks_per_second,1L); (rr) bt #0 XDisplayImage (display=display@entry=0x558dfa3c17f0, resource_info=resource_info@entry=0x7fff18991270, argv=0x558dfa3c15b0, argc=2, image=image@entry=0x7fff18990a50, state=state@entry=0x7fff18990a48) at ../../magick/display.c:14935 #1 0x7fcdf05cfaa7 in DisplayImageCommand (image_info=0x558dfa3c9680, image_info@entry=0x558dfa3c54e0, argc=, argc@entry=2, argv=, argv@entry=0x7fff189926b8, wand_unused_metadata=wand_unused_metadata@entry=0x0, exception=exception@entry=0x558dfa3c4c10) at ../../wand/display.c:538 #2 0x7fcdf0616f80 in MagickCommandGenesis (image_info=image_info@entry=0x558dfa3c54e0, command=0x7fcdf05cd5b0 , argc=argc@entry=2, argv=argv@entry=0x7fff189926b8, metadata=metadata@entry=0x0, exception=exception@entry=0x558dfa3c4c10) at ../../wand/mogrify.c:173 #3 0x558df995d0fa in DisplayMain (argv=0x7fff189926b8, argc=2) at ../../utilities/display.c:89 #4 main (argc=2, argv=0x7fff189926b8) at ../../utilities/display.c:100 (rr) print display_image->ticks_per_second $11 = 100 (rr) print display_image->delay $12 = 20 (rr) next 14935 timer=GetMagickTime()+(delay == 0 ? 1 : delay)+1; (rr) print delay $13 = 0 https://sources.debian.org/src/imagemagick/8:6.9.11.60+dfsg-1.3/magick/display.c/#L14934 One could modify the delay to e.g. 1000 centiseconds == 10 seconds: time display-im6.q16 -delay 1000 2006_08262.gif I am not sure how this "Delay" and "Duration" is expected to be interpreted (or ignored?) for a GIF with just one picture. Kind regards, Bernhard
Bug#989208: atril: Segfault
Hello Jerome, could you please add a few more details for the Maintainer? What shows the "bt full" command in gdb, when the crash is reached? Is the package dconf-service installed and when you login a process dconf-service running? Kind regards, Bernhard
Bug#989010: linux-image-5.10.0-7-amd64: No display (post, grub, boot messages and desktop) after the upgrade to 5.10.38
Hello Jim, I am not involved in packaging, but came to this report by chance. The attached file contains all the changes you devs have made in the kernel configs from 5.10.28 (-6 package) to 5.10.38/.40 (-7 package). It was made with meld. ~10 kernel parameters have changed and led to this mess, so I assume it would be trivial for you to find the faulty one. These parameters are not all that changed - there are around 1400 patches added upstream to the kernel between v5.10.28 and v5.10.38. https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/log/?h=v5.10.38 Kind regards, Bernhard
Bug#989220: solvespace: crashes when starting on Debian stable.
Hello Juan, the last lines of your backtrace end in nouveau_dri.so. Therefore this might not be a fault in solvespace. Maybe you could install the package libgl1-mesa-dri-dbgsym where the file nouveau_dri.so originates from, and provide another backtrace from such a crash. I would expect that the currently uninformative lines in nouveau_dri.so would look similar to below. With the following environment set, before running solvespace in gdb, you might get a backtrace more related to the real memory operation causing the error. MALLOC_CHECK_=2 gdb --args solvespace Another source of information might be to run solvespace within valgrind: valgrind solvespace But I guess this issue is likeley to be caused by the graphics driver, maybe limited to the NV50 hardware class, which your GPU seems to be. This makes it hard to impossible to reproduce without having such graphics hardware. Kind regards, Bernhard ... #6 0xb6c70c34 in calloc () from libc.so.6 #7 0xb312b867 in nv50_rasterizer_state_create at ../src/gallium/drivers/nouveau/nv50/nv50_state.c:230 from nouveau_dri.so #8 0xb2ec0ea9 in cso_set_rasterizer at ../src/gallium/auxiliary/cso_cache/cso_context.c:604 from nouveau_dri.so #9 0xb3445465 in st_update_rasterizer at ../src/mesa/state_tracker/st_atom_rasterizer.c:317 from nouveau_dri.so #10 0xb3442e0f in st_validate_state at ../src/util/bitscan.h:103 from nouveau_dri.so #11 0xb339fea7 in prepare_draw at ../src/mesa/state_tracker/st_draw.c:123 from nouveau_dri.so #12 0xb329843e in vbo_exec_vtx_flush at ../src/mesa/vbo/vbo_exec_draw.c:393 from nouveau_dri.so #13 0xb3297e57 in vbo_exec_FlushVertices_internal at ../src/mesa/vbo/vbo_exec_api.c:1255 from nouveau_dri.so #14 0xb334477f in line_width at ../src/mesa/main/lines.c:70 from nouveau_dri.so #15 0x004df59f in SolveSpace::ssglLineWidth (width=) at ./src/glhelper.cpp:97 ...
Bug#988924: nemo: Nemo crashes if select "Create Folder" in Favorites
Dear Maintainer, I could reproduce the issue, but mostly just on the first run after a reboot of my test VM. When the issue appears the context menu opens for the favorites, but the entry to create a new folder is wrongly enabled. Clicking in that state leads to the error message: Error while copying to "Favorites". The destination is read-only. Cancel Hitting the Cancel button leads to this message at the terminal: (nemo:1242): GLib-CRITICAL **: 13:58:57.717: g_error_free: assertion 'error != NULL' failed ** ERROR:../libnemo-private/nemo-file.c:699:nemo_file_get_internal: assertion failed: (location != NULL) Bail out! ERROR:../libnemo-private/nemo-file.c:699:nemo_file_get_internal: assertion failed: (location != NULL) Aborted I was able to record one run with rr. There I was able to follow the calls to gtk_action_set_sensitive for the action NEMO_ACTION_NEW_FOLDER, but unfortunately I saw just calls to disable it short before. Therefore its still unclear why the context menu shows the entries as enabled in the first place. Kind regards, Bernhard (rr) bt #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 #1 0x7f7ea92fe537 in __GI_abort () at abort.c:79 #2 0x7f7ea99cbdcc in g_assertion_message (domain=, file=0x5635be1e5d90 "../libnemo-private/nemo-file.c", line=, func=, message=) at ../../../glib/gtestutils.c:2937 #3 0x7f7ea9a292fb in g_assertion_message_expr (domain=domain@entry=0x0, file=file@entry=0x5635be1e5d90 "../libnemo-private/nemo-file.c", line=line@entry=699, func=func@entry=0x5635be1e7540 <__func__.103> "nemo_file_get_internal", expr=expr@entry=0x5635be1dab47 "location != NULL") at ../../../glib/gtestutils.c:2963 #4 0x5635be176ce1 in nemo_file_get_internal (location=, create=create@entry=1) at ../libnemo-private/nemo-file.c:699 #5 0x5635be17770a in nemo_file_get (location=) at ../libnemo-private/nemo-file.c:751 #6 0x5635be11e26f in new_folder_done (new_folder=, success=, data=0x5635bee1c7e0) at ../src/nemo-tree-sidebar.c:913 #7 0x5635be1630e7 in create_job_done (user_data=0x5635beb13cd0) at ../libnemo-private/nemo-file-operations.c:6290 #8 0x7f7ea9bb8e4f in mainloop_proxy_func (data=0x7f7e8802b070) at ../../../gio/gioscheduler.c:203 #9 0x7f7ea9a00d6f in g_main_dispatch (context=0x5635be862db0) at ../../../glib/gmain.c:3325 #10 g_main_context_dispatch (context=0x5635be862db0) at ../../../glib/gmain.c:4043 #11 0x7f7ea9a01118 in g_main_context_iterate (context=context@entry=0x5635be862db0, block=block@entry=1, dispatch=dispatch@entry=1, self=) at ../../../glib/gmain.c:4119 #12 0x7f7ea9a011cf in g_main_context_iteration (context=context@entry=0x5635be862db0, may_block=may_block@entry=1) at ../../../glib/gmain.c:4184 #13 0x7f7ea9c19545 in g_application_run (application=0x5635be860130, argc=1834504324, argc@entry=1, argv=argv@entry=0x7ffc6d5851f8) at ../../../gio/gapplication.c:2559 #14 0x5635be0bd192 in main (argc=1, argv=0x7ffc6d5851f8) at ../src/nemo-main.c:104 # single-use Bullseye/testing amd64 qemu VM 2021-06-05 echo "set enable-bracketed-paste off" >> /etc/inputrc; bash apt update apt dist-upgrade apt install systemd-coredump gdb mc cinnamon \ nemo-dbgsym libglib2.0-0-dbgsym libgtk-3-0-dbgsym apt build-dep nemo reboot mkdir /home/benutzer/source/nemo/orig -p cd/home/benutzer/source/nemo/orig apt source nemo cd mkdir /home/benutzer/source/libgtk-3-0/orig -p cd/home/benutzer/source/libgtk-3-0/orig apt source libgtk-3-0 cd Fehler beim Kopieren nach >>Favoriten<<. Das Ziel ist schreibgeschützt. Abbrechen Error while copying to "Favorites". The destination is read-only. Cancel # coredumpctl list TIMEPID UID GID SIG COREFILE EXE Sat 2021-06-05 13:10:11 CEST 1099 1000 1000 6 present /usr/bin/nemo # coredumpctl gdb 1099 PID: 1099 (nemo) UID: 1000 (benutzer) GID: 1000 (benutzer) Signal: 6 (ABRT) Timestamp: Sat 2021-06-05 13:10:11 CEST (5min ago) Command Line: nemo /home/benutzer Executable: /usr/bin/nemo Control Group: /user.slice/user-1000.slice/session-2.scope Unit: session-2.scope Slice: user-1000.slice Session: 2 Owner UID: 1000 (benutzer) Boot ID: fa231400d36b4b479aa5f6395cdd6522 Machine ID: 33f18f39d2a9438eb75b0ed52848afcd Hostname: debian Storage: /var/lib/systemd/coredump/core.nemo.1000.fa231400d36b4b479aa5f6395cdd6522.1099.162289141100.zst Message: Process 1099 (nemo) of user 1000 dumped core. Stack trace of thread 1099: #0 0x7f839fb7ece1 raise (libc.so.6 + 0x3bce1) #1 0x7f839fb68537 abort (libc.so.6 + 0x25537) #2 0x7f83a0233dcc n/a (libglib-2.0.so.0 + 0x1cdcc) #3 0x7f83a02912fb g_assertion_message_expr (libglib-2.0.so.0 + 0x7a2fb) #4
Bug#988351: gimp crashes when copyq is running and i copy something from gimp to clipboard
Am 01.06.21 um 14:31 schrieb Bernhard Übelacker: Dear Maintainer, there is an upstream bug that shows a similar backtrace and is also about clipboard interaction. Maybe more likely to happen with larger selections. https://gitlab.gnome.org/GNOME/gimp/-/issues/2357 And copyq upstream has also a similar bug report here: https://github.com/hluk/CopyQ/issues/1070 Kind regards, Bernhard
Bug#988351: gimp crashes when copyq is running and i copy something from gimp to clipboard
Dear Maintainer, there is an upstream bug that shows a similar backtrace and is also about clipboard interaction. Maybe more likely to happen with larger selections. https://gitlab.gnome.org/GNOME/gimp/-/issues/2357 Kind regards, Bernhard
Bug#987566: ghostscript: PDF Interpreter error on armel
Am 31.05.21 um 21:49 schrieb Adrian Bunk: #975977 comes into my mind as a similar bug in a different package. Unfortunately in this bug it was possible to do a side by side debugging, that way the exact instruction could be identified, and the relation to the alignment was found. But with ghostscript being an interpreter this seems far more complicated in this case. Is there any automatic way to detect such alignment issues with armel? I hope it is ok to add debian-arm list in CC. Kind regards, Bernhard
Bug#988351: gimp crashes when copyq is running and i copy something from gimp to clipboard
Hello Mr. T, I tried to reproduce the issue inside a small VM. I hit an issue when copying something, mostly larger areas, in gimp. If I started gimp from a terminal I got this message [1]. Maybe you could confirm when you start gimp from a terminal you see the same message, when the error happens. Following the advice from the message I get this backtrace [2]. Kind regards, Bernhard [1] The program 'gimp-2.10' received an X Window System error. This probably reflects a bug in the program. The error was 'BadWindow (invalid Window parameter)'. (Details: serial 193066 error_code 3 request_code 18 minor_code 0) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the --sync command line option to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) [2] (gdb) bt #0 gdk_x_error (display=0x55fc8c60, error=0x7fffdee0) at ../../../../../gdk/x11/gdkmain-x11.c:458 #1 0x76b7f754 in _XError (dpy=dpy@entry=0x55fc8c60, rep=rep@entry=0x583efec0) at ../../src/XlibInt.c:1503 #2 0x76b7c217 in handle_error (dpy=0x55fc8c60, err=0x583efec0, in_XReply=) at ../../src/xcb_io.c:207 #3 0x76b7c2b5 in handle_response (dpy=dpy@entry=0x55fc8c60, response=0x583efec0, in_XReply=in_XReply@entry=1) at ../../src/xcb_io.c:394 #4 0x76b7d51d in _XReply (dpy=dpy@entry=0x55fc8c60, rep=rep@entry=0x7fffe0a0, extra=extra@entry=0, discard=discard@entry=1) at ../../src/xcb_io.c:718 #5 0x76b78d1b in XSync (dpy=0x55fc8c60, discard=discard@entry=0) at ../../src/Sync.c:44 #6 0x76b78dbb in _XSyncFunction (dpy=) at ../../src/Synchro.c:35 #7 0x76b595a3 in XChangeProperty (dpy=0x55fc8c60, w=w@entry=37748743, property=property@entry=308, type=type@entry=523, format=format@entry=8, mode=mode@entry=0, data=0x5b301170 "\211PNG\r\n\032\n", nelements=262144) at ../../src/ChProp.c:92 #8 0x77a6f560 in IA__gdk_property_change (window=0x5930b6c0, property=, type=0x75, format=8, mode=mode@entry=GDK_PROP_MODE_REPLACE, data=0x5b301170 "\211PNG\r\n\032\n", nelements=262144) at ../../../../../gdk/x11/gdkproperty-x11.c:732 #9 0x77c63121 in _gtk_selection_incr_event (window=, event=0x595baac0) at ../../../../gtk/gtkselection.c:2593 #10 0x77a65afc in gdk_event_dispatch (source=, callback=, user_data=) at ../../../../../gdk/x11/gdkevents-x11.c:2425 #11 0x77006e6b in g_main_dispatch (context=0x55ff5f10) at ../../../glib/gmain.c:3325 #12 g_main_context_dispatch (context=0x55ff5f10) at ../../../glib/gmain.c:4043 #13 0x77007118 in g_main_context_iterate (context=0x55ff5f10, block=block@entry=1, dispatch=dispatch@entry=1, self=) at ../../../glib/gmain.c:4119 #14 0x7700740b in g_main_loop_run (loop=loop@entry=0x585e0990) at ../../../glib/gmain.c:4317 #15 0x5563356e in app_run (full_prog_name=, filenames=, alternate_system_gimprc=alternate_system_gimprc@entry=0x0, alternate_gimprc=alternate_gimprc@entry=0x0, session_name=, batch_interpreter=0x0, batch_commands=0x0, as_new=0, no_interface=0, no_data=0, no_fonts=0, no_splash=0, be_verbose=0, use_shm=1, use_cpu_accel=1, console_messages=0, use_debug_handler=0, show_playground=0, show_debug_menu=0, stack_trace_mode=GIMP_STACK_TRACE_NEVER, pdb_compat_mode=GIMP_PDB_COMPAT_ON, backtrace_file=0x55ee7820 "/home/benutzer/.config/GIMP/2.10/CrashLog/GIMP-crash-1622193301.txt") at app.c:439 #16 0x55632e3e in main (argc=, argv=) at main.c:636
Bug#988432: gnome-shell: segfault in libgobject-2.0.so.0.6600.8
Dear Maintainer, this backtrace looks quite similar to the reports from following link from fedora, which started to appear end of march. Unfortunately I could not find a related entry in their bug tracker. https://retrace.fedoraproject.org/faf/problems/41770/ Kind regards, Bernhard
Bug#986176: openuniverse runs with crippled GUI, then crashes.
Hello Ray, Warning, a coredump from this system would be immense. Or, well anyway pretty darn large. systemd-coredump should limit the core to 2G. And as a first target, the journal output might have a backtrace from which one could start looking. Maybe running openuniverse with a memory limit produces the same error in dmesg? systemd-run --user --scope -p MemoryMax=2G openuniverse It would also be possible to tell the kernel to just use a certain amount of RAM by adding e.g. "mem=2G" to the kernel parameters. But this would require a reboot of the system. Testing in a VM with a more reasonable 6GB apparently does not provoke the crash. I fear the issue might also be specific to the graphics library because the crash happens in nouveau_dri.so. Therefore a VM might not show this issue. ... and openuniverse seems to expand to fill available space. That would be a memory leak I guess. Then the backtrace would be really not that interesting. ... but checking screenshots of it online I see many UI elements that simply are not present when I start it. I guess the gui needs a libglui, which is not "yet" packaged for debian (see #801858). If the issue might be related to the usage of multiple threads, the risk that the issue gets triggered might be lowered by running openuniverse just on a single CPU core: taskset 0x0001 openuniverse ## But while writing this email, I got my hands on a nouveau capable laptop. There I found openuniverse also crashing if I leave it some time alone, at the very exact instruction [1]. I could not see a excessive memory usage - htop shows 0.7% usage of 7.66G. So I can't currently see a connection between the available RAM size and this issue. I tried to record with rr, but this forces the driver to software mode, therefore the issue then does not show up. Also running with valgrind does not crash nor show something obvious. Kind regards, Bernhard [1] (gdb) bt #0 0x7fc3fc635d63 in create_cache_trans (st=0x556dd8391f80) at ../src/mesa/state_tracker/st_cb_bitmap.c:402 #1 accum_bitmap (bitmap=0x7fc3ff07fcf1 "", unpack=0x7fc3f4201ad8, height=14, width=7, y=441, x=0, ctx=0x7fc3f41cf010) at ../src/mesa/state_tracker/st_cb_bitmap.c:516 #2 st_Bitmap (ctx=0x7fc3f41cf010, x=0, y=441, width=7, height=14, unpack=0x7fc3f4201ad8, bitmap=0x7fc3ff07fcf1 "") at ../src/mesa/state_tracker/st_cb_bitmap.c:621 #3 0x7fc3fc8c167e in _mesa_Bitmap (width=7, height=14, xorig=, yorig=3, xmove=7, ymove=0, bitmap=0x7fc3ff07fcf1 "") at ../src/mesa/main/drawpix.c:357 #4 0x7fc3ff066830 in glutBitmapCharacter (fontID=0x556dd6aba740 , character=) at freeglut_font.c:122 #5 0x556dd6aa09ec in glutprintstring (x=, y=, z=, string=) at font.cpp:76 #6 glutprintstring (string=0x7fff4ffb0400 "Body distance from Sun (Km): 151595991.59", z=0, y=, x=0) at font.cpp:67 #7 printstring (x=x@entry=0, y=, z=z@entry=0, string=string@entry=0x7fff4ffb0400 "Body distance from Sun (Km): 151595991.59") at font.cpp:86 #8 0x556dd6a95150 in OnScreenInfo () at info.cpp:211 #9 0x556dd6a9f028 in Display () at ou.cpp:517 #10 0x7fc3ff06ed83 in fghRedrawWindow (window=0x556dd82bad20) at freeglut_main.c:231 #11 fghcbDisplayWindow (window=0x556dd82bad20, enumerator=0x7fff4ffb0570) at freeglut_main.c:248 #12 0x7fc3ff072619 in fgEnumWindows (enumCallback=enumCallback@entry=0x7fc3ff06ed10 , enumerator=enumerator@entry=0x7fff4ffb0570) at freeglut_structure.c:396 #13 0x7fc3ff06f2fb in fghDisplayAll () at freeglut_main.c:271 #14 glutMainLoopEvent () at freeglut_main.c:1523 #15 0x7fc3ff06fc0b in glutMainLoop () at freeglut_main.c:1571 #16 0x556dd6a85c3d in main (argc=, argv=0x7fff4ffb08a8) at ou.cpp:572
Bug#988174: (/usr/bin/qemu-aarch64-static: Segfaults sometimes on python3-minimal on arm64)
Dear Maintainer,
I did a little further investigation and found that it could be
reproduced with just the following line, inside the arm64 chroot:
for i in {1..100}; do echo $i; python3.9 -c "exit()"; done
This produced 13 crashes for the 100 runs.
But the crashes stop to appear when /proc is mounted inside the chroot.
With the help of strace:amd64, rr:amd64 and a self-built qemu-aarch64-static
I could locate the access [2] to /proc that, if failing,
seem to cause the segfault.
And the backtrace leads to this upstream change [1],
which matches this bug and a qemu-aarch64-static built
with this patch does not show the segfault anymore,
when /proc is not available.
Kind regards,
Bernhard
[1]
https://git.qemu.org/?p=qemu.git;a=commitdiff;h=0266e8e3b3981b492e82be20bb97e8ed9792ed00
[2]
(rr) bt
#0 0x00607402 in read_self_maps () at ../../util/selfmap.c:60
#1 0x005b5124 in pgb_find_hole
(guest_loaddr=guest_loaddr@entry=4194304, guest_size=guest_size@entry=22269416,
align=align@entry=4096, offset=0) at ../../linux-user/elfload.c:2211
#2 0x005b69bf in pgb_static (align=4096, orig_hiaddr=,
orig_loaddr=4194304, image_name=0x7ffc7ef22cf3 "/usr/bin/python3.9") at
../../linux-user/elfload.c:2305
#3 probe_guest_base (image_name=image_name@entry=0x7ffc7ef22cf3
"/usr/bin/python3.9", guest_loaddr=guest_loaddr@entry=4194304,
guest_hiaddr=) at ../../linux-user/elfload.c:2389
#4 0x005b71e7 in load_elf_image (image_name=0x7ffc7ef22cf3 "/usr/bin/python3.9",
image_fd=3, info=info@entry=0x7ffc7ef20bc0, pinterp_name=pinterp_name@entry=0x7ffc7ef20920,
bprm_buf=bprm_buf@entry=0x7ffc7ef20dd0 "\177ELF\002\001\001") at
../../linux-user/elfload.c:2676
#5 0x005b754c in load_elf_binary (bprm=bprm@entry=0x7ffc7ef20dd0,
info=info@entry=0x7ffc7ef20bc0) at ../../linux-user/elfload.c:3104
#6 0x005b49db in loader_exec (fdexec=fdexec@entry=3, filename=, argv=argv@entry=0x23df520, envp=envp@entry=0x23eee00,
regs=regs@entry=0x7ffc7ef20cc0, infop=infop@entry=0x7ffc7ef20bc0, bprm=) at ../../linux-user/linuxload.c:147
#7 0x00402801 in main (argc=, argv=0x7ffc7ef21388,
envp=) at ../../linux-user/main.c:832
Bug#988174: (/usr/bin/qemu-aarch64-static: Segfaults sometimes on python3-minimal on arm64)
Am 22.05.21 um 00:11 schrieb Bernhard Übelacker: Maybe systemd-coredump would collect a core of such a crash? And I did a debootstrap in a loop and got three crashes out of 20 tries. A core was collected and shows the stack below. It is strange that exec_path shows just "/arm64" and trying gdb to print the variable mmap_lock_count shows a warning about a corrupted shared library list. Kind regards, Bernhard (gdb) bt #0 have_mmap_lock () at ../../linux-user/mmap.c:43 #1 0x005863ac in page_set_flags (start=start@entry=4194304, end=end@entry=21041152, flags=flags@entry=8) at ../../accel/tcg/translate-all.c:2568 #2 0x0056416d in target_mmap (start=start@entry=4194304, len=, len@entry=16842963, target_prot=target_prot@entry=0, flags=16434, fd=fd@entry=-1, offset=offset@entry=0) at ../../linux-user/mmap.c:602 #3 0x0057be4d in load_elf_image (image_name=0x7ffe12b44e4f "/arm64", image_fd=3, info=info@entry=0x7ffe12b43b20, pinterp_name=pinterp_name@entry=0x7ffe12b43880, bprm_buf=bprm_buf@entry=0x7ffe12b43d30 "\177ELF\002\001\001") at ../../linux-user/elfload.c:2700 #4 0x0057c5bc in load_elf_binary (bprm=bprm@entry=0x7ffe12b43d30, info=info@entry=0x7ffe12b43b20) at ../../linux-user/elfload.c:3104 #5 0x00571a4b in loader_exec (fdexec=fdexec@entry=3, filename=, argv=argv@entry=0x20b8d20, envp=envp@entry=0x210db50, regs=regs@entry=0x7ffe12b43c20, infop=infop@entry=0x7ffe12b43b20, bprm=) at ../../linux-user/linuxload.c:147 #6 0x00402831 in main (argc=, argv=0x7ffe12b442e8, envp=) at ../../linux-user/main.c:831 (gdb) display/i $pc 1: x/i $pc => 0x5637c0 : mov%fs:0xff50,%eax (gdb) frame 6 #6 0x00402831 in main (argc=, argv=0x7ffe12b442e8, envp=) at ../../linux-user/main.c:831 831 ../../linux-user/main.c: Datei oder Verzeichnis nicht gefunden. (gdb) print argv[0] $6 = 0x7ffe12b44e25 "/usr/libexec/qemu-binfmt/aarch64-binfmt-P" (gdb) print argv[1] $7 = 0x7ffe12b44e4f "/arm64" (gdb) print argv[2] $8 = 0x7ffe12b44e56 "/arm64" (gdb) print argv[3] $9 = 0x0 (gdb) print _lock_count warning: Corrupted shared library list: 0xd5f120 != 0x0 Cannot find thread-local storage for LWP 148246, executable file /usr/lib/debug/.build-id/2e/c1a124ce847ca347222b5ddcdb8639aadff4e0.debug: Cannot find thread-local variables on this target (gdb) print exec_path $32 = 0x7ffe12b44e4f "/arm64" From Diederik's second mail: [44932.698657] python3.9[313800]: segfault at 2524310 ip 005637c0 sp 7ffdeefd1098 error 4 in qemu-aarch64-static[401000+3e3000] [44932.698664] Code: 00 e9 94 78 1c 00 0f 1f 40 00 64 83 2c 25 50 ff ff ff 01 74 05 c3 0f 1f 40 00 48 8d 3d e9 d0 7f 00 e9 e4 85 1c 00 0f 1f 40 00 <64> 8b 04 25 50 ff ff ff 85 c0 0f 9f c0 c3 66 90 48 83 ec 08 64 8b https://wiki.debian.org/InterpretingKernelOutputAtProcessCrash error 4 == 0b0100: bit 0 ==0: no page found bit 1 ==0: read access bit 2 ==1: user-mode access echo -n "find /b ..., ..., 0x" && \ echo "00 e9 94 78 1c 00 0f 1f 40 00 64 83 2c 25 50 ff ff ff 01 74 05 c3 0f 1f 40 00 48 8d 3d e9 d0 7f 00 e9 e4 85 1c 00 0f 1f 40 00 <64> 8b 04 25 50 ff ff ff 85 c0 0f 9f c0 c3 66 90 48 83 ec 08 64 8b" \ | sed 's/[<>]//g' | sed 's/ /, 0x/g' find /b ..., ..., 0x00, 0xe9, 0x94, 0x78, 0x1c, 0x00, 0x0f, 0x1f, 0x40, 0x00, 0x64, 0x83, 0x2c, 0x25, 0x50, 0xff, 0xff, 0xff, 0x01, 0x74, 0x05, 0xc3, 0x0f, 0x1f, 0x40, 0x00, 0x48, 0x8d, 0x3d, 0xe9, 0xd0, 0x7f, 0x00, 0xe9, 0xe4, 0x85, 0x1c, 0x00, 0x0f, 0x1f, 0x40, 0x00, 0x64, 0x8b, 0x04, 0x25, 0x50, 0xff, 0xff, 0xff, 0x85, 0xc0, 0x0f, 0x9f, 0xc0, 0xc3, 0x66, 0x90, 0x48, 0x83, 0xec, 0x08, 0x64, 0x8b ## # Bullseye/testing amd64 qemu VM 2021-05-21 dpkg --add-architecture arm64 apt update apt dist-upgrade apt install gdb qemu-user-static-dbgsym echo "set enable-bracketed-paste off" >> /etc/inputrc; bash gdb -q set width 0 set pagination off file /usr/bin/qemu-aarch64-static tb main run (gdb) info target Symbols from "/usr/bin/qemu-aarch64-static". Native process: Using the running image of child Thread 0xd873c0 (LWP 975). While running this, GDB does not access memory from... Local exec file: `/usr/bin/qemu-aarch64-static', file type elf64-x86-64. Entry point: 0x403670 ... 0x00401140 - 0x007e2872 is .text ... (gdb) find /b 0x00401140, 0x007e2872, 0x00, 0xe9, 0x94, 0x78, 0x1c, 0x00, 0x0f, 0x1f, 0x40, 0x00, 0x64, 0x83, 0x2c, 0x25, 0x50, 0xff, 0xff, 0xff, 0x01, 0x74, 0x05, 0xc3, 0x0f, 0x1f, 0x40, 0x00, 0x48, 0x8d, 0x3d, 0xe9, 0xd0, 0x7f, 0x00, 0xe9, 0xe4, 0x85, 0x1c, 0x00, 0x0f, 0x1f, 0x40, 0x00, 0x64, 0x8b, 0x04, 0x25, 0x50, 0xff, 0xff, 0xff, 0x85, 0xc0, 0x0f, 0x9f, 0xc0, 0xc3, 0x66, 0x90, 0x48, 0x83, 0xec, 0x08, 0x64, 0x8b 0x563796 1 pattern found. (gdb) b * (0x5637
Bug#988174: (/usr/bin/qemu-aarch64-static: Segfaults sometimes on python3-minimal on arm64)
Hello Diederik,
I am not involved in packaging, just
trying to collect some information.
Architecture: amd64 (x86_64)
The subject on the email mentions "on arm64".
From the Architecture line I assume this should read "on amd64"?
[44932.698657] python3.9[313800]: segfault at 2524310 ip 005637c0 sp
7ffdeefd1098 error 4 in qemu-aarch64-static[401000+3e3000]
[44932.698664] Code: 00 e9 94 78 1c 00 0f 1f 40 00 64 83 2c 25 50 ff ff ff 01 74 05
c3 0f 1f 40 00 48 8d 3d e9 d0 7f 00 e9 e4 85 1c 00 0f 1f 40 00 <64> 8b 04 25 50
ff ff ff 85 c0 0f 9f c0 c3 66 90 48 83 ec 08 64 8b
The breaking instruction seems to be here:
0x5637c0: file ../../linux-user/mmap.c, line 43.
0x005637c0 : 64 8b 04 25 50 ff ff ff mov
%fs:0xff50,%eax
https://sources.debian.org/src/qemu/1:5.2+dfsg-10/linux-user/mmap.c/#L43
25 static __thread int mmap_lock_count;
...
41 bool have_mmap_lock(void)
42 {
43 return mmap_lock_count > 0 ? true : false;
44 }
I have hoped it might be more clear, but this might probably
be related to the thread local storage of mmap_lock_count.
Maybe systemd-coredump would collect a core of such a crash?
Kind regards,
Bernhard
From Diederik's second mail:
[44932.698657] python3.9[313800]: segfault at 2524310 ip 005637c0 sp
7ffdeefd1098 error 4 in qemu-aarch64-static[401000+3e3000]
[44932.698664] Code: 00 e9 94 78 1c 00 0f 1f 40 00 64 83 2c 25 50 ff ff ff 01
74 05 c3 0f 1f 40 00 48 8d 3d e9 d0 7f 00 e9 e4 85 1c 00 0f 1f 40 00 <64> 8b 04
25 50 ff ff ff 85 c0 0f 9f c0 c3 66 90 48 83 ec 08 64 8b
https://wiki.debian.org/InterpretingKernelOutputAtProcessCrash
error 4 == 0b0100:
bit 0 ==0: no page found
bit 1 ==0: read access
bit 2 ==1: user-mode access
echo -n "find /b ..., ..., 0x" && \
echo "00 e9 94 78 1c 00 0f 1f 40 00 64 83 2c 25 50 ff ff ff 01 74 05 c3 0f 1f
40 00 48 8d 3d e9 d0 7f 00 e9 e4 85 1c 00 0f 1f 40 00 <64> 8b 04 25 50 ff ff ff
85 c0 0f 9f c0 c3 66 90 48 83 ec 08 64 8b" \
| sed 's/[<>]//g' | sed 's/ /, 0x/g'
find /b ..., ..., 0x00, 0xe9, 0x94, 0x78, 0x1c, 0x00, 0x0f, 0x1f, 0x40, 0x00,
0x64, 0x83, 0x2c, 0x25, 0x50, 0xff, 0xff, 0xff, 0x01, 0x74, 0x05, 0xc3, 0x0f,
0x1f, 0x40, 0x00, 0x48, 0x8d, 0x3d, 0xe9, 0xd0, 0x7f, 0x00, 0xe9, 0xe4, 0x85,
0x1c, 0x00, 0x0f, 0x1f, 0x40, 0x00, 0x64, 0x8b, 0x04, 0x25, 0x50, 0xff, 0xff,
0xff, 0x85, 0xc0, 0x0f, 0x9f, 0xc0, 0xc3, 0x66, 0x90, 0x48, 0x83, 0xec, 0x08,
0x64, 0x8b
##
# Bullseye/testing amd64 qemu VM 2021-05-21
dpkg --add-architecture arm64
apt update
apt dist-upgrade
apt install gdb qemu-user-static-dbgsym
echo "set enable-bracketed-paste off" >> /etc/inputrc; bash
gdb -q
set width 0
set pagination off
file /usr/bin/qemu-aarch64-static
tb main
run
(gdb) info target
Symbols from "/usr/bin/qemu-aarch64-static".
Native process:
Using the running image of child Thread 0xd873c0 (LWP 975).
While running this, GDB does not access memory from...
Local exec file:
`/usr/bin/qemu-aarch64-static', file type elf64-x86-64.
Entry point: 0x403670
...
0x00401140 - 0x007e2872 is .text
...
(gdb) find /b 0x00401140, 0x007e2872, 0x00, 0xe9, 0x94, 0x78,
0x1c, 0x00, 0x0f, 0x1f, 0x40, 0x00, 0x64, 0x83, 0x2c, 0x25, 0x50, 0xff, 0xff,
0xff, 0x01, 0x74, 0x05, 0xc3, 0x0f, 0x1f, 0x40, 0x00, 0x48, 0x8d, 0x3d, 0xe9,
0xd0, 0x7f, 0x00, 0xe9, 0xe4, 0x85, 0x1c, 0x00, 0x0f, 0x1f, 0x40, 0x00, 0x64,
0x8b, 0x04, 0x25, 0x50, 0xff, 0xff, 0xff, 0x85, 0xc0, 0x0f, 0x9f, 0xc0, 0xc3,
0x66, 0x90, 0x48, 0x83, 0xec, 0x08, 0x64, 0x8b
0x563796
1 pattern found.
(gdb) b * (0x563796 + 42)
Breakpoint 2 at 0x5637c0: file ../../linux-user/mmap.c, line 43.
(gdb) info b
Num Type Disp Enb AddressWhat
2 breakpoint keep y 0x005637c0 in have_mmap_lock at
../../linux-user/mmap.c:43
(gdb) disassemble /r 0x563796, 0x563796 + 62
Dump of assembler code from 0x563796 to 0x5637d4:
0x00563796 : 00 e9 add
%ch,%cl
0x00563798 : 94 xchg
%eax,%esp
0x00563799 : 78 1c js
0x5637b7
0x0056379b : 00 0f add
%cl,(%rdi)
0x0056379d: 1f (bad)
0x0056379e: 40 00 64 83 2c add
%spl,0x2c(%rbx,%rax,4)
0x005637a3 : 25 50 ff ff ff and
$0xff50,%eax
0x005637a8 : 01 74 05 c3 add
%esi,-0x3d(%rbp,%rax,1)
0x005637ac : 0f 1f 40 00 nopl
0x0(%rax)
0x005637b0 : 48 8d 3d e9 d0 7f 00lea
0x7fd0e9(%rip),%rdi# 0xd608a0
0x005637b7 : e9 e4 85 1c 00 jmp
0x72bda0 <__pthread_mutex_unlock>
0x005637bc: 0f 1f 40 00
Bug#987566: ghostscript: PDF Interpreter error on armel
Hello Guilhem, hello Jonas, might this be a similar or the same issue as in #942055 ? I took the example file from this issue, created an armel buster chroot and ran it once at my arm5tel device, and once at a armv7l cpu android device (unfortunately with a non-debian kernel). - with the arm5tel cpu I received the "Error reading" message. - with the arm7l cpu no such failure and much more output was produced. The same test with the arm5tel cpu with a bullseye chroot seems also not affected. Therefore my suspicion that gcc in buster produces instructions, which do not work as expected at arm5tel, just at arm7l cpus. Unfortunately I did never involve upstream with #942055, to ask how ghostscript could be debugged, to identify the related functions and prove this suspicion. Kind regards, Bernhard https://bugs.debian.org/942055
Bug#987642: freecad: wrong-sized widgets, fonts, menus and toolbars
Hello, just a small note about the toolbars in the screenshot may be looking similar to these in bug#986821. Kind regards, Bernhard https://bugs.debian.org/986821
Bug#987886: krita: Right-clicking on the canvas crashes krita
Hello Torbjørn Birch Moltu, I tried to reproduce this issue inside a virtual machine. But there the menu opens without the issue. Does this happen to you if you startup without the wacom input attached? Next thing you could try is to startup krita this way: export MALLOC_CHECK_=3 krita --new-image RGBA,U8,1600,1600 Does the KCrash window open or do you have the sad smiley at the bottom right near the clock? Kind regards, Bernhard
Bug#987916: openssh: Segfault or malloc_consolidate(): invalid chunk size + Aborted with GSSAPITrustDns yes
Hello Chris, I am not involved in packaging, just trying to give some pointers to get better information for the maintainers. In [1] are several possible actions listed, that could be used to get more informations. Just to clarify, host heisenberg is your local system, from which the connection starts? If yes, I would propose these actions: - If possible, install systemd-coredump. Then in the journalctl output there should already appear a basic backtrace with a crashing process, plus a core gets collected of it and stored for some time (e.g. "coredumpctl list" or "coredumpctl gdb"). - Try connecing setting following environment before: export MALLOC_CHECK_=3 That should make stricter checks in the allocator and maybe fail earlier. - You might install debug symbols too, also described in [1]. With that you could also start the connection inside a debugger: gdb -q --args ssh hammercloud-ai-11.cern.ch -v And do following actions at the gdb prompt: run bt detach quit That way the 'bt' command should print a backtrace that might help to reproduce the issue. Kind regards, Bernhard [1] https://wiki.debian.org/HowToGetABacktrace
Bug#943398: Closing this bug (BTS maintenance for src:linux bugs)
Hello, just for the record. Upstream seems to have fixed this in [1] which is included in kernel v5.8 and later. Kind regards, Bernhard [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/tools/perf/ui/browsers/hists.c?id=d61cbb859b45fdb6b4997f2d51834fae41af0e94
Bug#869684: linux-image-4.9.0-3-686-pae: Thinkpad T60 hangs on resume after suspend to disk; regress since Debian 8
Control: fixed -1 linux/5.10.28-1 Dear Maintainer, I got that Thinkpad T60 back, and did upgrade the installation to bullseye. I can now confirm that the nokaslr workaround is not needed any more, hibernate and resume is working for me with current kernel 5.10.0-6-686-pae/5.10.28-1 in testing. Unfortunately I did not check if buster kernel already would have worked without the nokaslr parameter. I hope it is ok to mark it fixed for current version. Kind regards, Bernhard
Bug#815909: Fwd: x11vnc session unrecoverable after trying to switch user in xfce
Hello, just for anyone coming here through internet searches. The "caught XIO error:" leads to this upstream bug reports: https://github.com/LibVNC/x11vnc/issues/147 https://github.com/LibVNC/x11vnc/issues/154 With the mentioned option "-noxdamage" I could stop getting this error. I received this with a i686 system updated to bullseye/testing today, running a plasma desktop. Unfortunately I could not reproduce this connecting to a similar installation inside qemu VM. Kind regards, Bernhard
Bug#987290: GIMP 2.10.8-2 crashes on segmentation error while opening in buster
Hello Simon, Am 21.04.21 um 20:19 schrieb Simon McVittie: On Tue, 20 Apr 2021 at 22:17:58 +0200, Chris Born wrote: This looks like #953880/#953854/#953794, ... Do you see enough similarity to #968005 and #954739 to justify closing or merging them too? Kind regards, Bernhard
Bug#986692: crash at startup
Just for reference, why g++ does not error here, this gcc bug might be interesting: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43943 Kind regards, Bernhard
Bug#986692: crash at startup
Dear Maintainer,
I tried to have a look, but got no clue why a Unwind should take place
until I saw the old build log [1].
There I found this warning:
Levels.cpp: In member function ‘bool Levels::addLevel(const string&, int,
int)’:
Levels.cpp:118:1: warning: no return statement in function returning non-void
[-Wreturn-type]
118 | }
| ^
So I assume g++ puts no ret instruction to this method
and therefore the Unwind gets executed because of this.
I wonder why this is just a warning ...
Attached patch contains a few changes for these warnings:
warning: no return statement in function returning non-void [-Wreturn-type]
warning: control reaches end of non-void function [-Wreturn-type]
warning: attempt to free a non-heap object ‘host’ [-Wfree-nonheap-object]
A build with this patch applied does not crash at startup.
(Testing if it really starts up took longer than the actual error ;-) )
Kind regards,
Bernhard
[1]
https://buildd.debian.org/status/fetch.php?pkg=numptyphysics=amd64=0.2%2Bsvn157-0.4=1573519484=0
Bug-Debian: https://bugs.debian.org/986692
Forwarded: no
Last-Update: 2021-04-22
--- numptyphysics-0.2+svn157.orig/Game.h
+++ numptyphysics-0.2+svn157/Game.h
@@ -58,7 +58,7 @@ struct GameControl
virtual ~GameControl() {}
virtual bool save( const char *file=NULL ) =0;
virtual bool send() =0;
- virtual bool load( const char* file ) {};
+ virtual bool load( const char* file ) { return false; };
virtual void gotoLevel( int l, bool replay=false ) =0;
virtual void clickMode(int cm) =0;
Levels& levels() { return *m_levels; }
--- numptyphysics-0.2+svn157.orig/Http.cpp
+++ numptyphysics-0.2+svn157/Http.cpp
@@ -114,7 +114,6 @@ bool Http::get( const char* uri,
}
fclose ( m_file );
- free( host );
return m_size > 0;
}
@@ -175,6 +174,7 @@ bool Http::post( const char* uri, const
fprintf(stderr,"http_get wobbly: %s\n",w.what());
}
}
+ return true;
}
--- numptyphysics-0.2+svn157.orig/Levels.cpp
+++ numptyphysics-0.2+svn157/Levels.cpp
@@ -114,7 +114,7 @@ bool Levels::addPath( const char* path )
bool Levels::addLevel( const string& file, int rank, int index )
{
- addLevel( getCollection(MISC_COLLECTION), file, rank, index );
+ return addLevel( getCollection(MISC_COLLECTION), file, rank, index );
}
bool Levels::addLevel( Collection* collection,
@@ -248,6 +248,7 @@ int Levels::collectionFromLevel( int i,
}
}
}
+ return -1;
}
std::string Levels::collectionName( int i, bool pretty )
--- numptyphysics-0.2+svn157.orig/Scene.cpp
+++ numptyphysics-0.2+svn157/Scene.cpp
@@ -616,6 +616,7 @@ bool Scene::activateStroke( Stroke *s )
{
activate(s);
m_recorder.activateStroke( m_strokes.indexOf(s) );
+ return true;
}
void Scene::getJointCandidates( Stroke* s, Path& pts )
--- numptyphysics-0.2+svn157.orig/Ui.cpp
+++ numptyphysics-0.2+svn157/Ui.cpp
@@ -1081,7 +1081,7 @@ bool Dialog::onEvent( Event& ev )
return Panel::onEvent(ev);
}
-bool Dialog::close()
+void Dialog::close()
{
if (m_parent) {
//fprintf(stderr,"close dialog\n");
--- numptyphysics-0.2+svn157.orig/Ui.h
+++ numptyphysics-0.2+svn157/Ui.h
@@ -321,7 +321,7 @@ class Dialog : public Panel
void onTick( int tick );
bool processEvent( SDL_Event& ev );
bool onEvent( Event& ev );
- bool close();
+ void close();
virtual Container* content() { return m_content; }
Button* leftControl() { return m_left; }
Button* rightControl() { return m_right; }
--- numptyphysics-0.2+svn157.orig/Worker.cpp
+++ numptyphysics-0.2+svn157/Worker.cpp
@@ -64,4 +64,5 @@ int WorkerBase::startThread(void* wbase)
event.user.data1 = wbase;
event.user.data2 = 0;
SDL_PushEvent();
+ return 0;
}
Bug#987290: GIMP 2.10.8-2 crashes on segmentation error while opening in buster
Dear Maintainer, ... #3 0x559e07a698d8 in gimp_fatal_error () #4 0x559e07a6a037 in ?? () #5 #6 0x559e07dd1e3b in gimp_param_spec_layer_id () #7 0x559e07cf57ed in gimp_pdb_compat_param_spec () #8 0x559e07d02077 in gimp_plug_in_handle_message () #9 0x559e07d10501 in gimp_plug_in_manager_call_query () #10 0x559e07d085b8 in gimp_plug_in_manager_restore () #11 0x559e07d25e7d in ?? () ... This backtrace seems similar to following upstream issues: https://gitlab.gnome.org/GNOME/gimp/-/issues/4392 https://gitlab.gnome.org/GNOME/gimp/-/issues/6021 (mentions a possible workaround) And downstream this bug shows up and links to a few others: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968005 Kind regards, Bernhard
Bug#986623: tuxmath: Segfaults on startup
Attached patch just renames the global variable blits to tmblits.
A package tuxmath built with this patch does not show this crash.
Sorry, forgot to attach.
Bug-Debian: https://bugs.debian.org/986623
Forwarded: no
Last-Update: 2021-04-20
--- tuxmath-2.0.3.orig/src/titlescreen.c
+++ tuxmath-2.0.3/src/titlescreen.c
@@ -55,7 +55,7 @@ struct blit {
SDL_Rect *srcrect;
SDL_Rect *dstrect;
unsigned char type;
-} blits[MAX_UPDATES];
+} tmblits[MAX_UPDATES];
// Lessons available for play
char **lesson_list_titles = NULL;
@@ -1019,8 +1019,8 @@ void init_blits(void) {
int i;
for (i = 0; i < MAX_UPDATES; ++i) {
- blits[i].srcrect = [i];
- blits[i].dstrect = [i];
+ tmblits[i].srcrect = [i];
+ tmblits[i].dstrect = [i];
}
}
@@ -1032,14 +1032,14 @@ void update_screen(int *frame) {
/* -- First erase everything we need to -- */
for (i = 0; i < numupdates; i++)
- if (blits[i].type == 'E')
- SDL_LowerBlit(blits[i].src, blits[i].srcrect, screen, blits[i].dstrect);
+ if (tmblits[i].type == 'E')
+ SDL_LowerBlit(tmblits[i].src, tmblits[i].srcrect, screen, tmblits[i].dstrect);
//SNOW_erase();
/* -- then draw -- */
for (i = 0; i < numupdates; i++)
- if (blits[i].type == 'D')
- SDL_BlitSurface(blits[i].src, blits[i].srcrect, screen, blits[i].dstrect);
+ if (tmblits[i].type == 'D')
+ SDL_BlitSurface(tmblits[i].src, tmblits[i].srcrect, screen, tmblits[i].dstrect);
//SNOW_draw();
/* -- update the screen only where we need to! -- */
@@ -1067,7 +1067,7 @@ void add_rect(SDL_Rect* src, SDL_Rect* d
return;
}
-update = [numupdates++];
+update = [numupdates++];
update->srcrect->x = src->x;
update->srcrect->y = src->y;
Bug#986623: tuxmath: Segfaults on startup
Dear Maintainer, I tried to have a look at this crash and got this backtrace [1]. It looks like there is a disaggreement about the size of the blits structure, one inside tuxmath and one inside libt4k-common0: tuxmath-2.0.3/src/titlescreen.h:65:#define MAX_UPDATES 180 tuxmath-2.0.3/src/titlescreen.c:58:} blits[MAX_UPDATES]; t4kcommon-0.1.1/src/t4k_sdl.c:954:#define MAX_UPDATES 512 t4kcommon-0.1.1/src/t4k_sdl.c:966:} blits[MAX_UPDATES]; Because of this libt4k-common0 accesses memory behind the 180 records of the blits structure from tuxmath. Attached patch just renames the global variable blits to tmblits. A package tuxmath built with this patch does not show this crash. I found no exact match in upstream bug trackers, but I guess [2] is about this bug. Currently I see no direct connection to #933346. Kind regards, Bernhard [1] (gdb) bt #0 0x7f063879a972 in T4K_AddRect (src=src@entry=0x7ffede50c468, dst=dst@entry=0x7ffede50c468) at t4k_sdl.c:1034 #1 0x7f063879acb3 in T4K_TransWipe (newbkg=0x55bd0b680520, type=, type@entry=RANDOM_WIPE, segments=segments@entry=5, duration=duration@entry=20) at t4k_sdl.c:824 #2 0x55bd0893b23f in TitleScreen () at titlescreen.c:245 #3 0x55bd08938bee in main (argc=, argv=) at tuxmath.c:41 https://sources.debian.org/src/t4kcommon/0.1.1-10/src/t4k_sdl.c/#L1034 [2] https://github.com/tux4kids/tuxmath/issues/16 # single-use Bullseye/testing amd64 qemu VM 2021-04-20 echo "set enable-bracketed-paste off" >> /etc/inputrc; bash apt update # to speedup testing mv /etc/manpath.config /etc/manpath.config.renamed apt install libeatmydata1 export LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libeatmydata.so apt dist-upgrade apt install systemd-coredump mc gdb rr lightdm xserver-xorg jwm fakeroot tuxmath \ tuxmath-dbgsym libt4k-common0-dbgsym apt build-dep tuxmath libt4k-common0 mkdir /home/benutzer/source/tuxmath/orig -p cd/home/benutzer/source/tuxmath/orig apt source tuxmath cd mkdir /home/benutzer/source/libt4k-common0/orig -p cd/home/benutzer/source/libt4k-common0/orig apt source libt4k-common0 cd benutzer@debian:~$ export DISPLAY=:0 benutzer@debian:~$ tuxmath Initializing Tux4Kids-Common 0.1.1 ALSA lib pcm.c:8545:(snd_pcm_recover) underrun occurred libpng warning: iCCP: known incorrect sRGB profile libpng warning: iCCP: known incorrect sRGB profile libpng warning: iCCP: known incorrect sRGB profile libpng warning: iCCP: known incorrect sRGB profile libpng warning: iCCP: known incorrect sRGB profile libpng warning: iCCP: known incorrect sRGB profile libpng warning: iCCP: known incorrect sRGB profile libpng warning: iCCP: known incorrect sRGB profile libpng warning: iCCP: known incorrect sRGB profile libpng warning: iCCP: known incorrect sRGB profile libpng warning: iCCP: known incorrect sRGB profile libpng warning: iCCP: known incorrect sRGB profile libpng warning: iCCP: known incorrect sRGB profile libpng warning: iCCP: known incorrect sRGB profile libpng warning: iCCP: known incorrect sRGB profile libpng warning: iCCP: known incorrect sRGB profile libpng warning: iCCP: known incorrect sRGB profile libpng warning: iCCP: known incorrect sRGB profile Speicherzugriffsfehler (Speicherabzug geschrieben) root@debian:~# coredumpctl list TIMEPID UID GID SIG COREFILE EXE Tue 2021-04-20 15:45:51 CEST644 1000 1000 11 present /usr/lib/tuxmath/tuxmath root@debian:~# coredumpctl gdb 644 PID: 644 (tuxmath) UID: 1000 (benutzer) GID: 1000 (benutzer) Signal: 11 (SEGV) Timestamp: Tue 2021-04-20 15:45:50 CEST (38s ago) Command Line: tuxmath Executable: /usr/lib/tuxmath/tuxmath Control Group: /user.slice/user-1000.slice/session-5.scope Unit: session-5.scope Slice: user-1000.slice Session: 5 Owner UID: 1000 (benutzer) Boot ID: 27f9ae5d40034f8484e4d155de897ba4 Machine ID: 33f18f39d2a9438eb75b0ed52848afcd Hostname: debian Storage: /var/lib/systemd/coredump/core.tuxmath.1000.27f9ae5d40034f8484e4d155de897ba4.644.161892635000.zst Message: Process 644 (tuxmath) of user 1000 dumped core. Stack trace of thread 644: #0 0x7f063879a972 T4K_AddRect (libt4k_common.so.0 + 0xe972) #1 0x7f063879acb3 T4K_TransWipe (libt4k_common.so.0 + 0xecb3) #2 0x55bd0893b23f n/a (tuxmath + 0x923f) #3 0x55bd08938bee main (tuxmath + 0x6bee) #4 0x7f06385c9d0a __libc_start_main (libc.so.6 + 0x26d0a) #5 0x55bd08938c2a n/a (tuxmath + 0x6c2a) ... Core was generated by `tuxmath'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x7f063879a972 in T4K_AddRect () from /lib/x86_64-linux-gnu/libt4k_common.so.0 [Current thread is 1 (Thread 0x7f0632edfe80 (LWP 644))] (gdb)
Bug#986564: Crash on pool-evolution
Dear Maintainer,
with the help of the dbgsym package the "Code:" line
points to this line [1]:
0x7fffebed7f9c in camel_imapx_folder_set_mailbox at
./src/camel/providers/imapx/camel-imapx-folder.c:1371
The function camel_imapx_folder_set_mailbox then points
to this upstream bug report [2].
That also mentions another Debian report #985353, which
shows the same line and instruction offset.
Kind regards,
Bernhard
[1]
https://sources.debian.org/src/evolution-data-server/3.38.3-1/src/camel/providers/imapx/camel-imapx-folder.c/#L1371
https://gitlab.gnome.org/GNOME/evolution-data-server/-/blob/master/src/camel/providers/imapx/camel-imapx-folder.c#L1364
[2]
https://gitlab.gnome.org/GNOME/evolution-data-server/-/issues/312
#985353
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=985353
From submitter:
kernel: [27363.195104] pool-evolution[76405]: segfault at 28 ip
7f6d1e663f9c sp 7f6d0b7fd7a0 error 4 in
libcamelimapx.so[7f6d1e656000+3b000]
kernel: [27363.195115] Code: c6 e8 78 48 ff ff 48 89 c7 e8 b0 36 ff ff 4c 89 ee
48 89 c7 e8 65 48 ff ff 4c 89 e7 49 89 c5 e8 ba 56 ff ff 85 c0 74 10 89 c6 <49>
3b 75 28 74 08 48 89 ef e8 b6 36 ff ff 48 89 ef be 50 00 00 00
https://wiki.debian.org/InterpretingKernelOutputAtProcessCrash
"error 4" == 0b0100
bit 0 ==0: no page found
bit 1 ==0: read access
bit 2 ==1: user-mode access
echo -n "find /b ..., ..., 0x" && \
echo "c6 e8 78 48 ff ff 48 89 c7 e8 b0 36 ff ff 4c 89 ee 48 89 c7 e8 65 48 ff
ff 4c 89 e7 49 89 c5 e8 ba 56 ff ff 85 c0 74 10 89 c6 <49> 3b 75 28 74 08 48 89
ef e8 b6 36 ff ff 48 89 ef be 50 00 00 00" \
| sed 's/[<>]//g' | sed 's/ /, 0x/g'
find /b ..., ..., 0xc6, 0xe8, 0x78, 0x48, 0xff, 0xff, 0x48, 0x89, 0xc7, 0xe8,
0xb0, 0x36, 0xff, 0xff, 0x4c, 0x89, 0xee, 0x48, 0x89, 0xc7, 0xe8, 0x65, 0x48,
0xff, 0xff, 0x4c, 0x89, 0xe7, 0x49, 0x89, 0xc5, 0xe8, 0xba, 0x56, 0xff, 0xff,
0x85, 0xc0, 0x74, 0x10, 0x89, 0xc6, 0x49, 0x3b, 0x75, 0x28, 0x74, 0x08, 0x48,
0x89, 0xef, 0xe8, 0xb6, 0x36, 0xff, 0xff, 0x48, 0x89, 0xef, 0xbe, 0x50, 0x00,
0x00, 0x00
# single-use Bullseye/testing amd64 qemu VM 2021-04-20
echo "set enable-bracketed-paste off" >> /etc/inputrc; bash
apt update
# to speedup testing
mv /etc/manpath.config /etc/manpath.config.renamed
apt install libeatmydata1
export LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libeatmydata.so
apt dist-upgrade
apt install systemd-coredump gdb evolution evolution-dbgsym
evolution-data-server-dbgsym
gdb -q
set width 0
set pagination off
file /usr/bin/evolution
tb main
run
call
dlopen("/usr/lib/evolution-data-server/camel-providers/libcamelimapx.so",0x102)
info share
find /b 0x7fffebecda50, 0x7fffebf044f1, 0xc6, 0xe8, 0x78, 0x48, 0xff,
0xff, 0x48, 0x89, 0xc7, 0xe8, 0xb0, 0x36, 0xff, 0xff, 0x4c, 0x89, 0xee, 0x48,
0x89, 0xc7, 0xe8, 0x65, 0x48, 0xff, 0xff, 0x4c, 0x89, 0xe7, 0x49, 0x89, 0xc5,
0xe8, 0xba, 0x56, 0xff, 0xff, 0x85, 0xc0, 0x74, 0x10, 0x89, 0xc6, 0x49, 0x3b,
0x75, 0x28, 0x74, 0x08, 0x48, 0x89, 0xef, 0xe8, 0xb6, 0x36, 0xff, 0xff, 0x48,
0x89, 0xef, 0xbe, 0x50, 0x00, 0x00, 0x00
b * (0x7fffebed7f72 + 42)
info b
disassemble camel_imapx_folder_set_mailbox
(gdb) info share
FromTo Syms Read Shared Object Library
...
0x7fffebecda50 0x7fffebf044f1 Yes
/usr/lib/evolution-data-server/camel-providers/libcamelimapx.so
(gdb) find /b 0x7fffebecda50, 0x7fffebf044f1, 0xc6, 0xe8, 0x78, 0x48,
0xff, 0xff, 0x48, 0x89, 0xc7, 0xe8, 0xb0, 0x36, 0xff, 0xff, 0x4c, 0x89, 0xee,
0x48, 0x89, 0xc7, 0xe8, 0x65, 0x48, 0xff, 0xff, 0x4c, 0x89, 0xe7, 0x49, 0x89,
0xc5, 0xe8, 0xba, 0x56, 0xff, 0xff, 0x85, 0xc0, 0x74, 0x10, 0x89, 0xc6, 0x49,
0x3b, 0x75, 0x28, 0x74, 0x08, 0x48, 0x89, 0xef, 0xe8, 0xb6, 0x36, 0xff, 0xff,
0x48, 0x89, 0xef, 0xbe, 0x50, 0x00, 0x00, 0x00
0x7fffebed7f72
1 pattern found.
(gdb) b * (0x7fffebed7f72 + 42)
Breakpoint 2 at 0x7fffebed7f9c: file
./src/camel/providers/imapx/camel-imapx-folder.c, line 1371.
(gdb) info b
Num Type Disp Enb AddressWhat
2 breakpoint keep y 0x7fffebed7f9c in
camel_imapx_folder_set_mailbox at
./src/camel/providers/imapx/camel-imapx-folder.c:1371
(gdb) disassemble camel_imapx_folder_set_mailbox
Dump of assembler code for function camel_imapx_folder_set_mailbox:
0x7fffebed7ee0 <+0>: push %r13
0x7fffebed7ee2 <+2>: push %r12
0x7fffebed7ee4 <+4>: mov%rsi,%r12
0x7fffebed7ee7 <+7>: push %rbp
0x7fffebed7ee8 <+8>: mov%rdi,%rbp
0x7fffebed7eeb <+11>:call 0x7fffebecc7c0
0x7fffebed7ef0 <+16>:test %rbp,%rbp
0x7fffebed7ef3 <+19>:je 0x7fffebed7fd0
0x7fffebed7ef9 <+25>:mov%rax,%rsi
0x7fffebed7efc <+28>:mov0x0(%rbp),%rax
0x7fffebed7f00 <+32>:test %rax,%rax
0x7fffebed7f03 <+35>:je 0x7fffebed7f0a
0x7fffebed7f05 <+37>:cmp%rsi,(%rax)
Bug#986433: gnome-software segfaults before end of first window
Hello Jérémy, Am 19.04.21 um 16:35 schrieb Jérémy Lal: Meanwhile, i suspect the other bug i reported is similar you are right, at least the backtrace is also showing some 'valist'. This bug seems to lead to this upstream bug: https://gitlab.gnome.org/GNOME/gnome-software/-/issues/1007 (Which is resolved upstream with a kind of big merge request.) Kind regards, Bernhard
Bug#986432: totem: segfault when opening totem
Dear Maintainer, I tried to have a look and I could reproduce the crash [1]. I think this is caused by a call to gtk_list_store_set in totem_playlist_steal_current_starttime [2]. There a variadic argument list contains a plain 0, which might occupy just 32 bit, but gets later interpreted as gint64, therefore the terminating -1 gets overrun. A totem package rebuilt with attached patch does not show the crash inside the test VM. Kind regards, Bernhard [1] (gdb) bt #0 strlen () at ../sysdeps/arm/armv6t2/strlen.S:126 #1 0xb6e82878 in g_strdup (str=0x63fca6aa ) at ../../../glib/gstrfuncs.c:363 #2 0xb6f47144 in value_collect_string (value=0xbeffee60, n_collect_values=, collect_values=, collect_flags=) at ../../../gobject/gvaluetypes.c:293 #3 0xb680a3be in gtk_list_store_set_valist_internal (list_store=list_store@entry=0xa0b4c8, iter=iter@entry=0xbeffef44, emit_signal=emit_signal@entry=0xbeffeefc, maybe_need_sort=maybe_need_sort@entry=0xbeffef00, var_args=..., var_args@entry=...) at ../../../../gtk/gtkliststore.c:1033 #4 0xb680ab52 in gtk_list_store_set_valist (list_store=0xa0b4c8, iter=iter@entry=0xbeffef44, var_args=..., var_args@entry=...) at ../../../../gtk/gtkliststore.c:1137 #5 0xb680ac1a in gtk_list_store_set (list_store=, iter=0xbeffef44) at ../../../../gtk/gtkliststore.c:1179 #6 0xb6f91c40 in totem_playlist_steal_current_starttime (playlist=0xa1e100) at ../src/totem-playlist.c:1790 #7 0xb6f8b590 in update_seekable (totem=0x450140) at ../src/totem-object.c:2524 #8 property_notify_cb_seekable (bvw=, spec=, totem=0x450140) at ../src/totem-object.c:2616 #9 0xb6f2b252 in g_closure_invoke (closure=0x6e7048, return_value=return_value@entry=0x0, n_param_values=2, param_values=param_values@entry=0xbefff090, invocation_hint=invocation_hint@entry=0xbefff00c) at ../../../gobject/gclosure.c:810 #10 0xb6f38768 in signal_emit_unlocked_R (node=node@entry=0x448800, detail=105, instance=0xa6e290, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0xbefff090) at ../../../gobject/gsignal.c:3739 #11 0xb6f3ce12 in g_signal_emit_valist (instance=instance@entry=0xa6e290, signal_id=signal_id@entry=1, detail=detail@entry=320612, var_args=..., var_args@entry=...) at ../../../gobject/gsignal.c:3495 #12 0xb6f3d0a2 in g_signal_emit (instance=instance@entry=0xa6e290, signal_id=signal_id@entry=1, detail=105) at ../../../gobject/gsignal.c:3551 #13 0xb6f2e33e in g_object_dispatch_properties_changed (object=0xa6e290, n_pspecs=1, pspecs=) at ../../../gobject/gobject.c:1206 #14 0xb6f2faac in g_object_notify_by_spec_internal (pspec=, object=0xa6e290) at ../../../gobject/gobject.c:1299 #15 g_object_notify (object=0xa6e290, property_name=) at ../../../gobject/gobject.c:1347 #16 0xb6f9b9ec in got_time_tick (time_nanos=, bvw=bvw@entry=0xa6e290, play=) at ../src/backend/bacon-video-widget.c:2614 #17 0xb6f9ca02 in bvw_query_timeout (bvw=bvw@entry=0xa6e290) at ../src/backend/bacon-video-widget.c:2830 #18 0xb6fa0792 in bvw_bus_message_cb (bus=, message=, bvw=0xa6e290) at ../src/backend/bacon-video-widget.c:2485 #19 0xb6f2d2e8 in g_cclosure_marshal_VOID__BOXEDv (closure=0xaaf750, return_value=, instance=0x9f8bf0, args=..., marshal_data=0x0, n_params=1, param_types=0x7d1118) at ../../../gobject/gmarshal.c:1686 #20 0xb6f2b3d8 in _g_closure_invoke_va (closure=closure@entry=0xaaf750, return_value=0x0, instance=0x9f8bf0, instance@entry=0x0, args=..., args@entry=..., n_params=n_params@entry=1, param_types=0x7d1118) at ../../../gobject/gclosure.c:873 #21 0xb6f3cef6 in g_signal_emit_valist (instance=0x0, instance@entry=0x9f8bf0, signal_id=, detail=0, detail@entry=3204445364, var_args=..., var_args@entry=...) at ../../../gobject/gsignal.c:3404 #22 0xb6f3d0a2 in g_signal_emit (instance=instance@entry=0x9f8bf0, signal_id=, detail=289) at ../../../gobject/gsignal.c:3551 #23 0xb64b1420 in gst_bus_async_signal_func (bus=0x9f8bf0, message=0xa5405068, data=) at ../gst/gstbus.c:1295 #24 0xb64b2008 in gst_bus_source_dispatch (source=0xa8a388, callback=0xb64b13e5 , user_data=0x0) at ../gst/gstbus.c:851 #25 0xb6e6bf4c in g_main_dispatch (context=0x46e678) at ../../../glib/gmain.c:3325 #26 g_main_context_dispatch (context=context@entry=0x46e678) at ../../../glib/gmain.c:4043 #27 0xb6e6c1e0 in g_main_context_iterate (context=context@entry=0x46e678, block=block@entry=1, dispatch=dispatch@entry=1, self=) at ../../../glib/gmain.c:4119 #28 0xb6e6c25a in g_main_context_iteration (context=context@entry=0x46e678, may_block=may_block@entry=1) at ../../../glib/gmain.c:4184 #29 0xb6d990a6 in g_application_run (application=0x450140, argc=, argv=0xbefff754) at ../../../gio/gapplication.c:2559 #30 0x00401160 in main (argc=, argv=) at ../src/totem.c:83 [2] https://sources.debian.org/src/totem/3.38.0-2/src/totem-playlist.c/#L1790
Bug#986176: openuniverse runs with crippled GUI, then crashes.
Hello Ray,
from the "Code:" line you supplied I think the segfault happens
in create_cache_trans at ../src/mesa/state_tracker/st_cb_bitmap.c:402.
https://sources.debian.org/src/mesa/20.3.5-1/src/mesa/state_tracker/st_cb_bitmap.c/#L402
But I guess this information is not enough for the maintiner,
to find out what inputs causing the segfault in this function.
Maybe you could install systemd-coredump and deliver the
output of 'journalctl --no-pager' following the last segfault line,
that appears in dmesg too.
More details are in this link: https://wiki.debian.org/HowToGetABacktrace
Kind regards,
Bernhard
https://wiki.debian.org/InterpretingKernelOutputAtProcessCrash
From submitter:
[406058.660546] openuniverse[242638]: segfault at 20 ip 7f86f454ad63 sp
7ffefd7050a0 error 4 in nouveau_dri.so[7f86f4517000+d46000]
[406058.660565] Code: 48 48 89 c7 b9 02 00 00 00 ff 90 08 03 00 00 4c 8b 54 24
10 be ff 00 00 00 48 89 c7 49 89 82 70 12 00 00 49 8b 82 60 12 00 00 <8b> 50 20
c1 e2 05 e8 52 c9 fc ff 4c 8b 54 24 10 48 89 ea 4c 89 fe
"error 4" == 0b100
0: no page found
0: read access
1: user-mode access
echo -n "find /b ..., ..., 0x" && \
echo "48 48 89 c7 b9 02 00 00 00 ff 90 08 03 00 00 4c 8b 54 24 10 be ff 00 00
00 48 89 c7 49 89 82 70 12 00 00 49 8b 82 60 12 00 00 <8b> 50 20 c1 e2 05 e8 52
c9 fc ff 4c 8b 54 24 10 48 89 ea 4c 89 fe" \
| sed 's/[<>]//g' | sed 's/ /, 0x/g'
find /b ..., ..., 0x48, 0x48, 0x89, 0xc7, 0xb9, 0x02, 0x00, 0x00, 0x00, 0xff,
0x90, 0x08, 0x03, 0x00, 0x00, 0x4c, 0x8b, 0x54, 0x24, 0x10, 0xbe, 0xff, 0x00,
0x00, 0x00, 0x48, 0x89, 0xc7, 0x49, 0x89, 0x82, 0x70, 0x12, 0x00, 0x00, 0x49,
0x8b, 0x82, 0x60, 0x12, 0x00, 0x00, 0x8b, 0x50, 0x20, 0xc1, 0xe2, 0x05, 0xe8,
0x52, 0xc9, 0xfc, 0xff, 0x4c, 0x8b, 0x54, 0x24, 0x10, 0x48, 0x89, 0xea, 0x4c,
0x89, 0xfe
# single-use Bullseye/testing amd64 qemu VM 2021-04-14
echo "set enable-bracketed-paste off" >> /etc/inputrc; bash
apt update
# to speedup testing
mv /etc/manpath.config /etc/manpath.config.renamed
apt install libeatmydata1
export LD_PRELOAD=/usr/lib/$(uname -m)-linux-gnu/libeatmydata.so
apt dist-upgrade
apt install gdb libgl1-mesa-dri \
coreutils-dbgsym libgl1-mesa-dri-dbgsym
.
gdb -q
set width 0
set pagination off
file /bin/ls
tb main
run
call dlopen("/usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so",0x102)
info share
find /b 0x767c3160, 0x7750504e, 0x48, 0x48, 0x89, 0xc7, 0xb9,
0x02, 0x00, 0x00, 0x00, 0xff, 0x90, 0x08, 0x03, 0x00, 0x00, 0x4c, 0x8b, 0x54,
0x24, 0x10, 0xbe, 0xff, 0x00, 0x00, 0x00, 0x48, 0x89, 0xc7, 0x49, 0x89, 0x82,
0x70, 0x12, 0x00, 0x00, 0x49, 0x8b, 0x82, 0x60, 0x12, 0x00, 0x00, 0x8b, 0x50,
0x20, 0xc1, 0xe2, 0x05, 0xe8, 0x52, 0xc9, 0xfc, 0xff, 0x4c, 0x8b, 0x54, 0x24,
0x10, 0x48, 0x89, 0xea, 0x4c, 0x89, 0xfe
b * (0x767f3d39 + 42)
benutzer@debian:~$ gdb -q
(gdb) set width 0
(gdb) set pagination off
(gdb) file /bin/ls
Reading symbols from /bin/ls...
Reading symbols from
/usr/lib/debug/.build-id/64/61a544c35b9dc1d172d1a1c09043e487326966.debug...
(gdb) tb main
Temporary breakpoint 1 at 0x4760: file src/ls.c, line 1622.
(gdb) run
Starting program: /usr/bin/ls
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Temporary breakpoint 1, main (argc=1, argv=0x7fffe628) at src/ls.c:1622
1622src/ls.c: Datei oder Verzeichnis nicht gefunden.
(gdb) call dlopen("/usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so",0x102)
$1 = (void *) 0x5557a980
(gdb) find /b ..., ..., 0x48, 0x48, 0x89, 0xc7, 0xb9, 0x02, 0x00, 0x00, 0x00,
0xff, 0x90, 0x08, 0x03, 0x00, 0x00, 0x4c, 0x8b, 0x54, 0x24, 0x10, 0xbe, 0xff,
0x00, 0x00, 0x00, 0x48, 0x89, 0xc7, 0x49, 0x89, 0x82, 0x70, 0x12, 0x00, 0x00,
0x49, 0x8b, 0x82, 0x60, 0x12, 0x00, 0x00, 0x8b, 0x50, 0x20, 0xc1, 0xe2, 0x05,
0xe8, 0x52, 0xc9, 0xfc, 0xff, 0x4c, 0x8b, 0x54, 0x24, 0x10, 0x48, 0x89, 0xea,
0x4c, 0x89, 0xfe
A syntax error in expression, near `..., ..., 0x48, 0x48, 0x89, 0xc7, 0xb9,
0x02, 0x00, 0x00, 0x00, 0xff, 0x90, 0x08, 0x03, 0x00, 0x00, 0x4c, 0x8b, 0x54,
0x24, 0x10, 0xbe, 0xff, 0x00, 0x00, 0x00, 0x48, 0x89, 0xc7, 0x49, 0x89, 0x82,
0x70, 0x12, 0x00, 0x00, 0x49, 0x8b, 0x82, 0x60, 0x12, 0x00, 0x00, 0x8b, 0x50,
0x20, 0xc1, 0xe2, 0x05, 0xe8, 0x52, 0xc9, 0xfc, 0xff, 0x4c, 0x8b, 0x54, 0x24,
0x10, 0x48, 0x89, 0xea, 0x4c, 0x89, 0xfe'.
(gdb) info share
FromTo Syms Read Shared Object Library
...
0x767c3160 0x7750504e Yes
/usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so
...
(*): Shared library is missing debugging information.
(gdb) find /b 0x767c3160, 0x7750504e, 0x48, 0x48, 0x89, 0xc7,
0xb9, 0x02, 0x00, 0x00, 0x00, 0xff, 0x90, 0x08, 0x03, 0x00, 0x00, 0x4c, 0x8b,
0x54, 0x24, 0x10, 0xbe, 0xff, 0x00, 0x00, 0x00, 0x48, 0x89, 0xc7, 0x49, 0x89,
0x82, 0x70, 0x12, 0x00, 0x00, 0x49, 0x8b, 0x82, 0x60, 0x12, 0x00, 0x00, 0x8b,
0x50, 0x20, 0xc1, 0xe2, 0x05, 0xe8, 0x52, 0xc9, 0xfc,
Bug#986031: ogmrip crashes on startup with "malloc(): unsorted double linked list corrupted"
Dear Maintainer,
I tried to have a look and the segfault is really a result of the
previous g_param_spec_is_valid_name failures.
It looks like g_param_spec_is_valid_name got tightened lately to
not accept names with dashes anymore.
The following malloc corruption seems to originate in the backtrace below.
There the value pointer neither gets initialised, nor written to,
therefore the free fails.
Attached patch would replace thes "/" by "-" in the parameters
which get accepted by glib2.0.
I assume because of this issue this package is not usable at all,
therefore should be the severity increased?
Kind regards,
Bernhard
export MALLOC_CHECK_=3
(rr) bt
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1 0x7f11eae17537 in __GI_abort () at abort.c:79
#2 0x7f11eae70768 in __libc_message (action=action@entry=do_abort,
fmt=fmt@entry=0x7f11eaf7ee2d "%s\n") at ../sysdeps/posix/libc_fatal.c:155
#3 0x7f11eae77a5a in malloc_printerr (str=str@entry=0x7f11eaf7d05a "free():
invalid pointer") at malloc.c:5347
#4 0x7f11eae79ca6 in free_check (mem=0x55a02d91b8f0, caller=) at hooks.c:255
#5 0x55a02cd9ac41 in ogmrip_profiles_check_profile (section=0x55a02daae930
"/apps/ogmrip/profiles/default-avi", error=error@entry=0x0) at
ogmrip-profiles.c:155
#6 0x55a02cd9c7bf in ogmrip_profiles_dialog_add_profiles
(dialog=dialog@entry=0x55a02d9d4410, reload=reload@entry=0) at
ogmrip-profiles-dialog.c:157
#7 0x55a02cd9d0e5 in ogmrip_profiles_dialog_init (dialog=0x55a02d9d4410)
at ogmrip-profiles-dialog.c:733
#8 0x7f11eb11b391 in g_type_create_instance (type=) at
../../../gobject/gtype.c:1868
#9 0x7f11eb101615 in g_object_new_internal
(class=class@entry=0x55a02d92f430, params=params@entry=0x0,
n_params=n_params@entry=0) at ../../../gobject/gobject.c:1939
#10 0x7f11eb102b1d in g_object_new_with_properties
(object_type=94146449298656, n_properties=0, names=names@entry=0x0,
values=values@entry=0x0) at ../../../gobject/gobject.c:2107
#11 0x7f11eb1035f1 in g_object_new (object_type=,
first_property_name=first_property_name@entry=0x0) at ../../../gobject/gobject.c:1779
#12 0x55a02cd9d149 in ogmrip_profiles_dialog_new () at
ogmrip-profiles-dialog.c:741
#13 0x55a02cd8a21d in ogmrip_main_profiles_dialog_construct
(data=0x55a02d8a1b20) at ogmrip-main.c:1751
#14 main (argc=, argv=) at ogmrip-main.c:3215
Bug-Debian: https://bugs.debian.org/986031
Last-Update: 2021-04-11
--- ogmrip-1.0.1.orig/libogmrip-gtk/ogmrip-gconf-settings.c
+++ ogmrip-1.0.1/libogmrip-gtk/ogmrip-gconf-settings.c
@@ -63,10 +63,10 @@ my_gconf_concat_dir_and_key (const gchar
strcpy (retval, dir);
- if (dir[dirlen-1] == '/')
+ if (dir[dirlen-1] == '-')
{
/* dir ends in slash, strip key slash if needed */
-if (*key == '/')
+if (*key == '-')
++key;
strcpy (retval + dirlen, key);
@@ -76,9 +76,9 @@ my_gconf_concat_dir_and_key (const gchar
/* Dir doesn't end in slash, add slash if key lacks one. */
gchar* dest = retval + dirlen;
-if (*key != '/')
+if (*key != '-')
{
- *dest = '/';
+ *dest = '-';
++dest;
}
--- ogmrip-1.0.1.orig/libogmrip-gtk/ogmrip-lavc-options.c
+++ ogmrip-1.0.1/libogmrip-gtk/ogmrip-lavc-options.c
@@ -39,25 +39,25 @@
#define OGMRIP_IS_LAVC_DIALOG(obj) (G_TYPE_CHECK_INSTANCE_TYPE ((obj),
OGMRIP_TYPE_LAVC_DIALOG))
#define OGMRIP_IS_LAVC_DIALOG_CLASS(obj) (G_TYPE_CHECK_CLASS_TYPE ((klass),
OGMRIP_TYPE_LAVC_DIALOG))
-#define OGMRIP_LAVC_KEY_CMP OGMRIP_LAVC_SECTION "/"
OGMRIP_LAVC_PROP_CMP
-#define OGMRIP_LAVC_KEY_PRECMP OGMRIP_LAVC_SECTION "/"
OGMRIP_LAVC_PROP_PRECMP
-#define OGMRIP_LAVC_KEY_SUBCMP OGMRIP_LAVC_SECTION "/"
OGMRIP_LAVC_PROP_SUBCMP
-#define OGMRIP_LAVC_KEY_DIA OGMRIP_LAVC_SECTION "/"
OGMRIP_LAVC_PROP_DIA
-#define OGMRIP_LAVC_KEY_PREDIA OGMRIP_LAVC_SECTION "/"
OGMRIP_LAVC_PROP_PREDIA
-#define OGMRIP_LAVC_KEY_KEYINT OGMRIP_LAVC_SECTION "/"
OGMRIP_LAVC_PROP_KEYINT
-#define OGMRIP_LAVC_KEY_BUF_SIZEOGMRIP_LAVC_SECTION "/"
OGMRIP_LAVC_PROP_BUF_SIZE
-#define OGMRIP_LAVC_KEY_MIN_RATEOGMRIP_LAVC_SECTION "/"
OGMRIP_LAVC_PROP_MIN_RATE
-#define OGMRIP_LAVC_KEY_MAX_RATEOGMRIP_LAVC_SECTION "/"
OGMRIP_LAVC_PROP_MAX_RATE
-#define OGMRIP_LAVC_KEY_STRICT OGMRIP_LAVC_SECTION "/"
OGMRIP_LAVC_PROP_STRICT
-#define OGMRIP_LAVC_KEY_DC OGMRIP_LAVC_SECTION "/" OGMRIP_LAVC_PROP_DC
-#define OGMRIP_LAVC_KEY_MBD OGMRIP_LAVC_SECTION "/"
OGMRIP_LAVC_PROP_MBD
-#define OGMRIP_LAVC_KEY_QNS OGMRIP_LAVC_SECTION "/"
OGMRIP_LAVC_PROP_QNS
-#define OGMRIP_LAVC_KEY_VB_STRATEGY OGMRIP_LAVC_SECTION "/"
OGMRIP_LAVC_PROP_VB_STRATEGY
-#define OGMRIP_LAVC_KEY_LAST_PRED OGMRIP_LAVC_SECTION "/"
OGMRIP_LAVC_PROP_LAST_PRED
-#define OGMRIP_LAVC_KEY_PREME OGMRIP_LAVC_SECTION "/"
OGMRIP_LAVC_PROP_PREME
-#define OGMRIP_LAVC_KEY_VQCOMP OGMRIP_LAVC_SECTION "/"
OGMRIP_LAVC_PROP_VQCOMP
-#define
Bug#985989: nextcloud-desktop: segmentation fault when trying to open settings
Hello till, I tried to reproduce this inside a minimal VM, but the crash did not show for me. Maybe you could provide some more details, e.g. by installing systemd-coredump and inspecting the journal after a crash happened and adding the lines of the crash time to this bug. Please see more details in [1]. Kind regards, Bernhard [1] https://wiki.debian.org/HowToGetABacktrace
Bug#985994: kwin-x11: crashes randomly on ALT-TAB for switching between windows
Hello Russel, thank you for the detailed backtraces. Unfortunately they point into Qt's javascript module, finally trying to copy memory to a null pointer. I have not found a hint to similar crashes in upstream bug tracker. Could you please provide which theme you are using, or if there are maybe some third party extensions in use? Maybe you are aware of some not widely used settings that you changed, which might be related? Kind regards, Bernhard
Bug#984975: gedit 3.30.2-2 segmentation fault
Hello Nenad Cvetkovic, > Hi Bernhard Übelacker, > I hope I managed to create a proper backtrace, this is my first time. > > As for your question about rebuilt packages, I have no idea when this happened. I didn't build many things, I remember building ubuntu's Yaru theme. > > Thread 1 (Thread 0x7f7711e8ea80 (LWP 18322)): > #0 0x007f198f in () > #1 0x7f7715fee669 in g_main_context_prepare () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 > #2 0x7f7715fef06b in () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 > #3 0x7f7715fef25c in g_main_context_iteration () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 > #4 0x7f77171a5a2d in g_application_run () at /lib/x86_64-linux-gnu/libgio-2.0.so.0 > #5 0x55e52ad2d1fa in main () thank you for the backtrace, at least it is equal to what your core file generated in my test. I still guess this might be a manifestation of upstream bug [1]. Unfortunately this got closed as it could no longer be reproduced with at least gedit-3.30.2 and glib-2.60.6. Unfortunately in Buster/stable is glib-2.58.3 in use. Kind regards, Bernhard [1] https://gitlab.gnome.org/GNOME/gedit/-/issues/51
Bug#985402: libgconf-2-4: found segmentation fault
Hello Antonio, this directory should contain a file: /etc/gconf/2/path The content should most probably what is shown here: https://sources.debian.org/src/gconf/3.2.6-7/debian/default.path/ (And can be downloaded in the upper right corner.) Kind regards, Bernhard Am 09.04.21 um 15:26 schrieb Antonio: The path "/etc/gconf/2" is empty: totale 8 drwxr-xr-x 2 root root 4096 1 mar 15.36 . drwxr-xr-x 6 root root 4096 1 mar 15.36 .. However, even if I remove it or remove "/etc/gconf" occurs the same problem. I note if I remove the entire directory "usr/share/GConf/gsettings" then the bug does not occur, but it does not seem to be related to a specific file: just remains one file that the problem returns.
Bug#985994: kwin-x11: crashes randomly on ALT-TAB for switching between windows
Hello Russel, thanks for the fast answer, unfortunately the backtrace is not yet enough expressive. Maybe you could also install the following debug symbol packages? libqt5qml5-dbgsym libqt5core5a-dbgsym libqt5widgets5-dbgsym libqt5gui5-dbgsym kwin-common-dbgsym kwin-x11-dbgsym These are located in a separate debug symbol repository, which has to be enabled first and is described here: https://wiki.debian.org/HowToGetABacktrace#Installing_the_debugging_symbols Kind regards, Bernhard [KCrash Handler] #4 0x7f42259bee08 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Qml.so.5 #5 0x7f4225acd3cc in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Qml.so.5 #6 0x001e0009 in ?? () #7 0x55623023d9d0 in ?? () #8 0x7f421a2d in ?? () #9 0x556230c214a0 in ?? ()
Bug#985197: kwin-wayland: Drag and drop a file in Dolphin makes KDE Plasma Wayland crash
Hello Silvério, Reading symbols from /usr/bin/kwin_wayland... (No debugging symbols found in /usr/bin/kwin_wayland) BFD: warning: /tmp/user/1000/coredump-ySV5m6 is truncated: expected core file size >= 2365169664, found: 2147483648 it looks like for some reason the kwin_wayland exceeds the address space limit of systemd-coredump, therefore the results are not good. If you want to give it another try, then please uncomment and raise this limit from e.g. 2GB to 3GB like this: /etc/systemd/coredump.conf ... ProcessSizeMax=3G ExternalSizeMax=3G ... systemctl daemon-reload Then the size warning hopefully goes away on the next attempt, and a better backtrace might be printed. Kind regards, Bernhard
Bug#985402: libgconf-2-4: found segmentation fault
Hello Antonio, thank you for the detailed informations. Am 01.04.21 um 19:15 schrieb Antonio: $ gdb gsettings-data-convert Starting program: /usr/bin/gsettings-data-convert (gsettings-data-convert:4756): GConf-CRITICAL **: 19:00:31.514: gconf_engine_get_local_for_addresses: assertion 'addresses != NULL' failed I guess the above line is causing the issue, which results in "client->engine" being a null pointer [1] [2]. The interesting function for the addresses seems to be get_writable_client [3]. It looks like upstream applied a patch to exit the process immediately in the case of addresses being a null pointer. Therefore is just the question left why get_writable_source_path/gconf_load_source_path returns a null pointer... Which leads to the question what the content of this path might be: /etc/gconf/2 Kind regards, Bernhard Thread 1 "gsettings-data-" received signal SIGSEGV, Segmentation fault. gconf_engine_get_entry (conf=0x0, key=key@entry=0x555917d0 "/system/pulseaudio/modules/combine/args0", locale=0x77b70b6e <_nl_C_name> "C", use_schema_default=use_schema_default@entry=1, err=err@entry=0x7fffde60) at gconf-dbus.c:1293 1293 gconf-dbus.c: File o directory non esistente. (gdb) bt #0 gconf_engine_get_entry (conf=0x0, key=key@entry=0x555917d0 "/system/pulseaudio/modules/combine/args0", locale=0x77b70b6e <_nl_C_name> "C", use_schema_default=use_schema_default@entry=1, err=err@entry=0x7fffde60) at gconf-dbus.c:1293 #1 0x77f4d7a6 in get (client=client@entry=0xd2a0, key=0x555917d0 "/system/pulseaudio/modules/combine/args0", use_default=0, error=error@entry=0x7fffde60) at gconf-client.c:1493 #2 0x77f4ee93 in gconf_client_get_full (client=client@entry=0xd2a0, key=key@entry=0x555917d0 "/system/pulseaudio/modules/combine/args0", use_schema_default=use_schema_default@entry=0, err=err@entry=0x7fffdef8, locale=0x0) at gconf-client.c:1543 #3 0x77f4efbf in gconf_client_get_without_default (client=client@entry=0xd2a0, key=key@entry=0x555917d0 "/system/pulseaudio/modules/combine/args0", err=err@entry=0x7fffdef8) at gconf-client.c:1605 #4 0x715d in handle_file (filename=filename@entry=0x5556b490 "/usr/share/GConf/gsettings/pulseaudio.convert") at gsettings-data-convert.c:214 #5 0x6912 in handle_dir (converted=0xc980, stored_mtime=0, dirname=0x5556a3e0 "/usr/share/GConf/gsettings") at gsettings-data-convert.c:436 #6 main (argc=, argv=) at gsettings-data-convert.c:670 [1] https://gitlab.gnome.org/Archive/gconf/-/blob/master/gconf/gconf-dbus.c#L1293 [2] https://gitlab.gnome.org/Archive/gconf/-/blob/master/gconf/gconf-client.c#L1491 [3] https://gitlab.gnome.org/Archive/gconf/-/blob/master/gsettings/gsettings-data-convert.c#L98 [4] https://gitlab.gnome.org/Archive/gconf/-/commit/98ff7acca7595f508b094506195aeffaf2e8b74c
Bug#985994: kwin-x11: crashes randomly on ALT-TAB for switching between windows
Hello Russell, could you still see this issue? Stack trace of thread 120123: #0 0x7f49c3823ce1 n/a (/lib/x86_64-linux-gnu/libc-2.31.so (deleted) + 0x3bce1) Were there more lines following in the "Stack trace of thread 120123"? And as libc-2.31 is shown as deleted, I assume this happened while libc package got updated while the kwin-x11 process was still using the previous version. Kind regards, Bernhard
Bug#985820: python3-cryptography: Core dump in buster openssl binding
Hello Markus, I tried to fill in the symbol information that were missing in the above backtrace by using the available dbgsym packages python3-cryptography-dbgsym and libssl1.1-dbgsym. With these installed your gdb would show line information too [3]. I found following ticket [2] that shows in later entries similarities to the given backtrace. Further running the server with valgrind might show something related, if the crash happens there too. Kind regards, Bernhard [1] ... #4 0x...42c in _int_free at malloc.c:4165 #5 0x...9be in SSL_SESSION_free at ../ssl/ssl_sess.c:765 #6 0x...c8c in doall_util_fn at ../crypto/lhash/lhash.c:196 #7 0x...f57 in lh_SSL_SESSION_doall_TIMEOUT_PARAM at ../ssl/ssl_sess.c:1082 #8 0x...4d3 in tls_finish_handshake at ../ssl/statem/statem_lib.c:1075 #9 0x...e3e in state_machine / write_state_machine at ../ssl/statem/statem.c:810 #10 0x...f34 in SSL_do_handshake at ../ssl/ssl_lib.c:3607 #11 0x...71c in _cffi_f_SSL_do_handshake at build/temp.linux-amd64-3.7/_openssl.c:38289 ... [2] https://twistedmatrix.com/trac/ticket/9764 [3] https://wiki.debian.org/HowToGetABacktrace
Bug#967941: nautilus: fails to generate thumbnails for h264 encoded video files
Dear Maintainer, I wondered why the first two allocators would fail and tried to step into. At least the alloc_malloc seems to use the regular glibc-malloc, and should succeed therefore [1]? So might there be a size restriction in place how much memory totem-video-thumbnailer is allowed to allocate. Because each of these threads seems to try to allocate 128 MB, but malloc returns 0. And such a totem-video-thumbnailer process seems to contain many threads [2]. (One for each core?) Kind regards, Bernhard [1] (gdb) bt #0 0x779390f7 in __GI___libc_malloc (bytes=134221824) at malloc.c:3023 #1 0x7fffce1331de in alloc_malloc (address=) at memory.c:2290 #2 0x7fffce133709 in blas_memory_alloc (procpos=procpos@entry=2) at memory.c:2793 Thread 8 "matroskademux0:" hit Breakpoint 4, alloc_malloc (address=0x0) at memory.c:2290 2290 map_address = (void *)malloc(BUFFER_SIZE + FIXED_PAGESIZE); [2] ... 6Thread 0x71ef0700 (LWP 3797) "matroskademux0:" libc_feholdsetround_sse_ctx (r=0, ctx=) at ../sysdeps/x86/fpu/fenv_private.h:416 7Thread 0x716ef700 (LWP 3798) "multiqueue0:src" syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 8Thread 0x7fffcd877700 (LWP 3799) "matroskademux0:" 0x77993fa7 in sched_yield () at ../sysdeps/unix/syscall-template.S:120 * 9Thread 0x7fffcd076700 (LWP 3800) "matroskademux0:" 0x in ?? () 10 Thread 0x7fffcc875700 (LWP 3801) "matroskademux0:" 0x77993fa7 in sched_yield () at ../sysdeps/unix/syscall-template.S:120 11 Thread 0x7fffcc074700 (LWP 3802) "matroskademux0:" 0x7fffce133707 in blas_memory_alloc (procpos=procpos@entry=2) at memory.c:2793 12 Thread 0x7fffcb873700 (LWP 3803) "matroskademux0:" 0x7fffce133707 in blas_memory_alloc (procpos=procpos@entry=2) at memory.c:2793 13 Thread 0x7fffcb072700 (LWP 3804) "matroskademux0:" 0x7fffce133707 in blas_memory_alloc (procpos=procpos@entry=2) at memory.c:2793 14 Thread 0x7fffca871700 (LWP 3805) "matroskademux0:" 0x7fffce133707 in blas_memory_alloc (procpos=procpos@entry=2) at memory.c:2793 15 Thread 0x7fffc2070700 (LWP 3806) "matroskademux0:" 0x7fffce133707 in blas_memory_alloc (procpos=procpos@entry=2) at memory.c:2793 16 Thread 0x7fffc186f700 (LWP 3807) "matroskademux0:" alloc_malloc (address=0x0) at memory.c:2290 17 Thread 0x7fffb906e700 (LWP 3808) "matroskademux0:" alloc_malloc (address=0x0) at memory.c:2290 18 Thread 0x7fffb886d700 (LWP 3809) "matroskademux0:" alloc_malloc (address=0x0) at memory.c:2290 19 Thread 0x7fffb806c700 (LWP 3810) "matroskademux0:" alloc_malloc (address=0x0) at memory.c:2290 20 Thread 0x7fffb786b700 (LWP 3811) "matroskademux0:" alloc_malloc (address=0x0) at memory.c:2290 21 Thread 0x7fffb706a700 (LWP 3812) "matroskademux0:" 0x7fffce133707 in blas_memory_alloc (procpos=procpos@entry=2) at memory.c:2793 22 Thread 0x7fffb6869700 (LWP 3813) "matroskademux0:" 0x7fffce133707 in blas_memory_alloc (procpos=procpos@entry=2) at memory.c:2793
Bug#985473: slic3r: symbol lookup error after gcode export
Hello Gregor, I am not sure if my last mail reached you. [1] There I did not notice a line for libboost_nowide in ldd output. Also I tested by the last two modifications which made XS.so to be linked to libboost_nowide and made slic3r not fail with the unknown symbol error. Kind regards, Bernhard [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=985473#20
Bug#967941: nautilus: fails to generate thumbnails for h264 encoded video files
Dear Maintainer,
I was trying to collect some more information for bug #973811.
There it looks like openblas does its own memory management seems
therefore affected by some sandboxing disallowing a SYS_bind syscall.
With the test VM I used there I get with current testing this
output for a manually created test mkv with h264 video the
following output.
This is now kind of different, but might be caused by some
new package versions since last October.
Therefore I am not sure if this is really what I observe.
It seems like openblas tries the allocators in variable memoryalloc,
and if no one works calls the terminating null pointer with
the current version.
Kind regards,
Bernhard
# ffmpeg -f lavfi -i testsrc=duration=10:size=1280x720:rate=30 -vcodec h264
-acodec libvorbis output.mkv
benutzer@debian:~$ totem-video-thumbnailer -v output.mkv tmp.png
TotemVideoThumbnailer-Message: 17:37:58.702: Initialised libraries, about to
create video widget
TotemVideoThumbnailer-Message: 17:37:58.710: setting URI
file:///home/benutzer/output.mkv
TotemVideoThumbnailer-Message: 17:37:58.710: Video widget created
TotemVideoThumbnailer-Message: 17:37:58.710: About to open video file
OpenBLAS blas_thread_init: pthread_create failed for thread 6 of 16: Die
Ressource ist zur Zeit nicht verfügbar
OpenBLAS blas_thread_init: RLIMIT_NPROC 11759 current, 11759 max
Speicherzugriffsfehler (Speicherabzug geschrieben)
benutzer@debian:~$ coredumpctl -q list
TIMEPID UID GID SIG COREFILE EXE
Wed 2021-04-07 17:37:59 CEST 3087 1000 1000 11 present
/usr/bin/totem-video-thumbnailer
benutzer@debian:~$ coredumpctl -q gdb 3087
PID: 3087 (totem-video-thu)
UID: 1000 (benutzer)
GID: 1000 (benutzer)
Signal: 11 (SEGV)
Timestamp: Wed 2021-04-07 17:37:58 CEST (7min ago)
Command Line: totem-video-thumbnailer -v output.mkv tmp.png
Executable: /usr/bin/totem-video-thumbnailer
Control Group: /user.slice/user-1000.slice/session-8.scope
Unit: session-8.scope
Slice: user-1000.slice
Session: 8
Owner UID: 1000 (benutzer)
Boot ID: 505eeb0b4fe548338077ab20802215cc
Machine ID: 33f18f39d2a9438eb75b0ed52848afcd
Hostname: debian
Storage:
/var/lib/systemd/coredump/core.totem-video-thu.1000.505eeb0b4fe548338077ab20802215cc.3087.161780987800.zst
Message: Process 3087 (totem-video-thu) of user 1000 dumped core.
Stack trace of thread 3096:
#0 0x n/a (n/a + 0x0)
...
Core was generated by `totem-video-thumbnailer -v output.mkv tmp.png'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x in ?? ()
[Current thread is 1 (Thread 0x7f4ab3aa6700 (LWP 3096))]
(gdb) bt
#0 0x in ()
#1 0x7f4ab5364709 in blas_memory_alloc (procpos=procpos@entry=2) at
memory.c:2793
#2 0x7f4ab5364f04 in blas_thread_server (arg=) at
blas_server.c:366
#3 0x7f4ade5deea7 in start_thread (arg=) at
pthread_create.c:477
#4 0x7f4adebdadef in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:95
(gdb) cd
/home/benutzer/source/libopenblas0-pthread/orig/openblas-0.3.13+ds/driver/others
Working directory
/home/benutzer/source/libopenblas0-pthread/orig/openblas-0.3.13+ds/driver/others.
(gdb) up
#1 0x7f4ab5364709 in blas_memory_alloc (procpos=procpos@entry=2) at
memory.c:2793
2793map_address = (*func)((void *)base_address);
(gdb) print memoryalloc
$1 = {0x7f4ab5364230 , 0x7f4ab53641d0 , 0x0}
Bug#973811: tracker-miners sandbox
Hello Roderich, I looked a little around and found Debian bug #967941. There the media file is a video file that led to loading libopenblas.so. This seems to be caused by the file gstreamer-1.0/libgstlibav.so. I could reproduce it now within a VM with current testing. By creating a mkv video container containing dummy h264 video. This made tracker-extract crash with the same backtrace. Details creating the test video file and some more details in attached file. Kind regards, Bernhard # single-use Bullseye/testing amd64 qemu VM 2021-04-07 echo "set enable-bracketed-paste off" >> /etc/inputrc; bash apt update # to speedup testing mv /etc/manpath.config /etc/manpath.config.renamed apt install libeatmydata1 export LD_PRELOAD=/usr/lib/$(uname -m)-linux-gnu/libeatmydata.so apt dist-upgrade apt install systemd-coredump gnome gdb tracker-extract libopenblas0-pthread totem mediainfo youtube-dl \ tracker-extract-dbgsym libopenblas0-pthread-dbgsym apt build-dep tracker-extract reboot mkdir /home/benutzer/source/libopenblas0-pthread/orig -p cd/home/benutzer/source/libopenblas0-pthread/orig apt source libopenblas0-pthread cd ffmpeg -f lavfi -i testsrc=duration=10:size=1280x720:rate=30 -vcodec h264 -acodec libvorbis output.mkv benutzer@debian:~$ mediainfo output.mkv General Unique ID: 86504292601449332751262688530610519286 (0x41141EE912C532EEC70F1D7D7877FCF6) Complete name: output.mkv Format : Matroska Format version : Version 4 File size: 118 KiB Duration : 10 s 0 ms Overall bit rate : 96.8 kb/s Writing application : Lavf58.45.100 Writing library : Lavf58.45.100 ErrorDetectionType : Per level 1 Video ID : 1 Format : AVC Format/Info : Advanced Video Codec Format profile : High 4:4:4 Predictive@L3.1 Format settings : CABAC / 4 Ref Frames Format settings, CABAC : Yes Format settings, Reference frames: 4 frames Codec ID : V_MPEG4/ISO/AVC Duration : 10 s 0 ms Bit rate : 94.9 kb/s Width: 1 280 pixels Height : 720 pixels Display aspect ratio : 16:9 Frame rate mode : Constant Frame rate : 30.000 FPS Chroma subsampling : 4:4:4 Bit depth: 8 bits Scan type: Progressive Bits/(Pixel*Frame) : 0.003 Stream size : 116 KiB (98%) Writing library : x264 core 160 r3011 cde9a93 Encoding settings: cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x3:0x113 / me=hex / subme=7 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=4 / threads=22 / lookahead_threads=3 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=crf / mbtree=1 / crf=23.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00 Default : Yes Forced : No journalctl --user -e: Apr 07 17:17:04 debian systemd[1093]: Starting Tracker metadata extractor... Apr 07 17:17:04 debian tracker-extract[2304]: Set scheduler policy to SCHED_IDLE Apr 07 17:17:04 debian tracker-extract[2304]: Setting priority nice level to 19 Apr 07 17:17:04 debian dbus-daemon[1120]: [session uid=1000 pid=1120] Successfully activated service 'org.freedesktop.Tracker1.Miner.Extract' Apr 07 17:17:04 debian systemd[1093]: Started Tracker metadata extractor. Apr 07 17:17:05 debian systemd-coredump[2328]: Process 2304 (tracker-extract) of user 1000 dumped core. Stack trace of thread 2324: #0 0x7f6dd97b89b9 syscall (libc.so.6 + 0xf89b9) #1 0x7f6d73b902ce my_mbind (libopenblas.so.0 + 0x34a2ce) #2 0x7f6d73b90709 blas_memory_alloc (libopenblas.so.0 + 0x34a709) #3 0x7f6d73b90f04 blas_thread_server
Bug#986570: ddrutility: ddru_findbad fails if fdisk output uses translated strings (ddru_findbad: 1027: arithmetic expression: expecting primary)
Package: ddrutility Version: 2.8-1.1 Severity: normal X-Debbugs-Cc: bernha...@mailbox.org Dear Maintainer, I found on some attempts to use ddru_findbad are failing for me like this: ... /usr/bin/ddru_findbad: 1027: arithmetic expression: expecting primary: " (300-/dev/loop0:) " I used as a workaround a "export LANG=C" before using it. Now I found some more time to report it. The issue shows when package util-linux-locales is installed and fdisk outputs something different than "Disk" in the column header. A minimal improvement might be this: /usr/bin/ddru_findbad:1027 -$GFDISK -lu "$TARGET" | grep -a "$TARGET" | grep -a -v Disk > tempddrfdisk +LANG=C $GFDISK -lu "$TARGET" | grep -a "$TARGET" | grep -a -v Disk > tempddrfdisk Kind regards, Bernhard -- System Information: Debian Release: bullseye/sid APT prefers testing-security APT policy: (500, 'testing-security'), (500, 'testing-debug'), (500, 'proposed-updates-debug'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-5-amd64 (SMP w/16 CPU threads) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages ddrutility depends on: ii fdisk 2.36.1-7 ii libc6 2.31-11 ii ntfs-3g1:2017.3.23AR.3-4 ii sleuthkit 4.10.1+dfsg-1 ddrutility recommends no packages. ddrutility suggests no packages. -- no debconf information Thank you for using reportbug # single-use Bullseye/testing amd64 qemu VM 2021-04-07 echo "set enable-bracketed-paste off" >> /etc/inputrc; bash apt update apt dist-upgrade apt install mc gdb gddrescue ddrutility util-linux-locales fdisk-dbgsym apt build-dep fdisk mkdir /home/benutzer/source/fdisk/orig -p cd/home/benutzer/source/fdisk/orig apt source fdisk cd mkdir /home/benutzer/source/glibc/orig -p cd/home/benutzer/source/glibc/orig apt source glibc cd truncate --size=300M test.img fdisk test.img # create primary Linux partition losetup -P /dev/loop0 test.img mkfs.ext4 /dev/loop0p1 mount /dev/loop0p1 /mnt dd if=/dev/zero of=/mnt/testfile bs=1M umount /mnt ddrescue /dev/loop0 ddrescue.img ddrescue.log losetup -d /dev/loop0 cat < ddrescue-fake.log # Mapfile. Created by GNU ddrescue version 1.23 # Command line: ddrescue /dev/loop0 ddrescue.img ddrescue.log # Start time: 2021-04-07 15:33:00 # Current time: 2021-04-07 15:33:01 # Finished # current_pos current_status current_pass 0x12BF + 1 # possize status 0x 0x0486 + 0x0486 0x4000 - 0x04864000 0x12C0 + EOF bash mkdir try1; cd try1 echo $LANG ddru_findbad ../ddrescue.img ../ddrescue-fake.log fdisk -lu ../ddrescue.img | grep ../ddrescue.img exit root@debian:~# bash root@debian:~# mkdir try1 root@debian:~# cdtry1 root@debian:~/try1# echo $LANG de_DE.UTF-8 root@debian:~/try1# ddru_findbad ../ddrescue.img ../ddrescue-fake.log Command line input was processed succesfully ddru_findbad 1.11 20141015 Waring! GNU fdisk is not detected! Therefore GPT partitioned disks will not be able to be processed and this script may produce errors if trying to do so. See help file for more info. Target = ../ddrescue.img Logfile = ../ddrescue-fake.log Output base name = results Sector size = 512 Loop wait time = 2 More info = false Extra output = false Quick = false Quick ntfs = false Target ../ddrescue.img is detected to be a file Target ../ddrescue.img is found to be a whole dos partitioned disk Processing ddrescue log file 0x0486 0x4000 - 148224 148255 Checking Festplatte /usr/bin/ddru_findbad: 1027: arithmetic expression: expecting primary: " (300-/dev/loop0:) " root@debian:~/try1# fdisk -lu ../ddrescue.img | grep ../ddrescue.img Festplatte ../ddrescue.img: 300 MiB, 314572800 Bytes, 614400 Sektoren ../ddrescue.img12048 614399 612352 299M 83 Linux root@debian:~/try1# exit bash mkdir try2; cd try2 export LANG=C echo $LANG ddru_findbad ../ddrescue.img ../ddrescue-fake.log fdisk -lu ../ddrescue.img | grep ../ddrescue.img exit root@debian:~# bash root@debian:~# mkdir try2; cd try2 root@debian:~/try2# export LANG=C root@debian:~/try2# echo $LANG C root@debian:~/try2# ddru_findbad ../ddrescue.img ../ddrescue-fake.log Command line input was processed succesfully ddru_findbad 1.11 20141015 Waring! GNU fdisk is not detected! Therefore GPT partitioned disks will not be able to be processed and this script may produce errors if trying to do so. See help file for more info. Target = ../ddrescue.img Logfile = ../ddrescue-fake.log Output base name = results Sector size = 512 Loop wait time = 2 More info = false Extra output = false Quick = false Quick ntfs = false Target ../ddrescue.img is detected to be a file Existing loop linked to target found, deleting /dev/loop0 Target ../ddrescue.img is found to be a whole dos partitioned disk Processing ddrescue log file 0x0486
Bug#985473: slic3r: symbol lookup error after gcode export
Hello Joe,
thanks for the backtrace. It enabled me to reproduce it.
You have configured a post processing step in your printer settings?
Then this setenv function is tried to be located in the loaded
shared objects. Unfortunately Slic3r/XS/XS.so does not show to be
linked to libboost_nowide.so, where the missing symbols seems to be.
With the 2 lines changed at the bottom of this mail,
ldd XS.so shows also a line for libboost_nowide.so,
therefore it gets loaded automatically by the dynamic loader
and symbol resolution should find it.
A package build with it shows then a correct error message
about my missing post processing file.
The given upstream commit contain similar changes.
Kind regards,
Bernhard
Thread 144 "perl" hit Breakpoint 6, _dl_lookup_symbol_x (undef_name=0x7729ee71
"_ZN5boost6nowide6setenvEPKcS2_i", undef_map=0x55d7a970,
ref=ref@entry=0x7fff527fb578, symbol_scope=0x55d7acd8, version=0x0,
type_class=type_class@entry=1, flags=5, skip_map=0x0) at dl-lookup.c:878
878 _dl_exception_create_format
1: x/i $pc
=> 0x77fdce9b <_dl_lookup_symbol_x+731>:test %dl,%dl
(gdb) bt
#0 _dl_lookup_symbol_x (undef_name=0x7729ee71
"_ZN5boost6nowide6setenvEPKcS2_i", undef_map=0x55d7a970,
ref=ref@entry=0x7fff527fb578, symbol_scope=0x55d7acd8, version=0x0,
type_class=type_class@entry=1, flags=5, skip_map=0x0) at dl-lookup.c:878
#1 0x77fe1623 in _dl_fixup (l=, reloc_arg=) at ../elf/dl-runtime.c:112
#2 0x77fe8503 in _dl_runtime_resolve_fxsave () at
../sysdeps/x86_64/dl-trampoline.h:126
#3 0x775c42f9 in Slic3r::ConfigBase::setenv_ (this=0x58a8da88) at
/usr/include/c++/10/bits/basic_string.h:186
#4 0x774966b6 in XS_Slic3r__Config__Static_setenv (my_perl=, cv=) at /usr/bin/perl -MExtUtils::XSpp::Cmd -e xspp -- -t "../xsp/typemap.xspt"
"../xsp/Config.xsp":479
#5 0x55665047 in Perl_pp_entersub ()
#6 0x5565b736 in Perl_runops_standard ()
#7 0x555c0c44 in Perl_call_sv ()
#8 0x7792c52a in ?? () from
/usr/lib/x86_64-linux-gnu/perl/5.32/auto/threads/threads.so
#9 0x7792df6d in ?? () from
/usr/lib/x86_64-linux-gnu/perl/5.32/auto/threads/threads.so
#10 0x77e58ea7 in start_thread (arg=) at
pthread_create.c:477
#11 0x77d88def in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:95
(gdb) list
873 const char *versionstr = version ? ", version " : "";
874 const char *versionname = (version && version->name
875 ? version->name : "");
876 struct dl_exception exception;
877 /* XXX We cannot translate the message. */
878 _dl_exception_create_format
879 (, DSO_FILENAME (reference_name),
880 "undefined symbol: %s%s%s",
881 undef_name, versionstr, versionname);
882 _dl_signal_cexception (0, , N_("symbol lookup
error"));
./lib/Slic3r/Print.pm
146 # run post-processing scripts
147 if (@{$self->config->post_process}) {
148 $self->status_cb->(95, "Running post-processing scripts");
149 $self->config->setenv;
150 for my $script (@{$self->config->post_process}) {
$ ldd /usr/lib/slic3r/auto/Slic3r/XS/XS.so
...
libboost_thread.so.1.74.0 =>
/lib/x86_64-linux-gnu/libboost_thread.so.1.74.0 (0x7fd9184fd000)
libboost_filesystem.so.1.74.0 =>
/lib/x86_64-linux-gnu/libboost_filesystem.so.1.74.0 (0x7fd9184db000)
...
(libboost_nowide.so is not listed)
+++ slic3r-1.3.0+dfsg1/src/CMakeLists.txt
-find_package(Boost COMPONENTS system thread filesystem)
+find_package(Boost COMPONENTS system thread filesystem nowide)
+++ slic3r-1.3.0+dfsg1/xs/Build.PL
-my @boost_libraries = qw(system thread filesystem); # we need these
+my @boost_libraries = qw(system thread filesystem nowide); # we need these
https://github.com/slic3r/Slic3r/commit/89018b6e02e9d3fda30602cb4cf48f7750ace7b5
Bug#973552: xserver-xorg-video-amdgpu: GPU crashed while doing screencast using ffmpeg with gsequencer
Hello Joël, I guess I have a similar setup and had similar lock-ups as your video shows. I had opened this upstream bug [1]. Either with latest bios updates the situation improved, or last year I started to do after each cold boot another warm boot and have the feeling that way this issue does occur a lot less to not at all. Could you still reproduce this issue - and does it show after a reboot too? Kind regards, Bernhard [1] https://gitlab.freedesktop.org/mesa/mesa/-/issues/1293
Bug#973811: crashes /usr/libexec/tracker-extract with signal SIGSYS, Bad system call.
Dear Maintainer, I tried to fill the gaps in the given backtrace with the matching dbgsym packages, see below. Might this be a kind of sandbox, not allowing to allocate memory the way libopenblas.so does/did? Kind regards, Bernhard #0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 #1 0x7295196e in my_mbind at ../../common_linux.h:87 #2 0x72951da9 in blas_memory_alloc at memory.c:2793 #3 0x729525a4 in blas_thread_server at blas_server.c:366 #4 0x77b1bea7 in start_thread (arg=) at pthread_create.c:477 #5 0x77a4bd4f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 # 0.3.12+ds-2 not available anymore, looking at 0.3.13+ds-2 https://sources.debian.org/src/openblas/0.3.13+ds-2/driver/others/memory.c/?hl=2925#L2793 https://sources.debian.org/src/openblas/0.3.13+ds-2/driver/others/blas_server.c/?hl=366#L366 https://sources.debian.org/src/openblas/0.3.13+ds-2/common_linux.h/#L80
Bug#986332: lsattr on certiain files in /dev results in "stack smashing detected"
Hello Chris, Am 04.04.21 um 22:33 schrieb Chris Hofstaedtler: Hello Bernhard, Marc, Some more questions: 1) which kernel version is this? My test was just inside a temporary VM with current testing. But I can still reproduce this with current testing kernel at the host too: Linux rechner 5.10.0-5-amd64 #1 SMP Debian 5.10.24-1 (2021-03-19) x86_64 GNU/Linux 2) /dev/dri is on tmpfs? bernhard@rechner:~$ mount udev on /dev type devtmpfs (rw,nosuid,noexec,relatime,size=8075552k,nr_inodes=201,mode=755) ... Kind regards, Bernhard
Bug#986332: lsattr on certiain files in /dev results in "stack smashing detected"
Dear Maintainer, tried to locate the exact smashing. It looks like the ioctl(EXT2_IOC_GETFLAGS) takes an int* parameter, but writes 8 bytes instead of just sizeof(int) to the given address. Kind regards, Bernhard Old value = (void *) 0xf759b62c03711000 New value = (void *) 0xf759b62c 0x77ec0cc7 in ioctl () at ../sysdeps/unix/syscall-template.S:120 120 ../sysdeps/unix/syscall-template.S: Datei oder Verzeichnis nicht gefunden. 1: x/i $pc => 0x77ec0cc7 :cmp$0xf001,%rax (gdb) bt #0 0x77ec0cc7 in ioctl () at ../sysdeps/unix/syscall-template.S:120 #1 0x77fbcb17 in fgetflags (name=name@entry=0x7fffe83f "/dev/dri/card0", flags=flags@entry=0x7fffe3e0) at ../../../../lib/e2p/fgetflags.c:90 #2 0x54d5 in list_attributes (name=name@entry=0x7fffe83f "/dev/dri/card0") at ../../../misc/lsattr.c:85 #3 0x56c9 in lsattr_args (name=0x7fffe83f "/dev/dri/card0") at ../../../misc/lsattr.c:134 #4 0x5369 in main (argc=, argv=) at ../../../misc/lsattr.c:221 https://sources.debian.org/src/e2fsprogs/1.46.2-1/lib/e2p/fgetflags.c/#L90 https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/tree/lib/e2p/fgetflags.c#n90 # single-use Bullseye/testing amd64 qemu VM 2021-04-04 echo "set enable-bracketed-paste off" >> /etc/inputrc; bash apt update # to speedup testing mv /etc/manpath.config /etc/manpath.config.renamed apt install libeatmydata1 export LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libeatmydata.so apt dist-upgrade apt install systemd-coredump gdb valgrind \ e2fsprogs-dbgsym libext2fs2-dbgsym . benutzer@debian:~$ lsattr /dev/dri/card0 *** stack smashing detected ***: terminated Abgebrochen (Speicherabzug geschrieben) root@debian:~# coredumpctl list TIMEPID UID GID SIG COREFILE EXE Sun 2021-04-04 14:22:59 CEST 1921 1000 1000 6 present /usr/bin/lsattr root@debian:~# coredumpctl gdb 1921 PID: 1921 (lsattr) UID: 1000 (benutzer) GID: 1000 (benutzer) Signal: 6 (ABRT) Timestamp: Sun 2021-04-04 14:22:59 CEST (50s ago) Command Line: lsattr /dev/dri/card0 Executable: /usr/bin/lsattr Control Group: /user.slice/user-1000.slice/session-3.scope Unit: session-3.scope Slice: user-1000.slice Session: 3 Owner UID: 1000 (benutzer) Boot ID: de580d9e15564f17b195ec068c7129dc Machine ID: 33f18f39d2a9438eb75b0ed52848afcd Hostname: debian Storage: /var/lib/systemd/coredump/core.lsattr.1000.de580d9e15564f17b195ec068c7129dc.1921.161753897900.zst Message: Process 1921 (lsattr) of user 1000 dumped core. Stack trace of thread 1921: #0 0x7f7ea4286ce1 __GI_raise (libc.so.6 + 0x3bce1) #1 0x7f7ea4270537 __GI_abort (libc.so.6 + 0x25537) #2 0x7f7ea42c9768 __libc_message (libc.so.6 + 0x7e768) #3 0x7f7ea4358652 __GI___fortify_fail (libc.so.6 + 0x10d652) #4 0x7f7ea4358630 __stack_chk_fail (libc.so.6 + 0x10d630) #5 0x7f7ea443bbd6 fgetflags (libe2p.so.2 + 0x3bd6) #6 0x557d54ea24d5 n/a (lsattr + 0x14d5) #7 0x557d54ea26c9 n/a (lsattr + 0x16c9) #8 0x557d54ea2369 n/a (lsattr + 0x1369) #9 0x7f7ea4271d0a __libc_start_main (libc.so.6 + 0x26d0a) #10 0x557d54ea23ea n/a (lsattr + 0x13ea) ... Core was generated by `lsattr /dev/dri/card0'. Program terminated with signal SIGABRT, Aborted. #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 50 ../sysdeps/unix/sysv/linux/raise.c: Datei oder Verzeichnis nicht gefunden. (gdb) bt #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 #1 0x7f7ea4270537 in __GI_abort () at abort.c:79 #2 0x7f7ea42c9768 in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7f7ea43d7c24 "*** %s ***: terminated\n") at ../sysdeps/posix/libc_fatal.c:155 #3 0x7f7ea4358652 in __GI___fortify_fail (msg=msg@entry=0x7f7ea43d7c0c "stack smashing detected") at fortify_fail.c:26 #4 0x7f7ea4358630 in __stack_chk_fail () at stack_chk_fail.c:24 #5 0x7f7ea443bbd6 in fgetflags () from /lib/x86_64-linux-gnu/libe2p.so.2 #6 0x557d54ea24d5 in ?? () #7 0x557d54ea26c9 in ?? () #8 0x557d54ea2369 in ?? () #9 0x7f7ea4271d0a in __libc_start_main (main=0x557d54ea21d0, argc=2, argv=0x7ffda1e5c978, init=, fini=, rtld_fini=, stack_end=0x7ffda1e5c968) at ../csu/libc-start.c:308 #10 0x557d54ea23ea in ?? () (gdb) bt #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 #1 0x7f7ea4270537 in __GI_abort () at abort.c:79 #2 0x7f7ea42c9768 in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7f7ea43d7c24 "*** %s ***: terminated\n") at
Bug#985489: 0ad freezes with 0.0.24b1
Dear Maintainer, I tried to have a look at this savegame and when loaded shows these freezes to me too. An attached gdb shows that leaving VertexPathfinder::ComputeShortPath takes some minutes, while the game is frozen. Upstream might have already some optimizations for this issue in [1]. At least the game shows an "obstacle" that might block some units, because of an closed gate. Kind regards, Bernhard (gdb) bt #0 CheckVisibility (a=..., edges=..., a=..., edges=..., b=...) at /usr/include/c++/10/bits/stl_vector.h:918 #1 VertexPathfinder::ComputeShortPath (this=0x5587684b0f50, request=..., cmpObstructionManager=...) at ../../../source/simulation2/helpers/VertexPathfinder.cpp:786 #2 0x5587572ccc1d in CCmpPathfinder::PathfinderWorker::Work (this=0x558767340600, pathfinder=...) at ../../../source/simulation2/components/CCmpPathfinder.cpp:772 #3 0x5587572ccffb in CCmpPathfinder::StartProcessingMoves (this=0x55875e086000, useMax=) at ../../../source/simulation2/components/CCmpPathfinder.cpp:841 #4 0x55875725417f in CSimulation2Impl::Update (this=0x55875e1350c0, turnLength=, commands=std::vector of length 0, capacity 0) at ../../../source/simulation2/Simulation2.cpp:399 #5 0x55875729647c in CTurnManager::Update (this=0x55875db87c20, simFrameLength=, maxTurns=1) at ../../../source/simulation2/system/TurnManager.cpp:169 #6 0x5587573e786e in CGame::Update (this=0x55875bb809d0, deltaRealTime=0.20622983574867249, doInterpolate=) at ../../../source/ps/Game.cpp:400 #7 0x5587571f3b32 in Frame () at ../../../source/main.cpp:426 #8 RunGameOrAtlas (argc=, argv=) at ../../../source/main.cpp:692 #9 0x5587571e021a in main (argc=1, argv=0x7fffcf84d8c8) at ../../../source/main.cpp:743 (gdb) finish Run till exit from #0 CheckVisibility (a=..., edges=..., a=..., edges=..., b=...) at /usr/include/c++/10/bits/stl_vector.h:918 VertexPathfinder::ComputeShortPath (this=0x5587684b0f50, request=..., cmpObstructionManager=...) at ../../../source/simulation2/helpers/VertexPathfinder.cpp:786 786 ../../../source/simulation2/helpers/VertexPathfinder.cpp: Datei oder Verzeichnis nicht gefunden. (gdb) finish Run till exit from #0 VertexPathfinder::ComputeShortPath (this=0x5587684b0f50, request=..., cmpObstructionManager=...) at ../../../source/simulation2/helpers/VertexPathfinder.cpp:786 CCmpPathfinder::PathfinderWorker::Work (this=0x558767340600, pathfinder=...) at ../../../source/simulation2/components/CCmpPathfinder.cpp:773 ... [1] https://trac.wildfiregames.com/log/ps/trunk/source/simulation2/helpers/VertexPathfinder.cpp
Bug#985473: slic3r: symbol lookup error after gcode export
Dear Maintainer, tried to export the example files delivered with prusa-slicer e.g. AK_Bed.stl, but could not reproduce the fault inside a minimal qemu VM. My resulting process has /usr/lib/slic3r/auto/Slic3r/XS/XS.so mapped, the function _ZN5boost6nowide6setenvEPKcS2_i would be printed by gdb as this: "boost::nowide::setenv(char const*, char const*, int)@plt" But I could not see gdb trapping at this breakpoint. Maybe I have not a good input file for this. Kind regards, Bernhard
Bug#985137: Segfault plotting wind data
Dear Maintainer, I could reproduce the issue inside a minimal stable VM. It crashes with following backtrace [1]. This crash does not show up with the same input in current testing. The resulting png file shows a "mesh" on top of a map. The method GribDecoder::visit changed a bit [2]. Kind regards, Bernhard [1] Program terminated with signal SIGSEGV, Segmentation fault. #0 0x7f4f07840dce in magics::GribDecoder::visit (this=0x1b1f5e0, transformation=...) at ./src/decoders/GribDecoder.cc:371 371transformation.setMinMaxX(matrix_->minX(), matrix_->maxX()); (gdb) bt #0 0x7f4f07840dce in magics::GribDecoder::visit (this=0x1b1f5e0, transformation=...) at ./src/decoders/GribDecoder.cc:371 #1 0x7f4f0755a4f2 in magics::VisualAction::visit (this=0x1b1f440, transformation=...) at /usr/include/c++/8/bits/locale_facets.h:877 #2 0x7f4f07553cd4 in magics::BasicSceneObject::dispatch (visitor=..., this=0x1b1d900) at /usr/include/c++/8/bits/stl_iterator.h:783 #3 magics::BasicSceneObject::visit (transformation=..., this=0x1b1d900) at ./src/basic/BasicSceneObject.h:135 #4 magics::ViewNode::visit (this=0x1b1d900, tree=...) at ./src/basic/ViewNode.cc:286 #5 0x7f4f0753a92c in magics::BasicSceneObject::dispatch (visitor=..., this=0x1b1d560) at ./src/common/Layout.h:237 #6 magics::FortranSceneNode::visit (this=0x1b1d560, tree=...) at ./src/basic/SceneNode.cc:134 #7 0x7f4f07536e6b in magics::BasicSceneObject::dispatch (visitor=..., this=0x16e3c40) at /usr/include/c++/8/bits/stl_iterator.h:783 #8 magics::RootScenePage::visualise (this=0x16e3c40) at ./src/basic/RootSceneNode.cc:346 #9 0x7f4f0753707a in magics::RootSceneNode::visualise (this=0x1a43240) at ./src/basic/RootSceneNode.cc:331 #10 0x7f4f075065d5 in magics::FortranMagics::dispatch (this=this@entry=0x1b15740) at ./src/basic/FortranMagics.cc:509 #11 0x7f4f075098c0 in magics::FortranMagics::pclose (this=0x1b15740) at ./src/basic/FortranMagics.cc:144 #12 0x7f4f0747a27d in pclose_ () at ./src/common/MagicsCalls.cc:1085 ... (gdb) py-bt Traceback (most recent call first): File "/usr/lib/python3/dist-packages/Magics/Magics.py", line 181, in finalize return dll.mag_close() File "/usr/lib/python3/dist-packages/Magics/Magics.py", line 149, in wrapped err = fn(*args) File "/usr/lib/python3/dist-packages/Magics/macro.py", line 523, in _plot Magics.finalize() File "wflags-segfault.py", line 29, in (gdb) print this->matrix_ $4 = (magics::Matrix *) 0x0 https://sources.debian.org/src/magics++/3.3.1-1/src/decoders/GribDecoder.cc/#L371 [2] https://sources.debian.org/src/magics++/4.6.0-2/src/decoders/GribDecoder.cc/#L406 # single-use Buster/stable amd64 qemu VM 2021-03-31 apt update apt dist-upgrade apt install systemd-coredump lightdm xserver-xorg openbox xterm mc gdb xygrib magics++ python3-magics++ libeccodes-tools \ libeccodes0-dbgsym libmagplus3v5-dbgsym libffi6-dbg pyhton3-dbg apt build-dep libeccodes0 mkdir /home/benutzer/source/eccodes/orig -p cd/home/benutzer/source/eccodes/orig apt source eccodes cd wget "https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=985137;filename=wflags-segfault.tar.gz;msg=5; -O wflags-segfault.tar.gz tar -zxf wflags-segfault.tar.gz benutzer@debian:~$ python3 wflags-segfault.py Magics :-- Magics : Magics : Magics 3.3.1 (64 bit) Magics : Magics : Meteorological Applications Graphics Integrated Colour System Magics : Magics :Developed By Magics : Magics : The European Centre for Medium-Range Weather Forecasts Magics : Magics : Magics :-- Speicherzugriffsfehler (Speicherabzug geschrieben) root@debian:~# coredumpctl list TIMEPID UID GID SIG COREFILE EXE Thu 2021-04-01 18:26:33 CEST 21049 1000 1000 11 present /usr/bin/python3.7 root@debian:~# coredumpctl gdb 21049 PID: 21049 (python3) UID: 1000 (benutzer) GID: 1000 (benutzer) Signal: 11 (SEGV) Timestamp: Thu 2021-04-01 18:26:32 CEST (39s ago) Command Line: python3 wflags-segfault.py Executable: /usr/bin/python3.7 Control Group: /user.slice/user-1000.slice/session-5.scope Unit: session-5.scope Slice: user-1000.slice Session: 5 Owner UID: 1000 (benutzer) Boot ID: 13704ca5860b4e1ca1d50c521516559a Machine ID: 33f18f39d2a9438eb75b0ed52848afcd Hostname: debian Storage: /var/lib/systemd/coredump/core.python3.1000.13704ca5860b4e1ca1d50c521516559a.21049.161729439200.lz4 Message: Process 21049 (python3) of user 1000 dumped core. Stack trace of thread 21049: #0
Bug#985402: libgconf-2-4: found segmentation fault
Hello Antonio, was this line in dmesg maybe followed by a "Code:" line? Could you provide that too? Otherwise maybe you could install systemd-coredump and after the next crash journal should contain more info about it and collect a core for later inspection. More details here: https://wiki.debian.org/HowToGetABacktrace Kind regards, Bernhard
Bug#985364: Aborted (core dumped) drawing a simple GRIB file
Hello Enrico, I am not involved in packaging python3-magics++, just tried to reproduce this fault. Unfortunately it did not show up in my minimal test VM. It produced a png with a frame and a text and a symbol at the bottom. Is there something more expected to be in the rendered png? Do I have missed to install some kind of map data or similar? You write grib_dump shows no fault, should XyGrib work on that file too - it shows me (translated): file cannot be opened. It's not a GRIB file or it contains no valid data or ... Might that give a hint on what is the issue? Maybe you could add a backtrace of the assert? Kind regards, Bernhard
Bug#985197: kwin-wayland: Drag and drop a file in Dolphin makes KDE Plasma Wayland crash
Hello Silvério, Am 31.03.21 um 20:42 schrieb Silvério Santos: Hallo Bernhard, Here is it: Mär 31 20:11:25 systemname kernel: kwin_wayland[1834]: segfault at e8 ip 7fe70ba08268 sp 7ffc9bbf64d0 error 4 in libKWaylandServer.so.5.20.5[7fe70b9b+b6000] Mär 31 20:11:25 systemname kernel: Code: 00 00 48 8b 47 10 48 8b 40 48 c3 90 66 0f 1f 44 00 00 41 57 41 56 41 55 41 54 41 89 f4 55 48 89 fd 53 48 83 ec 18 4c 8b 7f 10 <49> 8b 87 c8 00 00 00 8b 48 0c 8b 58 08 89 4c 24 0c 89 5c 24 08 39 Mär 31 20:11:25 systemname systemd[1]: Created slice system-systemd\x2dcoredump.slice. Mär 31 20:11:25 systemname systemd[1]: Started Process Core Dump (PID 3494/UID 0). Mär 31 20:12:04 systemname systemd-coredump[3495]: Process 1834 (kwin_wayland) of user 1000 dumped core. Stack trace of thread 1834: #0 0x7fe70ba08268 n/a (n/a + 0x0) Mär 31 20:12:05 systemname systemd[1]:systemd-coredump@0-3494-0.service: Succeeded. thanks for the quick response, but unfortunately this is less informative as I expected it to be. If you have the package gdb installed could you please try following commands and forward the output: coredumpctl gdb 1834 set pagination off bt (With 1834 or the last pid shown after kwin_wayland from the latest crash.) Kind regards, Bernhard
Bug#985383: auditd: Stopping of auditd service cause segmentation fault
Control: fixed -1 1:3.0-2 Control: tags -1 + upstream fixed-upstream Dear Maintainer, I tried to reproduce this issue and got this backtrace: (gdb) bt #0 0x7f52d57cf7e4 in _IO_new_fclose (fp=0x0) at iofclose.c:48 #1 0x55884d86fec0 in shutdown_events () at ../../../src/auditd-event.c:122 #2 0x55884d86d421 in close_down () at ../../../src/auditd.c:1012 #3 0x55884d86c9a7 in main (argc=, argv=) at ../../../src/auditd.c:995 https://sources.debian.org/src/audit/1:2.8.4-3/src/auditd-event.c/#L122 It looks like upstream has already fixed this issue in this commit, which is already included in current version in testing: https://github.com/linux-audit/audit-userspace/commit/e42602b7b246ae62e7a12e9cd91f0ac37b1b1968 https://sources.debian.org/src/audit/1:3.0-2/src/auditd-event.c/#L142 Kind regards, Bernhard # single-use Buster/stable amd64 qemu VM 2021-03-31 apt update apt dist-upgrade apt install systemd-coredump mc gdb auditd auditd-dbgsym service auditd stop cp -a /etc/audit/auditd.conf /etc/audit/auditd.conf.orig sed -i 's@write_logs = yes@write_logs = no@g' /etc/audit/auditd.conf sed -i 's@log_file = /var/log/audit/audit.log@#log_file =@g' /etc/audit/auditd.conf service auditd start service auditd stop journalctl -f Mär 31 17:00:07 debian systemd[1]: Stopping Security Auditing Service... Mär 31 17:00:07 debian audit[1261]: ANOM_ABEND auid=4294967295 uid=0 gid=0 ses=4294967295 subj==unconfined pid=1261 comm="auditd" exe="/usr/sbin/auditd" sig=11 res=1 Mär 31 17:00:07 debian kernel: auditd[1261]: segfault at 0 ip 7f52d57cf7e4 sp 7ffe709d0790 error 4 in libc-2.28.so[7f52d5782000+148000] Mär 31 17:00:07 debian kernel: Code: 00 64 44 89 23 85 c0 75 d4 e9 3b ff ff ff 0f 1f 84 00 00 00 00 00 e8 fb a4 00 00 e9 09 ff ff ff e8 d1 af 09 00 90 41 54 55 53 <8b> 07 48 89 fb f6 c4 20 0f 85 9e 00 00 00 89 c2 81 e2 00 80 00 00 Mär 31 17:00:07 debian systemd[1]: Created slice system-systemd\x2dcoredump.slice. Mär 31 17:00:07 debian systemd[1]: Started Process Core Dump (PID 1304/UID 0). Mär 31 17:00:07 debian audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj==unconfined msg='unit=systemd-coredump@0-1304-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Mär 31 17:00:07 debian systemd[1]: auditd.service: Main process exited, code=dumped, status=11/SEGV Mär 31 17:00:07 debian systemd[1]: auditd.service: Failed with result 'core-dump'. Mär 31 17:00:07 debian systemd[1]: Stopped Security Auditing Service. Mär 31 17:00:07 debian audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj==unconfined msg='unit=auditd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed' Mär 31 17:00:07 debian kernel: audit: type=1131 audit(1617202807.556:30): pid=1 uid=0 auid=4294967295 ses=4294967295 subj==unconfined msg='unit=auditd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed' Mär 31 17:00:07 debian systemd-coredump[1305]: Process 1261 (auditd) of user 0 dumped core. Stack trace of thread 1261: #0 0x7f52d57cf7e4 fclose (libc.so.6) #1 0x55884d86fec0 n/a (auditd) #2 0x55884d86d421 n/a (auditd) #3 0x55884d86c9a7 n/a (auditd) #4 0x7f52d578409b __libc_start_main (libc.so.6) #5 0x55884d86cf4a n/a (auditd) Mär 31 17:00:07 debian systemd[1]: systemd-coredump@0-1304-0.service: Succeeded. Mär 31 17:00:07 debian audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj==unconfined msg='unit=systemd-coredump@0-1304-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Mär 31 17:00:07 debian kernel: audit: type=1131 audit(1617202807.592:31): pid=1 uid=0 auid=4294967295 ses=4294967295 subj==unconfined msg='unit=systemd-coredump@0-1304-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' root@debian:~# coredumpctl list TIMEPID UID GID SIG COREFILE EXE Wed 2021-03-31 17:00:07 CEST 1261 0 0 11 present /usr/sbin/auditd root@debian:~# coredumpctl gdb 1261 PID: 1261 (auditd) UID: 0 (root) GID: 0 (root) Signal: 11 (SEGV) Timestamp: Wed 2021-03-31 17:00:07 CEST (1min 30s ago) Command Line: /sbin/auditd Executable: /usr/sbin/auditd Control Group: /system.slice/auditd.service Unit: auditd.service Slice: system.slice Boot ID: 13704ca5860b4e1ca1d50c521516559a Machine ID:
Bug#985197: kwin-wayland: Drag and drop a file in Dolphin makes KDE Plasma Wayland crash
Hello Santos, I tried to reproduce this issue but did not see it inside a minimal VM. Therefore tried to some more information from the Code bytes printed in you journal/dmesg. This should point to this instruction: 0x7f6e16bd5268 <_ZN14KWaylandServer16SurfaceInterface13frameRenderedEj+24>: 49 8b 87 c8 00 00 00mov0xc8(%r15),%rax A breakpoint set to this instruction points to this source line: 0x...268 in QListData::isEmpty() const at /usr/include/x86_64-linux-gnu/qt5/QtCore/qlist.h:116 The unmangled function name should read like this: KWaylandServer::SurfaceInterface::frameRendered(unsigned int) Unfortunately this seems not exact enough to take further actions. Therefore I would suggest installing, if possible, the package systemd-coredump. That way in the journal a simple backtrace should be printed which might give an idea which functions are involved. (As there may crash multiple processes as the wayland server dies, make sure to get the lines after this line: "Process ... (kwin_wayland) of user ... dumped core" On the other side a search in upstream bugtracker returned [1]. I could immediately reproduce that crash by dragging an icon from the kickoff menu onto a opened konsole window, which crashed in the exact same instruction, pointed to by the code bytes from the bug submission. Therefore I guess chances are not too bad this bug is related. Kind regards, Bernhard [1] https://bugs.kde.org/show_bug.cgi?id=428399 # single-use Bullseye/testing amd64 qemu VM 2021-03-29 echo "set enable-bracketed-paste off" >> /etc/inputrc; bash apt update # to speedup testing mv /etc/manpath.config /etc/manpath.config.renamed apt install libeatmydata1 export LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libeatmydata.so apt dist-upgrade apt install systemd-coredump mc gdb rr valgrind sddm plasma-workspace-wayland dolphin konsole lilypond-doc-html \ libkwaylandserver5-dbgsym apt build-dep libkwaylandserver5 mkdir /home/benutzer/source/libkwaylandserver5/orig -p cd/home/benutzer/source/libkwaylandserver5/orig apt source libkwaylandserver5 cd cp -a /usr/share/doc/lilypond/html/Documentation/58/lily-ab77784d.ly . # could not reproduce by drag and drop ... https://wiki.debian.org/InterpretingKernelOutputAtProcessCrash # By bug submitter: kernel: kwin_wayland[12033]: segfault at e8 ip 7fbbe21d5268 sp 7ffe4b5000b0 error 4 in libKWaylandServer.so.5.20.5[7fbbe217d000+b6000] kernel: Code: 00 00 48 8b 47 10 48 8b 40 48 c3 90 66 0f 1f 44 00 00 41 57 41 56 41 55 41 54 41 89 f4 55 48 89 fd 53 48 83 ec 18 4c 8b 7f 10 <49> 8b 87 c8 00 00 00 8b 48 0c 8b 58 08 89 4c 24 0c 89 5c 24 08 39 error 4 == 0b100 0: no page found 0: read access 1: user-mode access echo -n "find /b ..., ..., 0x" && \ echo "00 00 48 8b 47 10 48 8b 40 48 c3 90 66 0f 1f 44 00 00 41 57 41 56 41 55 41 54 41 89 f4 55 48 89 fd 53 48 83 ec 18 4c 8b 7f 10 <49> 8b 87 c8 00 00 00 8b 48 0c 8b 58 08 89 4c 24 0c 89 5c 24 08 39" \ | sed 's/[<>]//g' | sed 's/ /, 0x/g' find /b ..., ..., 0x00, 0x00, 0x48, 0x8b, 0x47, 0x10, 0x48, 0x8b, 0x40, 0x48, 0xc3, 0x90, 0x66, 0x0f, 0x1f, 0x44, 0x00, 0x00, 0x41, 0x57, 0x41, 0x56, 0x41, 0x55, 0x41, 0x54, 0x41, 0x89, 0xf4, 0x55, 0x48, 0x89, 0xfd, 0x53, 0x48, 0x83, 0xec, 0x18, 0x4c, 0x8b, 0x7f, 0x10, 0x49, 0x8b, 0x87, 0xc8, 0x00, 0x00, 0x00, 0x8b, 0x48, 0x0c, 0x8b, 0x58, 0x08, 0x89, 0x4c, 0x24, 0x0c, 0x89, 0x5c, 0x24, 0x08, 0x39 # dpkg -S libKWaylandServer.so.5.20.5 libkwaylandserver5:amd64: /usr/lib/x86_64-linux-gnu/libKWaylandServer.so.5.20.5 $ gdb -q --pid $(pidof kwin_wayland) ... (gdb) set width 0 (gdb) set pagination off (gdb) info share FromTo Syms Read Shared Object Library 0x7f6e16b80ff0 0x7f6e16c32a66 Yes /lib/x86_64-linux-gnu/libKWaylandServer.so.5 ... (gdb) find /b 0x7f6e16b80ff0, 0x7f6e16c32a66, 0x00, 0x00, 0x48, 0x8b, 0x47, 0x10, 0x48, 0x8b, 0x40, 0x48, 0xc3, 0x90, 0x66, 0x0f, 0x1f, 0x44, 0x00, 0x00, 0x41, 0x57, 0x41, 0x56, 0x41, 0x55, 0x41, 0x54, 0x41, 0x89, 0xf4, 0x55, 0x48, 0x89, 0xfd, 0x53, 0x48, 0x83, 0xec, 0x18, 0x4c, 0x8b, 0x7f, 0x10, 0x49, 0x8b, 0x87, 0xc8, 0x00, 0x00, 0x00, 0x8b, 0x48, 0x0c, 0x8b, 0x58, 0x08, 0x89, 0x4c, 0x24, 0x0c, 0x89, 0x5c, 0x24, 0x08, 0x39 0x7f6e16bd523e 1 pattern found. (gdb) b * (0x7f6e16bd523e + 42) Breakpoint 1 at 0x7f6e16bd5268: file /usr/include/x86_64-linux-gnu/qt5/QtCore/qlist.h, line 116. (gdb) info b Num Type Disp Enb AddressWhat 1 breakpoint keep y 0x7f6e16bd5268 in QListData::isEmpty() const at /usr/include/x86_64-linux-gnu/qt5/QtCore/qlist.h:116 (gdb) disassemble /r 0x7f6e16bd523e, 0x7f6e16bd523e + 62 Dump of assembler code from 0x7f6e16bd523e to 0x7f6e16bd527c: 0x7f6e16bd523e: 00 00 add%al,(%rax) 0x7f6e16bd5240 <_ZNK14KWaylandServer16SurfaceInterface10compositorEv+0>: 48 8b 47 10 mov0x10(%rdi),%rax 0x7f6e16bd5244
Bug#984920: php7.3-imap: Using php-imap may cause segmentation faults
Dear Maintainer,
I tried to have a look at this segfault.
As far as I can see the issue here is a memory access after the
php heap, where this memory was allocated from, got unmapped.
Below are the backtraces for allocation [1], unmapping [2]
and the segfault [3].
Some more details in attached file.
Kind regards,
Bernhard
[1]
Breakpoint 69, 0x5636fef8fa40 in timelib_strtotime (s=0x5636ff1ae641 "now",
len=len@entry=3, errors=errors@entry=0x7fffd2243b98, tzdb=0x5636ffcb14c0,
tz_get_wrapper=tz_get_wrapper@entry=0x5636fef86af0 ) at
./ext/date/lib/parse_date.c:22046
22046 in.errors = timelib_malloc(sizeof(timelib_error_container));
1: x/i $pc
=> 0x5636fef8fa40 : mov%rax,0x60(%rsp)
(rr) bt
#0 0x5636fef8fa40 in timelib_strtotime (s=0x5636ff1ae641 "now",
len=len@entry=3, errors=errors@entry=0x7fffd2243b98, tzdb=0x5636ffcb14c0,
tz_get_wrapper=tz_get_wrapper@entry=0x5636fef86af0 ) at
./ext/date/lib/parse_date.c:22046
#1 0x5636fef8c18c in php_date_initialize (dateobj=0x7f3a880d1a10,
time_str=0x0, time_str_len=, format=0x0, timezone_object=0x0,
ctor=1) at ./ext/date/php_date.c:2686
#2 0x5636fef8c9e5 in zim_DateTime___construct (execute_data=0x7f3a8921f0c0,
return_value=) at ./ext/date/php_date.h:143
#3 0x5636ff1a0b4b in ZEND_DO_FCALL_SPEC_RETVAL_UNUSED_HANDLER () at
./Zend/zend_vm_execute.h:984
#4 execute_ex (ex=0x7f3a89200040) at ./Zend/zend_vm_execute.h:55523
#5 0x5636ff1a25e7 in zend_execute
(op_array=op_array@entry=0x7f3a880c0600, return_value=0x0,
return_value@entry=0x7f3a8921e9c0) at ./Zend/zend_vm_execute.h:60935
#6 0x5636ff11b233 in zend_execute_scripts (type=type@entry=8,
retval=0x7f3a8921e9c0, retval@entry=0x0, file_count=file_count@entry=3) at
./Zend/zend.c:1568
#7 0x5636ff0bb788 in php_execute_script (primary_file=)
at ./main/main.c:2637
#8 0x5636ff1a4b9e in do_cli (argc=3, argv=0x5636ffb0ca30) at
./sapi/cli/php_cli.c:1000
#9 0x5636fef80b9b in main (argc=3, argv=0x5636ffb0ca30) at
./sapi/cli/php_cli.c:1396
(rr) when
Current event: 4495
(rr) x/4xb 0x7f3a88055ca8
0x7f3a88055ca8: 0xb00xa10x0e0x88
[2]
Breakpoint 70, munmap () at ../sysdeps/unix/syscall-template.S:78
78 ../sysdeps/unix/syscall-template.S: Datei oder Verzeichnis nicht
gefunden.
1: x/i $pc
=> 0x7f3a8b7e31d0 : mov$0xb,%eax
(rr) bt
#0 munmap () at ../sysdeps/unix/syscall-template.S:78
#1 0x5636ff0f26f7 in zend_mm_munmap (size=2097152, addr=) at ./Zend/zend_alloc.c:777
#2 zend_mm_chunk_free (addr=, size=size@entry=2097152,
heap=) at ./Zend/zend_alloc.c:777
#3 0x5636ff0f2b3a in zend_mm_shutdown (heap=0x7f3a89200040, full=0,
silent=) at ./Zend/zend_alloc.c:2301
#4 0x5636ff0ba357 in php_request_shutdown (dummy=) at
./main/main.c:1951
#5 0x5636ff1a3fda in do_cli (argc=3, argv=0x5636ffb0ca30) at
./sapi/cli/php_cli.c:1167
#6 0x5636fef80b9b in main (argc=3, argv=0x5636ffb0ca30) at
./sapi/cli/php_cli.c:1396
(rr) when
Current event: 4620
(rr) x/4xb 0x7f3a88055ca8
0x7f3a88055ca8: 0x000x000x000x00
(rr) finish
Run till exit from #0 munmap () at ../sysdeps/unix/syscall-template.S:78
0x5636ff0f26f7 in zend_mm_munmap (size=2097152, addr=)
at ./Zend/zend_alloc.c:777
777 zend_mm_munmap(addr, size);
1: x/i $pc
=> 0x5636ff0f26f7 : test %eax,%eax
(rr) x/4xb 0x7f3a88055ca8
0x7f3a88055ca8: Cannot access memory at address 0x7f3a88055ca8
[3]
PHP Fatal error: Uncaught ErrorException: Notice: Unknown: Unexpected
characters at end of address: < (errflg=3) in Unknown:0
Stack trace:
#0 [internal function]:
Symfony\Component\ErrorHandler\ErrorHandler->handleError(8, 'Unknown:
Unexpe...', 'Unknown', 0, NULL)
#1 {main}
thrown in Unknown on line 0
Program received signal SIGSEGV, Segmentation fault.
0x5636fefac749 in timelib_error_container_dtor (errors=0x7f3a88055ca8)
at ./ext/date/lib/timelib.c:156
156 for (i = 0; i < errors->warning_count; i++) {
1: x/i $pc
=> 0x5636fefac749 : mov
0x14(%rdi),%edi
2: /x $rax = 0x0
3: /x $rsp = 0x7fffd2247350
(rr) bt
#0 0x5636fefac749 in timelib_error_container_dtor
(errors=0x7f3a88055ca8) at ./ext/date/lib/timelib.c:156
#1 0x5636fef82e9c in zm_shutdown_date (type=,
module_number=) at ./ext/date/php_date.c:945
#2 0x5636ff120397 in module_destructor
(module=module@entry=0x5636ffb3ace0) at ./Zend/zend_API.c:2575
#3 0x5636ff119e6c in module_destructor_zval (zv=) at
./Zend/zend.c:745
#4 0x5636ff12ada3 in _zend_hash_del_el_ex (prev=, p=, idx=1, ht=) at ./Zend/zend_hash.c:1182
#5 _zend_hash_del_el (p=0x5636ffb900f0, idx=1, ht=0x5636ff31b260
) at ./Zend/zend_hash.c:1205
#6 zend_hash_graceful_reverse_destroy (ht=ht@entry=0x5636ff31b260
) at
Bug#984975: gedit 3.30.2-2 segmentation fault
Hello Nenad Cvetkovic,
I tried to have a look at your core file.
It shows a crash with following backtrace [1].
The reason seems to be an invalid function pointer in variable "prepare".
The upstream issue in [2] shows a similar backtrace, but I
am not sure if they are related about what is causing it.
Investigation with a core file needs the same installed
package version, therefore the inspection at the host
creating the core has less chances for discrepancies.
Therefore, if you have gdb installed, you should be able
to generate a backtrace on your system too by e.g.:
coredumpctl list
coredumpctl gdb
bt
This gets normally improved by installing the dbgsym packages
or setting the environment DEBUGINFOD_URLS,
both and more described in [3].
Therefore the question, is there a reason for what looks like
local rebuilt packages libenchant1c2a and libxml2
due to the "~1.gbp73138d" version postfix?
Kind regards,
Bernhard
[1]
Core was generated by `/usr/bin/gedit --gapplication-service'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x007f198f in ?? ()
[Current thread is 1 (Thread 0x7f7cde497a80 (LWP 15100))]
(gdb) bt
#0 0x007f198f in ?? ()
#1 0x7f7ce25f7669 in g_main_context_prepare
(context=context@entry=0x55ba65041ad0, priority=priority@entry=0x7ffcb3349aa0)
at ../../../glib/gmain.c:3492
#2 0x7f7ce25f806b in g_main_context_iterate
(context=context@entry=0x55ba65041ad0, block=block@entry=1,
dispatch=dispatch@entry=1, self=) at ../../../glib/gmain.c:3900
#3 0x7f7ce25f825c in g_main_context_iteration
(context=context@entry=0x55ba65041ad0, may_block=may_block@entry=1) at
../../../glib/gmain.c:3981
#4 0x7f7ce37aea2d in g_application_run (application=0x55ba650231e0,
argc=, argv=0x7ffcb3349c88) at ../../../gio/gapplication.c:2470
#5 0x55ba63f271fa in main (argc=2, argv=0x7ffcb3349c88) at
gedit/gedit.c:146
(gdb) info local
No symbol table info available.
(gdb) up
#1 0x7f7ce25f7669 in g_main_context_prepare
(context=context@entry=0x55ba65041ad0, priority=priority@entry=0x7ffcb3349aa0)
at ../../../glib/gmain.c:3492
3492 result = (* prepare) (source, _timeout);
(gdb) info local
result =
prepare = 0x7f198f
source_timeout = -1
i =
n_ready = 16
current_priority = 0
source = 0x55ba658e7d00
iter = {context = 0x55ba65041ad0, may_modify = 1, current_list =
0x7f7cd00020e0, source = 0x55ba658e7d00}
https://sources.debian.org/src/glib2.0/2.58.3-2+deb10u2/glib/gmain.c/#L3492
[2]
https://gitlab.gnome.org/GNOME/gedit/-/issues/51
[3]
https://wiki.debian.org/HowToGetABacktrace
# single-use Buster/stable amd64 qemu VM 2021-03-28
echo "set enable-bracketed-paste off" >> /etc/inputrc; bash
apt update
# to speedup testing
mv /etc/manpath.config /etc/manpath.config.renamed
apt install libeatmydata1
export LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libeatmydata.so
apt dist-upgrade
apt install systemd-coredump gdb lz4 gedit gnome \
gedit-dbgsym libglib2.0-0-dbgsym
wget
"https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=984975;filename=core.gedit.1000.e6ec596bfdba4283915bcec4a14baf60.15100.161546904000.lz4;msg=5;
-O core.gedit.1000.e6ec596bfdba4283915bcec4a14baf60.15100.161546904000.lz4
unlz4
core.gedit.1000.e6ec596bfdba4283915bcec4a14baf60.15100.161546904000.lz4
gdb -q --core
core.gedit.1000.e6ec596bfdba4283915bcec4a14baf60.15100.161546904000
gdb -q /usr/bin/gedit --core
core.gedit.1000.e6ec596bfdba4283915bcec4a14baf60.15100.161546904000
benutzer@debian:~$ gdb -q /usr/bin/gedit --core
core.gedit.1000.e6ec596bfdba4283915bcec4a14baf60.15100.161546904000
Reading symbols from /usr/bin/gedit...(no debugging symbols found)...done.
[New LWP 15100]
[New LWP 15105]
[New LWP 15104]
[New LWP 15103]
[New LWP 15101]
[New LWP 15102]
warning: .dynamic section for "/lib/x86_64-linux-gnu/libpcre.so.3" is not at
the expected address (wrong library or version mismatch?)
warning: .dynamic section for "/lib/x86_64-linux-gnu/libenchant.so.1" is not at
the expected address (wrong library or version mismatch?)
warning: .dynamic section for "/lib/x86_64-linux-gnu/libzstd.so.1" is not at
the expected address (wrong library or version mismatch?)
warning: .dynamic section for
"/usr/lib/x86_64-linux-gnu/enchant/libenchant_myspell.so" is not at the
expected address (wrong library or version mismatch?)
warning: Could not load shared library symbols for 19 libraries, e.g.
/lib/x86_64-linux-gnu/libicui18n.so.65.
Use the "info sharedlibrary" command to see the complete listing.
Do you need "set solib-search-path" or "set sysroot"?
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/bin/gedit --gapplication-service'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0
Bug#984953: libgtkmm-3.0-1v5: GParted crashes on Gdk::Pixbuf::get_width() const ()
Dear Maintainer, I tried to have a look at the core file and a backtrace with all needed symbols looks like in [1]. In the end it looks like in refresh_combo_devices [2] it is attempted to load a harddisk icon. This failed for some reason in [3], therefore a local variable "theme_icon" contains a null pointer, which gets unconditionally called member function get_width on and therefore crashes a few lines later. A wild guess would be that the harddisk icon file is missing or is not accessible. Possibly there is some hint written to stdout before the crash. Kind regards, Bernhard [1] (gdb) bt #0 Gdk::Pixbuf::gobj (this=0x0) at ../gdkmm/pixbuf.h:389 #1 Gdk::Pixbuf::get_width (this=0x0) at pixbuf.cc:517 #2 0xaab89ca4 in GParted::Utils::mk_pixbuf (widget=..., stock_id=..., icon_size=..., icon_size@entry=...) at /usr/include/glibmm-2.4/glibmm/refptr.h:259 #3 0xaab92020 in GParted::Win_GParted::refresh_combo_devices (this=0xe960) at /usr/include/gtkmm-3.0/gtkmm/enums.h:2870 #4 0xaab95980 in GParted::Win_GParted::menu_gparted_refresh_devices (this=) at Win_GParted.cc:1674 #5 0xaab95e2c in GParted::Win_GParted::initial_device_refresh (data=) at Win_GParted.cc:1605 #6 0xf6b8dab4 in g_main_dispatch (context=0xaaca6f10) at ../../../glib/gmain.c:3325 #7 g_main_context_dispatch (context=0xaaca6f10) at ../../../glib/gmain.c:4043 #8 0xf6b8de5c in g_main_context_iterate (context=0xaaca6f10, block=block@entry=1, dispatch=dispatch@entry=1, self=) at ../../../glib/gmain.c:4119 #9 0xf6b8e1b0 in g_main_loop_run (loop=loop@entry=0xabb23860) at ../../../glib/gmain.c:4317 #10 0xf70b98f0 in gtk_main () at ../../../../gtk/gtkmain.c:1328 #11 0xaab2138c in main (argc=, argv=) at main.cc:62 [2] https://gitlab.gnome.org/GNOME/gparted/-/blob/master/src/Win_GParted.cc#L727 [3] https://gitlab.gnome.org/GNOME/gparted/-/blob/master/src/Utils.cc#L109 # Bullseye/testing arm64 qemu VM 2021-03-25 echo "set enable-bracketed-paste off" >> /etc/inputrc; bash apt update # to speedup testing mv /etc/manpath.config /etc/manpath.config.renamed apt install libeatmydata1 export LD_PRELOAD=/usr/lib/$(uname -m)-linux-gnu/libeatmydata.so apt dist-upgrade apt install gdb zstd mc gparted \ gparted-dbgsym libgtk-3-0-dbgsym libgtkmm-3.0-1v5-dbgsym libglib2.0-0-dbgsym apt build-dep gparted mkdir /home/benutzer/source/gparted/orig -p cd/home/benutzer/source/gparted/orig apt source gparted cd wget "https://bugs.debian.org/cgi-bin/bugreport.cgi?att=2;bug=984953;filename=gpartedbin.core.tar.zstd;msg=10; -O gpartedbin.core.tar.zstd tar axf gpartedbin.core.tar.zstd gdb -q --core gpartedbin.core gdb -q /usr/sbin/gpartedbin --core gpartedbin.core set width 0 set pagination off Core was generated by `/usr/sbin/gpartedbin'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0xf794d760 in Gdk::Pixbuf::get_width() const () from /usr/lib/aarch64-linux-gnu/libgdkmm-3.0.so.1 [Current thread is 1 (Thread 0xf51947a0 (LWP 9937))] (gdb) set width 0 (gdb) set pagination off (gdb) bt #0 0xf794d760 in Gdk::Pixbuf::get_width() const () from /usr/lib/aarch64-linux-gnu/libgdkmm-3.0.so.1 #1 0xaab89ca4 in ?? () #2 0xaab92020 in ?? () #3 0xaab95e2c in ?? () #4 0xf6b8dab4 in g_main_context_dispatch () from /usr/lib/aarch64-linux-gnu/libglib-2.0.so.0 #5 0xf6b8de5c in ?? () from /usr/lib/aarch64-linux-gnu/libglib-2.0.so.0 #6 0xf6b8e1b0 in g_main_loop_run () from /usr/lib/aarch64-linux-gnu/libglib-2.0.so.0 #7 0xf70b98f0 in gtk_main () from /usr/lib/aarch64-linux-gnu/libgtk-3.so.0 #8 0xaab2138c in ?? () #9 0xf6707218 in __libc_start_main (main=0xaab21290, argc=1, argv=0xf4e8, init=, fini=, rtld_fini=, stack_end=) at ../csu/libc-start.c:308 #10 0xaab219ec in ?? () Backtrace stopped: not enough registers or memory available to unwind further Core was generated by `/usr/sbin/gpartedbin'. Program terminated with signal SIGSEGV, Segmentation fault. #0 Gdk::Pixbuf::gobj (this=0x0) at ../gdkmm/pixbuf.h:389 389 ../gdkmm/pixbuf.h: No such file or directory. [Current thread is 1 (Thread 0xf51947a0 (LWP 9937))] (gdb) set width 0 (gdb) set pagination off (gdb) bt #0 Gdk::Pixbuf::gobj (this=0x0) at ../gdkmm/pixbuf.h:389 #1 Gdk::Pixbuf::get_width (this=0x0) at pixbuf.cc:517 #2 0xaab89ca4 in GParted::Utils::mk_pixbuf (widget=..., stock_id=..., icon_size=..., icon_size@entry=...) at /usr/include/glibmm-2.4/glibmm/refptr.h:259 #3 0xaab92020 in GParted::Win_GParted::refresh_combo_devices (this=0xe960) at /usr/include/gtkmm-3.0/gtkmm/enums.h:2870 #4 0xaab95980 in GParted::Win_GParted::menu_gparted_refresh_devices (this=) at Win_GParted.cc:1674 #5 0xaab95e2c in
Bug#979343: sddm: general protection fault in libQt5Qml.so.5.15.2
Hello everyone, I added it, and now I got one: Tue 2021-03-23 20:20:40 CET2000 109 115 11 present /usr/bin/sddm-greeter If I extract it, I get: Executable: /usr/bin/sddm-greeter ... #9 0x7fe7b41f5def __clone (libc.so.6 + 0xfddef) With this "coredumpctl gdb 2000", and when you have gdb installed, you should get a prompt "(gdb) ". There a command "bt" should get a better backtrace than the automatic one. You can get the core file, if you like, at https://www.helgefjell.de/data/sddm.core I tried to have a look at this one in the hope I have the same package versions installed as you, and have received a backtrace showing we are inside the __run_exit_handlers. This might explain why you get no issue with it except the logging, because this process has already done its main work and is about to end itself. What I further see is some object destruction going on with mentioning QV4 - which I believe is tightly related to Qts javascript engine. And finally it is in a method QMetaType::destruct, which is unfortunately about to call a function pointer m_destructor that consists of some string data. Getting a traps instead of a segfault might be because of the function pointer using more than the lower 48 bits, to which address space is currently limited? At least a short test with the value 0x0070006d006f0063 leads to such a traps message, using 0x006d006f0063 shows a "segfault at" message in dmesg. But having this string at this position might just be coincidence, a few debugging details might be found in attached file. Kind regards, Bernhard Core was generated by `/usr/bin/sddm-greeter --socket /tmp/sddm-:0-aSeIQL --theme /usr/share/sddm/them'. Program terminated with signal SIGSEGV, Segmentation fault. #0 QMetaType::destruct (data=0x563464af9d00, this=0x5634649ea3b8) at /usr/include/x86_64-linux-gnu/qt5/QtCore/qmetatype.h:2375 2375m_destructor(data); [Current thread is 1 (Thread 0x7fe7b49fb840 (LWP 2000))] (gdb) bt #0 QMetaType::destruct (data=0x563464af9d00, this=0x5634649ea3b8) at /usr/include/x86_64-linux-gnu/qt5/QtCore/qmetatype.h:2375 #1 QV4::Heap::QQmlValueTypeWrapper::destroy (this=0x7fe79833d460) at qml/qqmlvaluetypewrapper.cpp:100 #2 0x7fe7b52fa55f in QV4::Chunk::sweep (this=0x7fe79833, engine=0x56346475ffe0) at memory/qv4mm.cpp:349 #3 0x7fe7b52fa7f3 in operator() (c=, __closure=) at memory/qv4mm.cpp:630 #4 std::__partition<__gnu_cxx::__normal_iterator >, QV4::BlockAllocator::sweep():: > (__pred=..., __last=0x2, __first=0x7fe79833) at /usr/include/c++/10/bits/stl_algo.h:1515 #5 std::partition<__gnu_cxx::__normal_iterator >, QV4::BlockAllocator::sweep():: > (__pred=..., __last=..., __first=...) at /usr/include/c++/10/bits/stl_algo.h:4673 #6 QV4::BlockAllocator::sweep (this=this@entry=0x56346442fa60) at memory/qv4mm.cpp:631 #7 0x7fe7b52fb415 in QV4::MemoryManager::sweep (this=this@entry=0x56346442fa50, lastSweep=lastSweep@entry=false, classCountPtr=classCountPtr@entry=0x0) at memory/qv4mm.cpp:994 #8 0x7fe7b52fbf2d in QV4::MemoryManager::runGC (this=0x56346442fa50) at memory/qv4mm.cpp:1054 #9 0x7fe7b52fddb5 in QV4::MemoryManager::allocate (size=32, allocator=0x56346442fa60, this=0x56346442fa50) at ../../include/QtQml/5.15.2/QtQml/private/../../../../../src/qml/memory/qv4mm_p.h:307 #10 QV4::MemoryManager::allocString (this=this@entry=0x56346442fa50, unmanagedSize=) at memory/qv4mm.cpp:791 #11 0x7fe7b536418e in QV4::MemoryManager::allocWithStringData (arg1=..., unmanagedSize=, this=0x56346442fa50) at ../../include/QtQml/5.15.2/QtQml/private/../../../../../src/qml/memory/qv4mm_p.h:217 #12 QV4::ExecutionEngine::newString (this=this@entry=0x56346475ffe0, s=...) at jsruntime/qv4engine.cpp:894 #13 0x7fe7b539f688 in QV4::ErrorPrototype::method_toString (b=, thisObject=0x7fe7986b9508) at jsruntime/qv4errorobject.cpp:352 #14 0x7fe7b541706f in QV4::FunctionObject::call (argc=0, argv=0x0, thisObject=0x7fe7986b9508, this=0x7fe7986b9530) at jsruntime/qv4functionobject_p.h:172 #15 QV4::RuntimeHelpers::ordinaryToPrimitive (engine=engine@entry=0x56346475ffe0, object=object@entry=0x7fe7986b9508, typeHint=typeHint@entry=0x7fe7986b9310) at jsruntime/qv4runtime.cpp:517 #16 0x7fe7b5417394 in QV4::RuntimeHelpers::objectDefaultValue (object=0x7fe7986b9508, object@entry=0x7fe7986b9518, typeHint=typeHint@entry=2) at jsruntime/qv4runtime.cpp:495 #17 0x7fe7b541bd75 in QV4::RuntimeHelpers::toPrimitive (typeHint=QV4::STRING_HINT, value=...) at jsruntime/qv4runtime_p.h:123 #18 QV4::Value::toQStringNoThrow (this=this@entry=0x7fe7986b9508) at jsruntime/qv4value.cpp:150 #19 0x7fe7b536d5de in QV4::ExecutionEngine::catchExceptionAsQmlError (this=this@entry=0x56346475ffe0) at ../../include/QtQml/5.15.2/QtQml/private/../../../../../src/qml/jsruntime/qv4scopedvalue_p.h:234 #20 0x7fe7b5518412 in QQmlDelayedError::catchJavaScriptException (engine=0x56346475ffe0, this=0x5634647b3860)
Bug#984803: patchage: segfaults in ALSA mode
Dear Maintainer, On Mon, 08 Mar 2021 15:49:55 +0100 =?utf-8?q?IOhannes_m_zm=C3=B6lnig_=28Debian/GNU=29?= wrote: #4 0x554359e8 in PatchageCanvas::index_port(PortID const&, PatchagePort*) (this=0x0, id=..., port=0x557233c0) at ../src/PatchageCanvas.hpp:59 #5 0x55450837 in AlsaDriver::create_port(PatchageModule&, std::__cxx11::basic_string, std::allocator > const&, bool, snd_seq_addr) (this=0x55888e60, input=false, addr=...) at ../src/AlsaDriver.cpp:318 318 dynamic_cast(parent.canvas())->index_port( This crash seems to be caused by the line above where parent.canvas() returns a null pointer leading to this=0x0 in PatchageCanvas::index_port(). Unfortunately I found no upstream change related to this, and upstream seems to have evolved much lately. Therefore in [1] got removed altogether, therefore packaging a new release might fix this. Kind regards, Bernhard [1] https://gitlab.com/drobilla/patchage/-/commit/5128bfab7ddb9504abf17375e910e5bc94af291e
Bug#979343: sddm: general protection fault in libQt5Qml.so.5.15.2
Am 20.03.21 um 21:44 schrieb Helge Kreutzmann: If I should install a -dbg version or something else please inform me. Thank you for the additional information. There might really be something more. If you have not, is it possible to install the package "systemd-coredump". If then a crash happens again and it gets recorded it should be mentioned in journalctl and this command should list them: coredumpctl list And a core should be stored. (But maybe just for the current boot) There should be already a slight backtrace in journalctl that might be helpful, but with 'coredumpctl gdb' and at the gdb prompt with 'bt' it might reveal some more information. Even better when sddm-dbgsym is installed, and if sufficiently RAM is available, libqt5qml5-dbgsym. (and some more not yet known in between ...) There might be more pointer in: https://wiki.debian.org/HowToGetABacktrace Kind regards, Bernhard
Bug#977041: libapt-pkg5.0: apt install segfaults
Hello Julian, On Thu, 10 Dec 2020 16:52:14 +0100 Julian Andres Klode wrote: ... install libapt-pkg5.0-dbgsym and apt-dbgsym from the dbgsym repository and try again. Unfortunately there are just dbgsym packages for 1.4.10. I guess the dbgsym packages for 1.4.11 never got published, because they originate from a security update [1]. Even snapshot.debian.org [2] lists no dbgsym package for 1.4.11. Debian Bug [894081] seems related. Kind regards, Bernhard [1] http://deb.debian.org/debian-debug/pool/main/a/apt/ -> http://debug.mirrors.debian.org/debian-debug/pool/main/a/apt/ [2] https://snapshot.debian.org/package/apt/1.4.11/ [894081] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=894081
Bug#982661: mame: Crash on startup
Hello Celelibi, unfortunately, if I try to reproduce I reach the exact same stack, but in case of my VM ctx->pipe->set_shader_buffers contains a valid function pointer. Maybe you could add some information about which graphics card you use and maybe running with 'export LIBGL_DEBUG=verbose' might give some hints. Do you see such issues with other hardware accelerated programs too? Another way would be to debug the function where this function pointer initially gets set and if it gets overwritten later by a wrong memory operation by a watchpoint. In my test it gets set when a context gets created in [1]. Kind regards, Bernhard [1] ... #1 0x70b0905c in st_api_create_context () at ../src/mesa/state_tracker/st_manager.c:917 #2 0x70afd6c2 in dri_create_context () at ../src/gallium/frontends/dri/dri_context.c:163 #3 0x70ffccab in driCreateContextAttribs () at ../src/mesa/drivers/dri/common/dri_util.c:480 #4 0x70ffce1e in driCreateNewContextForAPI () at ../src/mesa/drivers/dri/common/dri_util.c:510 #5 driCreateNewContext () at ../src/mesa/drivers/dri/common/dri_util.c:518 #6 0x72377535 in dri2_create_context () at ../src/glx/dri2_glx.c:216 #7 0x72366938 in CreateContext () at ../src/glx/glxcmds.c:342 #8 0x72366d2e in glXCreateContext () at ../src/glx/glxcmds.c:467 #9 0x7579e983 in glXCreateContext () at ../src/GLX/libglx.c:246 ...
Bug#977878: jwm: Crashes trying to move window: segfault at (...) error 6 in jwm[5606f1bca000+26000]
Dear Maintainer, I tried to reproduce, and it got it crashing too when trying to move a window just by keyboard, before moving any windows by mouse. It looks like in that case the variable currentClient never got set, therefore the access in UpdateDesktop dereferences a null pointer. This seems to get fixed by upstream issue and commit [2]. Unfortunately there seems also to be no upstream release since 2.3.7. Kind regards, Bernhard [1] (gdb) bt #0 UpdateDesktop (now=, now=) at move.c:842 #1 0x559b2e28d28f in Signal () at event.c:269 #2 0x559b2e28e41c in WaitForEvent (event=event@entry=0x7ffdc924c010) at event.c:129 #3 0x559b2e29a2f8 in MoveClientKeyboard (np=0x559b2ed2b400) at move.c:339 #4 0x559b2e29857e in UpdateMotion (event=0x7ffdc924c1b0, runner=0x559b2e2a78f0 , menu=0x559b2ed296d0) at menu.c:710 #5 MenuLoop (runner=0x559b2e2a78f0 , menu=0x559b2ed296d0) at menu.c:405 #6 ShowSubmenu (menu=menu@entry=0x559b2ed296d0, parent=parent@entry=0x0, runner=runner@entry=0x559b2e2a78f0 , x=, y=, keyboard=keyboard@entry=1 '\001') at menu.c:296 #7 0x559b2e298a0f in ShowMenu (menu=menu@entry=0x559b2ed296d0, runner=runner@entry=0x559b2e2a78f0 , x=, x@entry=4, y=, y@entry=21, keyboard=keyboard@entry=1 '\001') at menu.c:213 #8 0x559b2e2a836b in ShowWindowMenu (np=np@entry=0x559b2ed2b400, x=4, y=21, keyboard=keyboard@entry=1 '\001') at winmenu.c:33 #9 0x559b2e28dc3b in HandleKeyPress (event=0x7ffdc924c3b0) at event.c:567 #10 ProcessEvent (event=0x7ffdc924c3b0) at event.c:283 #11 0x559b2e2833ac in EventLoop () at main.c:262 #12 main (argc=-920337520, argv=0x7ffdc924c5a8) at main.c:207 [2] https://github.com/joewing/jwm/issues/410 https://github.com/rdnvndr/jwm/commit/d0e28abd8eb8748470f07595be6da5cec05b4939 # Bullseye/testing amd64 qemu VM 2021-03-18 # to be able to paste with mouse echo "set enable-bracketed-paste off" >> /etc/inputrc; bash apt update # to speedup testing mv /etc/manpath.config /etc/manpath.config.renamed apt install libeatmydata1 export LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libeatmydata.so apt dist-upgrade apt install systemd-coredump lightdm xterm psmisc gdb jwm \ jwm-dbgsym wget https://snapshot.debian.org/archive/debian/20191125T025441Z/pool/main/j/jwm/jwm_2.3.7-3_amd64.deb wget https://snapshot.debian.org/archive/debian-debug/20191125T024842Z/pool/main/j/jwm/jwm-dbgsym_2.3.7-3_amd64.deb dpkg -i jwm_2.3.7-3_amd64.deb jwm-dbgsym_2.3.7-3_amd64.deb https://wiki.debian.org/InterpretingKernelOutputAtProcessCrash [ 507.316484] jwm[1767]: segfault at a0 ip 5606f1be0bf9 sp 7ffd942aa450 error 6 in jwm[5606f1bca000+26000] [ 507.316501] Code: 00 53 48 8d 35 68 d0 01 00 48 89 fb e8 c0 bf 00 00 49 89 c0 8b 05 eb da 01 00 49 39 c0 72 4f 48 8b 05 5b d0 01 00 f3 0f 6f 03 <83> 88 a0 00 00 00 04 80 3d 55 d0 01 00 00 0f 29 05 32 d0 01 00 0f error 6 == 0b110 1: user-mode access 1: write access 0: no page found echo -n "find /b ..., ..., 0x" && \ echo "00 53 48 8d 35 68 d0 01 00 48 89 fb e8 c0 bf 00 00 49 89 c0 8b 05 eb da 01 00 49 39 c0 72 4f 48 8b 05 5b d0 01 00 f3 0f 6f 03 <83> 88 a0 00 00 00 04 80 3d 55 d0 01 00 00 0f 29 05 32 d0 01 00 0f" \ | sed 's/[<>]//g' | sed 's/ /, 0x/g' find /b ..., ..., 0x00, 0x53, 0x48, 0x8d, 0x35, 0x68, 0xd0, 0x01, 0x00, 0x48, 0x89, 0xfb, 0xe8, 0xc0, 0xbf, 0x00, 0x00, 0x49, 0x89, 0xc0, 0x8b, 0x05, 0xeb, 0xda, 0x01, 0x00, 0x49, 0x39, 0xc0, 0x72, 0x4f, 0x48, 0x8b, 0x05, 0x5b, 0xd0, 0x01, 0x00, 0xf3, 0x0f, 0x6f, 0x03, 0x83, 0x88, 0xa0, 0x00, 0x00, 0x00, 0x04, 0x80, 0x3d, 0x55, 0xd0, 0x01, 0x00, 0x00, 0x0f, 0x29, 0x05, 0x32, 0xd0, 0x01, 0x00, 0x0f (gdb) info target Symbols from "/usr/bin/jwm". Native process: Using the running image of attached Thread 0x7f8787081240 (LWP 1403). While running this, GDB does not access memory from... Local exec file: `/usr/bin/jwm', file type elf64-x86-64. Entry point: 0x556228b47530 ... 0x556228b46f80 - 0x556228b6b411 is .text ... find /b 0x556228b46f80, 0x556228b6b411, 0x00, 0x53, 0x48, 0x8d, 0x35, 0x68, 0xd0, 0x01, 0x00, 0x48, 0x89, 0xfb, 0xe8, 0xc0, 0xbf, 0x00, 0x00, 0x49, 0x89, 0xc0, 0x8b, 0x05, 0xeb, 0xda, 0x01, 0x00, 0x49, 0x39, 0xc0, 0x72, 0x4f, 0x48, 0x8b, 0x05, 0x5b, 0xd0, 0x01, 0x00, 0xf3, 0x0f, 0x6f, 0x03, 0x83, 0x88, 0xa0, 0x00, 0x00, 0x00, 0x04, 0x80, 0x3d, 0x55, 0xd0, 0x01, 0x00, 0x00, 0x0f, 0x29, 0x05, 0x32, 0xd0, 0x01, 0x00, 0x0f benutzer@debian:~$ gdb -q --pid $(pidof jwm) Attaching to process 1403 ... (gdb) find /b 0x556228b46f80, 0x556228b6b411, 0x00, 0x53, 0x48, 0x8d, 0x35, 0x68, 0xd0, 0x01, 0x00, 0x48, 0x89, 0xfb, 0xe8, 0xc0, 0xbf, 0x00, 0x00, 0x49, 0x89, 0xc0, 0x8b, 0x05, 0xeb, 0xda, 0x01, 0x00, 0x49, 0x39, 0xc0, 0x72, 0x4f, 0x48, 0x8b, 0x05, 0x5b, 0xd0, 0x01, 0x00, 0xf3, 0x0f, 0x6f, 0x03, 0x83, 0x88, 0xa0, 0x00, 0x00, 0x00, 0x04, 0x80, 0x3d, 0x55, 0xd0, 0x01, 0x00, 0x00, 0x0f, 0x29,
Bug#978122: actiona: Segfaults on KDE Plasma Wayland
Dear Maintainer, this segfault seems to happen in [1]. It looks like upstream is not yet prepared to work with Wayland. There is an upstream issue about wayland support [2]. Kind regards, Bernhard [1] (gdb) bt #0 0x7f50f93c5caf in XGetKeyboardMapping (dpy=0x55a910fa20d0, first_keycode=first_keycode@entry=0 '\000', count=count@entry=1, keysyms_per_keycode=keysyms_per_keycode@entry=0x7ffda18a13d4) at ../../src/GetPntMap.c:103 #1 0x7f50fb31cddc in ActionTools::KeySymHelper::loadKeyCodes () at keysymhelper.cpp:141 #2 0x55a9103ad671 in main (argc=, argv=) at main.cpp:187 https://sources.debian.org/src/actiona/3.10.1-1/actiontools/keysymhelper.cpp/#L141 https://github.com/Jmgr/actiona/blob/main/actiontools/src/keysymhelper.cpp#L141 [2] https://github.com/Jmgr/actiona/issues/145 # Bullseye/testing amd64 qemu VM 2021-03-18 # to be able to paste with mouse echo "set enable-bracketed-paste off" >> /etc/inputrc apt update # to speedup testing mv /etc/manpath.config /etc/manpath.config.renamed apt install libeatmydata1 export LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libeatmydata.so apt dist-upgrade apt install systemd-coredump sddm plasma-workspace-wayland gdb actiona \ actiona-dbgsym libx11-6-dbgsym reboot dmesg: [ 31.476343] actiona[1227]: segfault at 1100080002 ip 7f50f93c5caf sp 7ffda18a1350 error 4 in libX11.so.6.4.0[7f50f93b8000+8c000] [ 31.476354] Code: 41 54 49 89 cc 55 48 89 fd 53 89 d3 48 83 ec 38 64 48 8b 04 25 28 00 00 00 48 89 44 24 28 48 8b 87 68 09 00 00 48 85 c0 74 02 10 ba 08 00 00 00 be 65 00 00 00 48 89 ef e8 dd 3a ff ff 31 c9 root@debian:~# coredumpctl list TIMEPID UID GID SIG COREFILE EXE Thu 2021-03-18 18:12:48 CET1227 1000 1000 11 present /usr/bin/actiona root@debian:~# coredumpctl gdb 1227 PID: 1227 (actiona) UID: 1000 (benutzer) GID: 1000 (benutzer) Signal: 11 (SEGV) Timestamp: Thu 2021-03-18 18:12:48 CET (54s ago) Command Line: /usr/bin/actiona Executable: /usr/bin/actiona Control Group: /user.slice/user-1000.slice/user@1000.service/app.slice/app-actiona-c1db1f2487904f65a4a2cb75daae626d.scope Unit: user@1000.service User Unit: app-actiona-c1db1f2487904f65a4a2cb75daae626d.scope Slice: user-1000.slice Owner UID: 1000 (benutzer) Boot ID: df012104535a45de88ea6998d0ba0a31 Machine ID: 33f18f39d2a9438eb75b0ed52848afcd Hostname: debian Storage: /var/lib/systemd/coredump/core.actiona.1000.df012104535a45de88ea6998d0ba0a31.1227.161608756800.zst Message: Process 1227 (actiona) of user 1000 dumped core. Stack trace of thread 1227: #0 0x7f50f93c5caf XGetKeyboardMapping (libX11.so.6 + 0x29caf) #1 0x7f50fb31cddc _ZN11ActionTools12KeySymHelper12loadKeyCodesEv (libactiontools.so.1 + 0x13dddc) #2 0x55a9103ad671 n/a (actiona + 0x2f671) #3 0x7f50f970dd0a __libc_start_main (libc.so.6 + 0x26d0a) #4 0x55a9103ae46a n/a (actiona + 0x3046a) Stack trace of thread 1229: #0 0x7f50f97da3ff __poll (libc.so.6 + 0xf33ff) #1 0x7f50f84060ae n/a (libglib-2.0.so.0 + 0x520ae) #2 0x7f50f84061cf g_main_context_iteration (libglib-2.0.so.0 + 0x521cf) #3 0x7f50f9d984bf _ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE (libQt5Core.so.5 + 0x3054bf) #4 0x7f50f9d3f92b _ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE (libQt5Core.so.5 + 0x2ac92b) #5 0x7f50f9b5ea3e _ZN7QThread4execEv (libQt5Core.so.5 + 0xcba3e) #6 0x7f50f5107a27 n/a (libQt5DBus.so.5 + 0x18a27) #7 0x7f50f9b5fb81 n/a (libQt5Core.so.5 + 0xccb81) #8 0x7f50f876bea7 start_thread (libpthread.so.0 + 0x8ea7) #9 0x7f50f97e4def __clone (libc.so.6 + 0xfddef) GNU gdb (Debian 10.1-1.7) 10.1.90.20210103-git ... Core was generated by `/usr/bin/actiona'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x7f50f93c5caf in XGetKeyboardMapping () from /lib/x86_64-linux-gnu/libX11.so.6 [Current thread is 1 (Thread 0x7f50f5603240 (LWP 1227))] (gdb) set width 0 (gdb) set pagination off (gdb) bt #0 0x7f50f93c5caf in XGetKeyboardMapping () from /lib/x86_64-linux-gnu/libX11.so.6 #1 0x7f50fb31cddc in ActionTools::KeySymHelper::loadKeyCodes() () from /usr/lib/actiona/libactiontools.so.1 #2 0x55a9103ad671 in ?? () #3 0x7f50f970dd0a in __libc_start_main (main=0x55a9103ac3e0, argc=1, argv=0x7ffda18a1a88, init=, fini=, rtld_fini=, stack_end=0x7ffda18a1a78) at ../csu/libc-start.c:308 #4 0x55a9103ae46a in ?? () Core was generated by `/usr/bin/actiona'. Program terminated with signal
Bug#979276: xserver-xorg-video-intel: Server fails to start: "Illegal instruction"
Dear Maintainer, I tried to reconstruct the given backtrace in [1]. So the actual issue seems to be a "movq" instruction which seems to be due to [3] a SSE2 instruction, which might the "Pentium III M" is lacking, like Stefan already noted. I am not sure where the current Debian baseline could be consulted regarding this, maybe [4] could give a hint. Kind regards, Bernhard [1] Backtrace: 0: Xorg (OsLookupColor+0x142) [0x611232] | 0x00646232 in OsSigHandler at ../../../../os/osinit.c:138 1: linux-gate.so.1 (?+0x0) [0xb7fbd570] | 2: intel_drv.so (?+0x0) [0xb701f94c] | 0x986c794c in choose_memcpy_tiled_x at ../../../src/sna/blt.c:1162 3: intel_drv.so (?+0x0) [0xb702ad14] | 0x986d2d14 in kgem_init_swizzling at ../../../src/sna/kgem.c:232 4: intel_drv.so (?+0x0) [0xb707aa93] | 0x98722a93 in sna_pre_init at ../../../src/sna/sna_driver.c:626 5: Xorg (InitOutput+0xa60) [0x4e7d70]| 0x0051cd70 in InitOutput at ../../../../../../hw/xfree86/common/xf86Init.c:523 6: Xorg (InitFonts+0x2b5) [0x4a8d05] | 0x004ddd05 in dix_main at ../../../../dix/main.c:193 7: Xorg (miPolyFillRect+0x804) [0x49184b]| 0x004c684b in main at ../../../../dix/stubmain.c:34 8: libc.so.6 (__libc_start_main+0x106) [0xb78cae46] | 0xb780fe46 in __libc_start_main at ../csu/libc-start.c:308 9: Xorg (_start+0x31) [0x491891] | 0x004c6891 <_start+49> Illegal instruction at address 0xb701f94c [2] (gdb) disassemble /r choose_memcpy_tiled_x, choose_memcpy_tiled_x+370 0x986c7940 : 66 0f 6e c0 movd %eax,%xmm0 0x986c7944 : 66 0f 6e c9 movd %ecx,%xmm1 0x986c7948 : 66 0f 62 c1 punpckldq %xmm1,%xmm0 -> 0x986c794c : 66 0f d6 82 0c 04 00 00 movq %xmm0,0x40c(%edx) 0x986c7954 : 5b pop %ebx 0x986c7955 : c3 ret [3] https://en.wikipedia.org/wiki/X86_instruction_listings#SSE2_MMX-like_instructions_extended_to_SSE_registers [4] https://wiki.debian.org/ArchitectureSpecificsMemo#i386-1
Bug#979340: nouveau: Suspend hangs for 5 minutes before completing
Dear Maintainer, just a side note: The visible segfaults might be related to #977945. Unknown if they have any effect on suspending. Kind regards, Bernhard
Bug#977945: redshift-gtk: [Xfce4] Odd autostart behavior and segfault
Dear Maintainer, I have tried to reproduce these segfaults and received them when redshift-gtk is installed and lightdm is used as login manager. It looks like redshift-gtk installs a systemd user unit, which is executed also for the lightdm login screen. But it looks like the 'systemd --user' processes for user lightdm does not receive which DISPLAY and XAUTHORITY environments it should deliver to the redshift-gtk process. Therefore redshift fails to connect to the xserver which leads to the segfault. So I am not sure if redshift is supposed to run at the login screen in the first place. If yes, it looks like "someone" has to tell the 'systemd --user' process by something like this: systemctl --user import-environment DISPLAY XAUTHORITY Unfortunately I did not find any obvious place for that, or how it is delivered for a regular logged in 'systemd --user' process. Kind regards, Bernhard [6.829265] redshift-gtk[692]: segfault at 18 ip 7fc62e9db690 sp 7ffdaacafbc8 error 4 in libgtk-3.so.0.2404.20[7fc62e78+374000] [6.829275] Code: da ff 48 8b 44 24 08 64 48 2b 04 25 28 00 00 00 75 0f 48 83 c4 18 5b 5d 41 5c 41 5d 41 5e 41 5f c3 e8 54 96 da ff 0f 1f 40 00 <48> 8b 47 18 48 8b 40 10 c3 0f 1f 80 00 00 00 00 53 48 8b 5f 18 48 (gdb) bt #0 _gtk_settings_get_screen (settings=0x0) at ../../../../gtk/gtksettings.c:3359 #1 0x7fc62e87c2c4 in gtk_css_value_icon_theme_compute (icon_theme=, property_id=, provider=, style=, parent_style=) at ../../../../gtk/gtkcssiconthemevalue.c:84 #2 0x7fc62e89dad8 in gtk_css_static_style_compute_value (style=0x213c040, provider=0x0, parent_style=, id=3, specified=0x7fc62eea4e20 , section=0x0) at ../../../../gtk/gtkcssstaticstyle.c:237 #3 0x7fc62e88821a in _gtk_css_lookup_resolve (lookup=lookup@entry=0x213a320, provider=provider@entry=0x0, style=style@entry=0x213c040, parent_style=parent_style@entry=0x0) at ../../../../gtk/gtkcsslookup.c:122 #4 0x7fc62e89d9a8 in gtk_css_static_style_new_compute (parent=0x0, matcher=0x0, provider=0x0) at ../../../../gtk/gtkcssstaticstyle.c:195 #5 gtk_css_static_style_get_default () at ../../../../gtk/gtkcssstaticstyle.c:164 #6 0x7fc62e888b62 in gtk_css_node_init (cssnode=0x21352c0) at ../../../../gtk/gtkcssnode.c:667 #7 0x7fc6306a3357 in g_type_create_instance (type=) at ../../../gobject/gtype.c:1862 ... (gdb) py-bt Traceback (most recent call first): File "/usr/lib/python3/dist-packages/redshift_gtk/statusicon.py", line 326, in __init__ File "/usr/lib/python3/dist-packages/redshift_gtk/statusicon.py", line 879, in run File "/usr/bin/redshift-gtk", line 27, in run() https://github.com/jonls/redshift/issues/265 https://gitlab.gnome.org/GNOME/gtk/-/issues/3310 https://superuser.com/questions/759759/writing-a-service-that-depends-on-xorg
Bug#979343: sddm: general protection fault in libQt5Qml.so.5.15.2
Hello Helge, do you still see these messages in your logging? If yes could you maybe add the surrounding logging of one such fault? E.g. by something like this: journalctl | grep "traps:" -C20 Kind regards, Bernhard
Bug#979343: sddm: general protection fault in libQt5Qml.so.5.15.2
Hello Helge, do you still see these messages in your logging? If yes could you maybe add the surrounding logging of one such fault? E.g. by something like this: journalctl | grep "traps:" -C20 Kind regards, Bernhard
Bug#983620: python3-vedo: Segfault rendering example files
Control: reassign -1 libvtk9 9.0.1+dfsg1-8
Control: affects -1 python3-vedo
Dear Maintainer,
I tried to reproduce this issue and got also a crash.
Digging further it looks like in FireTimers an iterator "timer"
of the map LocalToTimer currently points to the element
with id=1, which gets removed from the map in the backtrace
given in [1].
Therefore the iterator timer gets invalidated, but still
incremented afterwards in FireTimers in the for loop,
which leads to the crash [2].
I guess this seems to be an issue of vtk9, therefore I hope
it is ok to reassign this bug there.
Kind regards,
Bernhard
[1]
(rr) bt
#0 vtkXRenderWindowInteractorInternals::DestroyLocalTimer (id=1,
this=0x25b42f0) at ./Rendering/UI/vtkXRenderWindowInteractor.cxx:75
#1 vtkXRenderWindowInteractor::InternalDestroyTimer (this=,
platformTimerId=1) at ./Rendering/UI/vtkXRenderWindowInteractor.cxx:426
#2 0x7f19afcf5d62 in vtkRenderWindowInteractor::DestroyTimer
(this=0x258d1f0, timerId=) at
./Rendering/Core/vtkRenderWindowInteractor.cxx:906
#3 0x7f19ae550209 in vtkHoverWidget::HoverAction (w=0x25f8410) at
./Interaction/Widgets/vtkHoverWidget.cxx:129
#4 0x7f19b1a4f039 in vtkCallbackCommand::Execute (this=0x25f7c10, caller=, event=, callData=) at
./Common/Core/vtkCallbackCommand.cxx:41
#5 0x7f19b1b1e562 in vtkSubjectHelper::InvokeEvent (this=0x25c15f0,
event=25, callData=0x7ffdb4961174, self=0x258d1f0) at
./Common/Core/vtkObject.cxx:626
#6 0x7f19af67e75b in vtkXRenderWindowInteractorInternals::FireTimers
(this=0x25b42f0, rwi=0x258d1f0) at
./Rendering/UI/vtkXRenderWindowInteractor.cxx:112
#7 0x7f19af67d9a7 in vtkXRenderWindowInteractor::StartEventLoop
(this=0x258d1f0) at ./Rendering/UI/vtkXRenderWindowInteractor.cxx:258
#8 0x7f19aff074dd in PyvtkRenderWindowInteractor_Start (self=, args=) at
./debian/build/CMakeFiles/vtkRenderingCorePython/vtkRenderWindowInteractorPython.cxx:280
#9 0x0053f38a in cfunction_call (func=,
args=, kwargs=) at ../Objects/methodobject.c:548
...
(rr) print this->LocalToTimer
$17 = std::map with 2 elements = {[1] = {duration = 150, lastFire = {tv_sec
= 1615899318, tv_usec = 39132}}, [2] = {duration = 1, lastFire = {tv_sec =
1615899318, tv_usec = 362830}}}
[2]
Thread 1 received signal SIGSEGV, Segmentation fault.
...
(rr) bt
#0 std::local_Rb_tree_increment (__x=0x2e68e70) at
../../../../../src/libstdc++-v3/src/c++98/tree.cc:71
#1 std::local_Rb_tree_increment (__x=__x@entry=0x2e68e70) at
../../../../../src/libstdc++-v3/src/c++98/tree.cc:60
#2 std::_Rb_tree_increment (__x=__x@entry=0x2e68e70) at
../../../../../src/libstdc++-v3/src/c++98/tree.cc:85
#3 0x7f19af67e6fa in std::_Rb_tree_iterator >::operator++ (this=) at
/usr/include/c++/10/bits/stl_tree.h:285
#4 vtkXRenderWindowInteractorInternals::FireTimers (this=0x25b42f0,
rwi=0x258d1f0) at ./Rendering/UI/vtkXRenderWindowInteractor.cxx:105
#5 0x7f19af67d9a7 in vtkXRenderWindowInteractor::StartEventLoop
(this=0x258d1f0) at ./Rendering/UI/vtkXRenderWindowInteractor.cxx:258
#6 0x7f19aff074dd in PyvtkRenderWindowInteractor_Start (self=, args=) at
./debian/build/CMakeFiles/vtkRenderingCorePython/vtkRenderWindowInteractorPython.cxx:280
#7 0x0053f38a in cfunction_call (func=,
args=, kwargs=) at ../Objects/methodobject.c:548
...
# Bullseye/testing amd64 qemu VM 2021-03-16
apt update
apt dist-upgrade
apt install systemd-coredump sddm xserver-xorg openbox mc gdb rr valgrind
python3-vedo-examples \
python3-dbg python3-vtk9-dbgsym libvtk9-dbgsym libstdc++6-dbgsym
apt build-dep vtk9
apt build-dep gcc-10
export DISPLAY=:0
python3 /usr/share/doc/python3-vedo-examples/examples/basic/align1.py
coredumpctl list
coredumpctl gdb 10789
echo 1 > /proc/sys/kernel/perf_event_paranoid
mkdir /home/benutzer/source/vtk9/orig -p
cd/home/benutzer/source/vtk9/orig
apt source vtk9
cd
mkdir /home/benutzer/source/libstdc++6/orig -p
cd/home/benutzer/source/libstdc++6/orig
apt source libstdc++6
cd
benutzer@debian:~$ python3
/usr/share/doc/python3-vedo-examples/examples/basic/align1.py
ave. squared distance = 43.20515185350062
Speicherzugriffsfehler (Speicherabzug geschrieben)
root@debian:~# journalctl -e
Mär 16 12:02:46 debian kernel: traps: python3[10789] general protection fault
ip:7f71a04fbda3 sp:7ffcbedeb378 error:0 in
libstdc++.so.6.0.28[7f71a04d6000+dc000]
root@debian:~# coredumpctl list
TIMEPID UID GID SIG COREFILE EXE
Tue 2021-03-16 12:02:47 CET 10789 1000 1000 11 present /usr/bin/python3.9
root@debian:~# coredumpctl gdb 10789
PID: 10789 (python3)
UID: 1000 (benutzer)
GID: 1000 (benutzer)
Signal: 11 (SEGV)
Timestamp: Tue 2021-03-16 12:02:46 CET (1h 27min ago)
Command Line: python3
/usr/share/doc/python3-vedo-examples/examples/basic/align1.py
Executable:
Bug#983487: Asymptote error message concerning malloc (Bug#983487)
Am 15.03.21 um 16:36 schrieb John Bowman:
A SIGFPE
Hello John,
sorry, I noted the details for the SIGFPE in my
second mail just for completeness about debugging.
The issue starting it all seems the SIGSEGV from my first mail.
On a second look it seems that the descructor of
the builtin_builder object is called first, and
just afterwards the method relase on that deleted object.
Therefore the same pointer gets freed by ralloc_free twice.
Attached is a "one-liner" to illustrate how to drive gdb to
the SIGSEGV and the malloc issue.
And an example output.
And yes, it might be an mesa issue, not being
prepared of having __run_exit_handlers
calling the destructor of builtin_builder before
calling fgDeinitialize:
mesa-20.3.4/src/compiler/glsl/builtin_functions.cpp:7736:static
builtin_builder builtins;
Kind regards,
Bernhard
Script started on 2021-03-15 17:35:27+01:00 [TERM="xterm-256color"
TTY="/dev/pts/10" COLUMNS="194" LINES="61"]
benutzer@debian:~$ bash gdb-start.sh
Reading symbols from /usr/bin/asy...
Reading symbols from
/usr/lib/debug/.build-id/c0/770c19bdc18e5fcad0246cb07fa90e4a1158cf.debug...
Source directories searched:
/home/benutzer/source/libgl1-mesa-dri/orig/mesa-20.3.4/src:$cdir:$cwd
Source directories searched:
/home/benutzer/source/asymptote/orig/asymptote-2.69+ds:/home/benutzer/source/libgl1-mesa-dri/orig/mesa-20.3.4/src:$cdir:$cwd
Argument required (expression to compute).
Temporary breakpoint 1 at 0xa6a08: camp::picture::shipout3. (2 locations)
Starting program: /usr/bin/asy -config '' -render=4 -f png -o B_b.png B_b.asy
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x76be8700 (LWP 79424)]
[New Thread 0x763e7700 (LWP 79425)]
[New Thread 0x75be6700 (LWP 79426)]
[Detaching after fork from child process 79427]
[Detaching after fork from child process 79428]
[Detaching after fork from child process 79429]
[Detaching after fork from child process 79430]
Thread 1 "asy" hit Temporary breakpoint 1, camp::picture::shipout3 (this=0x3,
prefix="B_b", format="", width=162.97, height=166.97,
angle=0, zoom=1, m=..., M=..., shift=..., margin=..., t=0x55a1d260,
background=0x55a0eb00, nlights=3, lights=0x7481f548,
diffuse=0x7481f3f0, specular=0x7481f230, view=true) at picture.cc:1306
1306 if(getSetting("interrupt"))
Temporary breakpoint 2 at 0x5586c9b0: file tr.cc, line 369.
Continuing.
[Attaching after Thread 0x76c2c040 (LWP 79420) fork to child process 79431]
[New inferior 2 (process 79431)]
[Detaching after fork from parent process 79420]
[Inferior 1 (process 79420) detached]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x75be6700 (LWP 79432)]
[New Thread 0x763e7700 (LWP 79433)]
[New Thread 0x76be8700 (LWP 79434)]
[New Thread 0x7fffead13700 (LWP 79435)]
[New Thread 0x7fffea512700 (LWP 79436)]
[New Thread 0x7fffe9d11700 (LWP 79437)]
[New Thread 0x7fffe9510700 (LWP 79438)]
[New Thread 0x7fffe8d0f700 (LWP 79439)]
[New Thread 0x7fffcbfff700 (LWP 79440)]
[New Thread 0x7fffcb7fe700 (LWP 79441)]
[New Thread 0x7fffcaffd700 (LWP 79442)]
[New Thread 0x7fffca7fc700 (LWP 79443)]
[Switching to Thread 0x76c2c040 (LWP 79431)]
Thread 2.1 "asy" hit Temporary breakpoint 2, trEndTile (tr=0x1) at tr.cc:369
369 {
Breakpoint 3 at 0x719e2300: file
../src/compiler/glsl/builtin_functions.cpp, line 1280.
Continuing.
[Detaching after fork from child process 79444]
[Thread 0x7fffcaffd700 (LWP 79442) exited]
[Thread 0x7fffcb7fe700 (LWP 79441) exited]
[Thread 0x7fffca7fc700 (LWP 79443) exited]
[Thread 0x7fffcbfff700 (LWP 79440) exited]
Thread 2.1 "asy" hit Breakpoint 3, (anonymous
namespace)::builtin_builder::~builtin_builder (this=0x72a26fd0 ,
__in_chrg=) at ../src/compiler/glsl/builtin_functions.cpp:1280
1280 ralloc_free(mem_ctx);
#0 (anonymous namespace)::builtin_builder::~builtin_builder
(this=0x72a26fd0 , __in_chrg=) at
../src/compiler/glsl/builtin_functions.cpp:1280
#1 0x7733a4d7 in __run_exit_handlers (status=0, listp=0x774ba718
<__exit_funcs>, run_list_atexit=run_list_atexit@entry=true,
run_dtors=run_dtors@entry=true) at exit.c:108
#2 0x7733a67a in __GI_exit (status=) at exit.c:139
#3 0x55863ae2 in gl::quit () at glrender.cc:652
#4 0x55868ebf in gl::glrender (prefix='\000' ,
"\001", '\000' , "P\210\327UUU", '\000' ,
"\377\377\377\377\000\000\000\000\004\000\005", '\000' ...,
pic=0x0, format=Python Exception int too big to
convert:
, width=0, height=29163520, angle=1.7292297604443629e-322, zoom=0, m=...,
M=..., shift=..., margin=..., t=0x55a1d260, background=0x55a0eb00,
nlightsin=140737488308064, lights=0x7481f548, diffuse=0x7481f3f0,
specular=0x7481f230, view=false, oldpid=0) at glrender.cc:1866
#5 0x555fb01a in camp::picture::shipout3
Bug#983487: Asymptote error message concerning malloc (Bug#983487)
Am 15.03.21 um 14:10 schrieb Bernhard Übelacker: otherwise I got a SIGFPE A short offtopic side note to rr sensing this SIGFPE, not directly related to the malloc message: This can also be seen in a process without being recorded by rr by setting LP_NUM_THREADS to zero, so operations take place without worker threads. So this might be an additional llvmpipe issue? export LP_NUM_THREADS=0 gdb -q \ -ex 'tb camp::picture::shipout3' \ -ex 'set width 0' \ -ex 'set pagination off' \ -ex 'directory /home/benutzer/source/libgl1-mesa-dri/orig/mesa-20.3.4/src' \ -ex 'display/i $pc' \ -ex 'run' \ -ex 'set breakpoint pending on' \ -ex 'tb lp_rast.c:481' \ -ex 'b lp_rast_shade_quads_mask_sample+484' \ -ex 'set follow-fork-mode child' \ -ex 'cont' \ -ex 'bt' \ -ex 'finish' \ --args /usr/bin/asy -config "" -render=4 -f png -o B_b.png B_b.asy Thread 2.1 "asy" received signal SIGFPE, Arithmetic exception. 0x77fc2df1 in ?? () 1: x/i $pc => 0x77fc2df1: vdivps %ymm0,%ymm5,%ymm1 #0 lp_rast_shade_quads_mask_sample (task=task@entry=0x55aab538, inputs=inputs@entry=0x565105f0, x=x@entry=36, y=100, mask=17476) at ../src/gallium/drivers/llvmpipe/lp_rast.c:481 #1 0x71d0713d in do_block_4_3 (c=, y=, x=, plane=, tri=, task=) at ../src/gallium/drivers/llvmpipe/lp_rast_tri_tmp.h:88 #2 do_block_16_3 (c=0x7fff4270, y=96, x=32, plane=0x7fff42b0, tri=, task=0x55aab538) at ../src/gallium/drivers/llvmpipe/lp_rast_tri_tmp.h:173 #3 lp_rast_triangle_3 (task=, arg=...) at ../src/gallium/drivers/llvmpipe/lp_rast_tri_tmp.h:326 #4 0x71d04a16 in do_rasterize_bin (bin=, bin=, x=, y=, task=) at ../src/gallium/drivers/llvmpipe/lp_rast.c:658 #5 rasterize_bin (y=, x=, bin=, task=0x55aab538) at ../src/gallium/drivers/llvmpipe/lp_rast.c:677 #6 rasterize_scene (task=task@entry=0x55aab538, scene=scene@entry=0x7fffea222010) at ../src/gallium/drivers/llvmpipe/lp_rast.c:738 #7 0x71d0521b in lp_rast_queue_scene (rast=0x55aab520, scene=scene@entry=0x7fffea222010) at ../src/gallium/drivers/llvmpipe/lp_rast.c:786 #8 0x71d11645 in lp_setup_rasterize_scene (setup=0x55b55120) at ../src/gallium/drivers/llvmpipe/lp_setup.c:181 #9 set_scene_state (setup=setup@entry=0x55b55120, new_state=new_state@entry=SETUP_FLUSHED, reason=) at ../src/gallium/drivers/llvmpipe/lp_setup.c:332 #10 0x71d11ef3 in lp_setup_flush (setup=0x55b55120, fence=0x0, reason=) at ../src/gallium/drivers/llvmpipe/lp_setup.c:361 #11 0x7173ac49 in st_flush (flags=0, fence=0x0, st=0x55d23de0) at ../src/mesa/state_tracker/st_cb_flush.c:60 #12 st_glFlush (ctx=) at ../src/mesa/state_tracker/st_cb_flush.c:101 #13 0x5586c9ed in trEndTile (tr=0x5632b620) at tr.cc:378 ...
Bug#983487: Asymptote error message concerning malloc (Bug#983487)
Hello everyone, I tried to reproduce this issue inside a minimal qemu VM, with an available X server, and investigate with the help of rr-debugger and valgrind. First in camp::picture::shipout3, line 1404 the process asy forks, and following failure happens in the child thereof. In the backtrace [1] the malloc error is written. This happens while being inside a signal handler of a SIGSEGV, which attempts to to log something. As far as I understand are such complex things inside a signal handler likely to fail. The SIGSEGV before seems to be caused because by a double free, once in builtin_builder::release [2] and before that, once in builtin_builder::~builtin_builder [3], both below the __run_exit_handlers. Maybe the order of the exit handlers is important here? This also shows up with valgrind at the bottom of the run. rr was working with current git head and the environment LP_NO_RAST=1 set, otherwise I got a SIGFPE, which might be an issue in rr. It seems to depend on using the mesa software renderer. Therefore it may be better reproducible on regular desktops with e.g. LIBGL_ALWAYS_SOFTWARE=true and GALLIUM_DRIVER=llvmpipe. In my test VM with GALLIUM_DRIVER=softpipe it shows "malloc_consolidate(): invalid chunk size", but have not followed that further. Kind regards, Bernhard [1] (rr) bt #0 malloc_printerr (str=str@entry=0x7f76cc2c6678 "malloc(): unsorted double linked list corrupted") at malloc.c:5347 #1 0x7f76cc1bfd74 in _int_malloc (av=av@entry=0x7f76cc2f5b80 , bytes=bytes@entry=8192) at malloc.c:3744 #2 0x7f76cc1c1299 in __GI___libc_malloc (bytes=bytes@entry=8192) at malloc.c:3066 #3 0x7f76cc5220b5 in operator new (sz=8192) at ../../../../src/libstdc++-v3/libsupc++/new_op.cc:50 #4 0x7f76cc5220f5 in operator new[] (sz=) at ../../../../src/libstdc++-v3/libsupc++/new_opv.cc:32 #5 0x7f76cc57c0b4 in std::basic_filebuf >::_M_allocate_internal_buffer (this=0x7ffc31779080) at /build/gcc-10-Km9U7s/gcc-10-10.2.1/build/x86_64-linux-gnu/libstdc++-v3/include/bits/fstream.tcc:49 #6 std::basic_filebuf >::_M_allocate_internal_buffer (this=0x7ffc31779080) at /build/gcc-10-Km9U7s/gcc-10-10.2.1/build/x86_64-linux-gnu/libstdc++-v3/include/bits/fstream.tcc:49 #7 0x7f76cc57ffe3 in std::basic_filebuf >::open (this=0x7ffc31779080, __s=0x7f76ca30f860 "/usr/share/asymptote/three.asy", __mode=std::_S_in) at /build/gcc-10-Km9U7s/gcc-10-10.2.1/build/x86_64-linux-gnu/libstdc++-v3/include/bits/fstream.tcc:188 #8 0x55744bd819b9 in std::basic_ifstream >::open (__mode=, __s=, this=) at /usr/include/c++/10/bits/ios_base.h:130 #9 std::basic_ifstream >::basic_ifstream (__mode=, __s=, this=, __in_chrg=, __vtt_parm=) at /usr/include/c++/10/fstream:533 #10 operator<< (out=..., pos=...) at errormsg.cc:30 #11 0x55744bd81fd6 in errorstream::message (this=0x55744bef6270 , pos=..., s="runtime: ") at errormsg.cc:63 #12 0x55744bd8220a in errorstream::runtime (this=0x55744bef6270 , pos=...) at errormsg.cc:81 #13 0x55744be12ce6 in sigsegv_handler (emergency=) at main.cc:78 #14 sigsegv_handler (emergency=1277376864) at main.cc:75 #15 0x7f7682d0 in sigsegv_handler (sig=, sip=, ucp=0x7ffc31779440) at handler-unix.c:267 #16 #17 0x7f76c6b532cf in unsafe_free (info=0x55744c2662a0) at ../src/util/ralloc.c:307 #18 0x7f76c6b538a2 in unsafe_free (info=) at ../src/util/ralloc.c:308 #19 ralloc_free (ptr=0x55744c2339a0) at ../src/util/ralloc.c:278 #20 ralloc_free (ptr=0x55744c2339a0) at ../src/util/ralloc.c:269 #21 0x7f76c6a94b8c in (anonymous namespace)::builtin_builder::release (this=0x7f76c7aacfd0 ) at ../src/compiler/glsl/builtin_functions.cpp:1326 #22 _mesa_glsl_builtin_functions_decref () at ../src/compiler/glsl/builtin_functions.cpp:7759 #23 0x7f76c6831245 in _mesa_free_context_data (ctx=ctx@entry=0x7f76be008010, destroy_debug_output=destroy_debug_output@entry=false) at ../src/mesa/main/context.c:1402 #24 0x7f76c67c2a87 in st_destroy_context (st=0x55744c4aa880) at ../src/mesa/state_tracker/st_context.c:1146 #25 0x7f76c67a495e in dri_destroy_context (cPriv=) at ../src/gallium/frontends/dri/dri_context.c:247 #26 0x7f76c6ca3903 in driDestroyContext (pcp=0x55744c1ca700) at ../src/mesa/drivers/dri/common/dri_util.c:533 #27 0x7f76ca5d1a7f in drisw_destroy_context (context=0x55744c1ca570) at ../src/glx/drisw_glx.c:379 #28 0x7f76ca5d722e in glx_display_free (priv=priv@entry=0x55744c1c1a90) at ../src/glx/glxext.c:245 #29 0x7f76ca5d72bf in __glXCloseDisplay (dpy=0x55744c1a7870, codes=) at ../src/glx/glxext.c:304 #30 0x7f76cc00cbc2 in XCloseDisplay (dpy=0x55744c1a7870) at ../../src/ClDisplay.c:65 #31 0x7f76ccceda7f in fgDeinitialize () at freeglut_init.c:524 #32 fgDeinitialize () at freeglut_init.c:411 #33 0x7f76cc1754d7 in __run_exit_handlers (status=0,
Bug#985194: konsole: blue bar on the left side when text is scrolling
Hello Sandro, hello Norbert, this sounds like the feature "Highlight lines coming into view" [1]. There is an option that looks like it could be disabled in: Profiles - Scrollbars - "Highlight the lines coming into view" Kind regards, Bernhard https://invent.kde.org/utilities/konsole/-/commit/dabac1f47ead4626f0ff83affb851309f10a6e58
Bug#983377: libssh: autopkg test fails with valgrind error on armhf qemu testbed
Hello Ryutaroh Matsumoto, dear Maintainer,
I am not involved in packaging valgrind, just trying to
help with some random bug reports.
For this report #983377 I cannot follow, how #928224 is blocking it?
#928224 is about valgrind not running at all,
with "a function redirection ... cannot be set up" and exits.
This was not reproducible for me in 2019 inside a VM.
#983377 has "disInstr(thumb): unhandled instruction: 0xEC51 0x0F1E",
which seems to be tracked upstream in [1].
A valgrind package build with the patch [2] from this bug does
not show this "unhandled instruction" message anymore.
The instruction seems to be on purpose by openssl [3]
to detect certain cpu features.
[1] https://bugs.kde.org/show_bug.cgi?id=344802
[2] https://bugs.kde.org/attachment.cgi?id=113735
[3] https://sources.debian.org/src/openssl/1.1.1j-1/crypto/armcap.c/#L224
Program received signal SIGILL, Illegal instruction.
_armv7_tick () at crypto/armv4cpuid.S:136
136 crypto/armv4cpuid.S: Datei oder Verzeichnis nicht gefunden.
1: x/i $pc
=> 0x4b9f926 <_armv7_tick>: mrrc15, 1, r0, r1, cr14
(gdb) bt
#0 _armv7_tick () at crypto/armv4cpuid.S:136
#1 0x04b9a0fa in OPENSSL_cpuid_setup () at ../crypto/armcap.c:224
#2 0x0400bf40 in call_init (l=, argc=argc@entry=6,
argv=argv@entry=0xbdf1c624, env=env@entry=0xbdf1c640) at dl-init.c:72
#3 0x0400bfe2 in call_init (env=, argv=, argc=, l=) at dl-init.c:30
#4 _dl_init (main_map=0x402a9b8, argc=6, argv=0xbdf1c624, env=0xbdf1c640) at
dl-init.c:119
#5 0x04000ac4 in _dl_start_user () from /lib/ld-linux-armhf.so.3
#983377 shows also multiple "Invalid write ... below stack pointer".
Might this be kind of a stack protection?
There is an upstream bug describing something similar in Android
and there was a way to silence such access integrated:
'--ignore-range-below-sp=1152-0'.
Maybe related, in [5] it looks like gcc was starting to emit
stack protection instructions in 2017.
[4] https://bugs.kde.org/show_bug.cgi?id=360571
[5] https://bugzilla.redhat.com/show_bug.cgi?id=1522678
Kind regards,
Bernhard
valgrind --vgdb=yes --vgdb-error=0
/home/benutzer/autopkgtest.7hddQs/autopkgtest_tmp/mock-sshd --user=joe
--password=foobar --port 1234 -v
gdb -q /home/benutzer/autopkgtest.7hddQs/autopkgtest_tmp/mock-sshd
target remote | vgdb
==30911== Invalid write of size 4
==30911==at 0x4964BF6: libssh_constructor (init.c:111)
==30911==by 0x400BF3F: call_init.part.0 (dl-init.c:72)
==30911==by 0x400BFE1: call_init (dl-init.c:30)
==30911==by 0x400BFE1: _dl_init (dl-init.c:119)
==30911==by 0x4000AC3: ??? (in /usr/lib/arm-linux-gnueabihf/ld-2.31.so)
==30911== Address 0xbda4d650 is on thread 1's stack
==30911== 8 bytes below stack pointer
==30911==
==30911== (action on error) vgdb me ...
Program received signal SIGTRAP, Trace/breakpoint trap.
0x04964bf6 in libssh_constructor () at ./src/init.c:111
111 {
1: x/i $pc
=> 0x4964bf6 : str.w r0, [r12, #4088]; 0xff8
(gdb) disassemble libssh_constructor,libssh_constructor+40
Dump of assembler code from 0x4964bec to 0x4964c14:
0x04964bec : push{r4, lr}
0x04964bee : mov.w r12, #4096 ; 0x1000
0x04964bf2 : sub.w r12, sp, r12
=> 0x04964bf6 : str.w r0, [r12, #4088]; 0xff8
0x04964bfa : ldr r2, [pc, #84] ; (0x4964c50
)
0x04964bfc : ldr r4, [pc, #84] ; (0x4964c54
)
0x04964bfe : add r2, pc
End of assembler dump.
(gdb) print/x $r0
$1 = 0x6
(gdb) print/x $r12
$2 = 0xbda4c658
(gdb) print/x $sp
$3 = 0xbda4d658
(gdb) print/x $pc
$4 = 0x4964bf7
(gdb) bt
#0 0x04964bf6 in libssh_constructor () at ./src/init.c:111
#1 0x0400bf40 in call_init (l=, argc=argc@entry=6,
argv=argv@entry=0xbda4d6a4, env=env@entry=0xbda4d6c0) at dl-init.c:72
#2 0x0400bfe2 in call_init (env=, argv=, argc=, l=) at dl-init.c:30
#3 _dl_init (main_map=0x402a9b8, argc=6, argv=0xbda4d6a4, env=0xbda4d6c0) at
dl-init.c:119
#4 0x04000ac4 in _dl_start_user () from /lib/ld-linux-armhf.so.3
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
Bug#977043: fwupdmgr[1191] trap invalid opcode ip:4247d0 sp:bf98504c error:0 in fwupdmgr[423000+15000]
Hello Martin-Éric, without being involved in packaging fwupd I tried to have a look at this issue. I could not reproduce it inside a i386 qemu VM (not even with "-cpu pentium"). Have not tested on real hardware. Looking up the endbr32 instruction, it seems it belongs to something called "Control-flow Enforcement Technology" (CET, indirect branch) [1]. The opcode for this instruction got selected to run on old CPUs as NOP, but it looks like your CPU handles it differently. From the system name it is some "geode" CPU? (In [2] someone mentions also a illegal instruction for a geode CPU with the endbr32 instruction.) Maybe you could add to this bug report the output of 'lscpu' or 'cat /proc/cpuinfo' ? Then the maintainer might be able to tell if this CPU meets the Debian baseline requirements for bullseye. ([3], maybe outdated? Is there a better "baseline" description?) Kind regards, Bernhard [1] https://www.linuxplumbersconf.org/event/2/contributions/147/attachments/72/83/CET-LPC-2018.pdf [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84148#c3 [3] https://wiki.debian.org/ArchitectureSpecificsMemo#i386-1
Bug#982049: gdbserver: 32-bit segments are not set properly?
Dear Maintainer, tried to reproduce this issue inside a minimal qemu VM and found that this starts to manifest with kernel version 5.9. Using a kernel 5.8 with current testing userland does not show this issue. These tests were done with qemu parameter "-cpu host". Without any cpu parameter I could not detect this fault in this VM. Unfortunately I read the linked issue too late were investigation continued already (and points to a gdb upstream patch), so this seems to be a feature, added to the kernel, uncovering this bug in gdbserver. Building a gdb package, with this upstream patch included, does not show this issue. Kind regards, Bernhard
