Bug#1070687: systemsettings: received signal SIGSEGV, Segmentation fault
On Tue, 07 May 2024 11:30:41 +0200 antonio wrote: Dear Maintainer, when I try to add a online account (Systemsettings->Pesonalization->Online Accounts->Add new account... button) I get this error: Thread 1 "systemsettings" received signal SIGSEGV, Segmentation fault. 0x7fffc40f8765 in Accounts::Provider::~Provider() () from /usr/lib/x86_64-linux-gnu/libaccounts-qt5.so.1 where: libaccounts-qt5-1=1.17-1 Dear Maintainer, I still can reproduce this with current Trixie/testing [1] [2]. The crash seems to happen because for some reason the member m_tags contains an invalid pointer 0x1 [3]. With rr-debugger I could record such a crash and reverse execute to where m_tags got overwritten with this 0x1 [4]. Unfortunately I still cannot tell the exact reason, because the crash no longer happens with a locally rebuilt package libkaccounts2. Therefore, might this be an ABI break? And could be solved by a binNMU of libkaccounts2? Kind regards, Bernhard [1] #4 #5 0x7f1fb43a2765 in Accounts::Provider::~Provider() () from /lib/x86_64-linux-gnu/libaccounts-qt5.so.1 #6 0x7f1fb43bf198 in ProvidersModel::data(QModelIndex const&, int) const () from /lib/x86_64-linux-gnu/libkaccounts.so.2 #7 0x7f1fce9d44f0 in ?? () from /lib/x86_64-linux-gnu/libQt5QmlModels.so.5 [2] With debug symbols: #4 #5 std::__atomic_base::load (__m=std::memory_order_relaxed, this=) at /usr/include/c++/13/bits/atomic_base.h:503 #6 QAtomicOps::loadRelaxed (_q_value=) at /usr/include/x86_64-linux-gnu/qt5/QtCore/qatomic_cxx11.h:239 #7 QBasicAtomicInteger::loadRelaxed (this=) at /usr/include/x86_64-linux-gnu/qt5/QtCore/qbasicatomic.h:107 #8 QtPrivate::RefCount::deref (this=) at /usr/include/x86_64-linux-gnu/qt5/QtCore/qrefcount.h:66 #9 QHash::~QHash (this=0x1, __in_chrg=) at /usr/include/x86_64-linux-gnu/qt5/QtCore/qhash.h:250 #10 QSet::~QSet (this=0x1, __in_chrg=) at /usr/include/x86_64-linux-gnu/qt5/QtCore/qset.h:53 #11 Accounts::Provider::~Provider (this=, __in_chrg=) at ./Accounts/provider.cpp:93 #12 0x7f1fb43bf198 in ProvidersModel::data (this=, index=..., role=) at ./src/lib/providersmodel.cpp:105 #13 0x7f1fce9d44f0 in QModelIndex::data (arole=261, this=0x7ffddfe29ce0) at /usr/include/x86_64-linux-gnu/qt5/QtCore/qabstractitemmodel.h:460 [3] 93 delete m_tags; (rr) print this $1 = (Accounts::Provider * const) 0x7ffc316dca20 (rr) print *this $2 = {m_provider = 0x55b1af209730, m_tags = 0x1} (rr) print >m_tags $4 = (QSet **) 0x7ffc316dca28 [4] (rr) watch *0x7ffc316dca28 Hardware watchpoint 1: *0x7ffc316dca28 (rr) reverse-cont Continuing. Thread 1 hit Hardware watchpoint 1: *0x7ffc316dca28 Old value = 1 New value = 0 0x7f97bc1bc223 in ProvidersModel::data (this=0x55b1af23c460, index=..., role=261) at ./src/lib/providersmodel.cpp:86 86 data.setValue(!provider.isSingleAccount()); (rr) bt #0 0x7f97bc1bc223 in ProvidersModel::data(QModelIndex const&, int) const (this=0x55b1af23c460, index=, role=261) at ./src/lib/providersmodel.cpp:86 #1 0x7f97c8a6f4f0 in QModelIndex::data(int) const (arole=261, this=0x7ffc316dcac0) at /usr/include/x86_64-linux-gnu/qt5/QtCore/qabstractitemmodel.h:460 #2 QQmlDMAbstractItemModelData::value(int) const (role=261, this=0x55b1af0f5610) at ./src/qmlmodels/qqmladaptormodel.cpp:414 #3 QQmlDMCachedModelData::metaCall(QMetaObject::Call, int, void**) (this=0x55b1af0f5610, call=, id=, arguments=0x7ffc316dcb70) at ./src/qmlmodels/qqmladaptormodel.cpp:282 #4 0x7f97cada4fd6 in () at /lib/x86_64-linux-gnu/libQt5Qml.so.5
Bug#1070220: jbig2: broken manual page: src/jbig2: error while loading shared libraries: libjbig2enc.so.0: cannot open shared object file: No such file or directory
On Thu, 02 May 2024 12:28:29 +0800 Paul Wise wrote: The jbig2 manual page is broken. Looks like it was generated via help2man using the binary in the build tree but without using LD_LIBRARY_PATH so the binary could not find libraries it uses, so jbig2 could not start, so it didn't print the usage statement and help2man did not convert the usage statement to a manual page. The help2man conversion in debian/rules may have some kind of problem. Hello, it looks like make is not exporting the variable by default to the environment of subprocesses. This could be achieved by adding the below export [1]. Another way would be to move the LD_LIBRARY_PATH assignment to the same line of help2man [2]. Kind regards, Bernhard [1] --- orig/jbig2enc-0.29/debian/rules 2024-02-28 14:02:09.0 +0100 +++ try5/jbig2enc-0.29/debian/rules 2024-05-18 11:13:29.796407931 +0200 @@ -53,2 +53,3 @@ override_dh_installchangelogs: jbig2.1: LD_LIBRARY_PATH = src/.libs +export LD_LIBRARY_PATH jbig2.1: %.1: src/% [2] --- orig/jbig2enc-0.29/debian/rules 2024-02-28 14:02:09.0 +0100 +++ try2/jbig2enc-0.29/debian/rules 2024-05-18 10:07:46.877615011 +0200 @@ -52,5 +52,4 @@ override_dh_installchangelogs: # build manpages -jbig2.1: LD_LIBRARY_PATH = src/.libs jbig2.1: %.1: src/% - help2man --section 1 --no-info --no-discard-stderr \ + LD_LIBRARY_PATH=src/.libs help2man --section 1 --no-info --no-discard-stderr \ --name "encoder for JBIG2" \
Bug#1040375: /usr/lib/x86_64-linux-gnu/simplescreenrecorder/libssr-glinject.so: Segmentation fault when used with anything
On Sat, 10 Feb 2024 11:01:54 +0100 Petter Reinholdtsen wrote: [Petter Reinholdtsen] > I do not use ssr much myself, and have not had time to test. I applied the upstream commit in git branch fix-1040375-glinject and tested it on Bookworm, but alas, the .so file still segfaults with a useless backtrace. I might have applied the commit incorrectly, as it did not apply without changes, but hope not. Perhaps someone who understand what is happening can have a look? -- Happy hacking Petter Reinholdtsen Hello, looking through some bugs about crashes I came to this one and found found it interesting. If a proper backtrace is still helping one can get one by using systemd-coredump. Another nice way to debug early startup is using rr debugger. (Plus the ability to debug back and forth.) As far as I see the crash happens because it wants to print this message: 57 GLINJECT_PRINT("Error: Can't open libdl.so!"); But unfortunately libstdc++ seems not yet prepared to output the error. (rr) bt #0 0x7fbf7ff2fd9a in std::basic_ostream >::sentry::sentry(std::basic_ostream >&) () from /lib/x86_64-linux-gnu/libstdc++.so.6 #1 0x7fbf7ff3074c in std::basic_ostream >& std::__ostream_insert >(std::basic_ostream >&, char const*, long) () from /lib/x86_64-linux-gnu/libstdc++.so.6 #2 0x7fbf7ff30bdb in std::basic_ostream >& std::operator<< >(std::basic_ostream >&, char const*) () from /lib/x86_64-linux-gnu/libstdc++.so.6 #3 0x7fbf805cef6f in InitGLInject () at ./glinject/Hook.cpp:57 #4 0x7fbf805cf13f in dlsym (handle=0x7fbf8060d2e0, symbol=0x7fbf80185f7a "pthread_create") at ./glinject/Hook.cpp:231 #5 0x7fbf80136dd7 in glvndSetupPthreads () at ../src/util/glvnd_pthread.c:452 #6 0x7fbf801351a9 in __glDispatchOnLoadInit () at ../src/GLdispatch/GLdispatch.c:174 #7 0x7fbf805de9ce in call_init (env=0x7ffeea4b1538, argv=0x7ffeea4b1528, argc=1, l=) at ./elf/dl-init.c:74 #8 call_init (l=, argc=1, argv=0x7ffeea4b1528, env=0x7ffeea4b1538) at ./elf/dl-init.c:26 #9 0x7fbf805deab4 in _dl_init (main_map=0x7fbf8060d2e0, argc=1, argv=0x7ffeea4b1528, env=0x7ffeea4b1538) at ./elf/dl-init.c:121 #10 0x7fbf805f4a70 in _dl_start_user () from /lib64/ld-linux-x86-64.so.2 #11 0x0001 in ?? () #12 0x7ffeea4b25ea in ?? () #13 0x in ?? () (rr) (For some reason with libstdc++6-dbgsym the backtrace gets less good.) I guess upstream discussed this issue here: https://github.com/MaartenBaert/ssr/issues/947 And a package built from `fix-1040375-glinject` did no longer show this crash to me. Attached file shows my actions inside a minimal bookworm VM. Kind regards, Bernhard # 2024-05-07 Bookworm/stable amd64 qemu VM apt update apt dist-upgrade apt install systemd-coredump mc gdb rr mesa-utils git simplescreenrecorder-lib simplescreenrecorder-lib-dbgsym libglvnd0-dbgsym libstdc++6-dbgsym appstream apt build-dep simplescreenrecorder-lib mkdir /home/benutzer/source/simplescreenrecorder/orig -p cd/home/benutzer/source/simplescreenrecorder/orig apt source simplescreenrecorder benutzer@debian:~$ LD_PRELOAD=/usr/lib/x86_64-linux-gnu/simplescreenrecorder/libssr-glinject.so /usr/bin/true Speicherzugriffsfehler (Speicherabzug geschrieben) benutzer@debian:~$ benutzer@debian:~$ coredumpctl list Hint: You are currently not seeing messages from other users and the system. Users in groups 'adm', 'systemd-journal' can see all messages. Pass -q to turn off this notice. TIME PID UID GID SIG COREFILE EXESIZE Tue 2024-05-07 00:10:28 CEST 994 1000 1000 SIGSEGV present /usr/bin/true 89.0K benutzer@debian:~$ benutzer@debian:~$ coredumpctl gdb --debugger-argument=-q 994 Hint: You are currently not seeing messages from other users and the system. Users in groups 'adm', 'systemd-journal' can see all messages. Pass -q to turn off this notice. PID: 994 (true) UID: 1000 (benutzer) GID: 1000 (benutzer) Signal: 11 (SEGV) Timestamp: Tue 2024-05-07 00:10:28 CEST (1min 26s ago) Command Line: /usr/bin/true Executable: /usr/bin/true 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: 4df23299079540e38e42560b3966b576 Machine ID: 55a5ad9df1d547f38d7696343d9fde7d Hostname: debian Storage: /var/lib/systemd/coredump/core.true.1000.4df23299079540e38e42560b3966b576.994.171503342800.zst (present) Size on Disk: 89.0K Message: Process 994 (true) of user 1000 dumped core. Stack trace of thread 994: #0 0x7f988d92fd9a _ZNSo6sentryC1ERSo (libstdc++.so.6 + 0x12fd9a) #1 0x7f988d93074c _ZSt16__ostream_insertIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_PKS3_l (libstdc++.so.6 + 0x13074c)
Bug#1054080: stlcmd: stl_boolean segfaults on some inputs
Hello, I am not maintainer of stlcmd, just tried to collect some more information. This crash seems to be a stack overflow because of a recursive function call. There is a comment near that recursive call, which could be interesting here. And this issue seems not to be a packaging issue in Debian, therefore it might be better to report this issue upstream in [2]. Kind regards, Bernhard [1] https://github.com/AllwineDesigns/stl_cmd/blob/7c2582864df1c10d11f5acb4901fb04c55ea7492/src/csgjs/Trees.cpp#L44-L55 [2] https://github.com/AllwineDesigns/stl_cmd/issues Core was generated by `stl_boolean -a one.stl -b intersection.stl -d one-additions.stl'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x7fe2a95c855e in _int_malloc (av=av@entry=0x7fe2a9712b80 , bytes=bytes@entry=512) at malloc.c:3637 3637malloc.c: Datei oder Verzeichnis nicht gefunden. (gdb) bt #0 0x7fe2a95c855e in _int_malloc (av=av@entry=0x7fe2a9712b80 , bytes=bytes@entry=512) at malloc.c:3637 #1 0x7fe2a95c9de4 in __GI___libc_malloc (bytes=512) at malloc.c:3058 #2 0x7fe2a991c0b5 in operator new(unsigned long) () from /lib/x86_64-linux-gnu/libstdc++.so.6 #3 0x56309140a744 in __gnu_cxx::new_allocator::allocate (this=, __n=) at /usr/include/c++/7/ext/new_allocator.h:111 #4 std::allocator_traits >::allocate (__a=..., __n=) at /usr/include/c++/7/bits/alloc_traits.h:436 #5 std::_Vector_base >::_M_allocate (this=0x210, this@entry=0x7fff7ccf8470, __n=) at /usr/include/c++/7/bits/stl_vector.h:172 #6 std::vector >::_M_realloc_insert (this=this@entry=0x7fff7ccf8470, __position=, __args#0=@0x7fff7ccf82a0: 0x563093c75b00) at /usr/include/c++/7/bits/vector.tcc:406 #7 0x56309140a84b in std::vector >::emplace_back (this=this@entry=0x7fff7ccf8470, __args#0=@0x7fff7ccf82a0: 0x563093c75b00) at /usr/include/c++/7/bits/vector.tcc:105 #8 0x563091409a9a in std::vector >::push_back (__x=@0x7fff7ccf82a0: 0x563093c75b00, this=0x7fff7ccf8470) at /usr/include/c++/7/bits/stl_vector.h:954 #9 csgjs::PolygonTreeNode::splitPolygonByPlane (this=this@entry=0x563093c75b00, plane=..., coplanarFrontNodes=std::vector of length 0, capacity 0, coplanarBackNodes=std::vector of length 32, capacity 32 = {...}, frontNodes=std::vector of length 0, capacity 0, backNodes=std::vector of length 32, capacity 32 = {...}) at src/csgjs/Trees.cpp:298 #10 0x563091409d7c in csgjs::PolygonTreeNode::splitLeafByPlane (this=0x563093c75b00, plane=..., coplanarFrontNodes=std::vector of length 0, capacity 0, coplanarBackNodes=std::vector of length 32, capacity 32 = {...}, frontNodes=std::vector of length 0, capacity 0, backNodes=std::vector of length 32, capacity 32 = {...}) at src/csgjs/Trees.cpp:239 #11 0x563091409f67 in csgjs::Node::addPolygonTreeNodes (this=this@entry=0x563096390cc0, polyTreeNodes=std::vector of length 60, capacity 64 = {...}) at src/csgjs/Trees.cpp:40 #12 0x56309140a061 in csgjs::Node::addPolygonTreeNodes (this=this@entry=0x563096390a50, polyTreeNodes=std::vector of length 60, capacity 64 = {...}) at src/csgjs/Trees.cpp:54 #13 0x56309140a061 in csgjs::Node::addPolygonTreeNodes (this=this@entry=0x5630963907e0, polyTreeNodes=std::vector of length 60, capacity 64 = {...}) at src/csgjs/Trees.cpp:54 #14 0x56309140a061 in csgjs::Node::addPolygonTreeNodes (this=this@entry=0x563096390570, polyTreeNodes=std::vector of length 60, capacity 64 = {...}) at src/csgjs/Trees.cpp:54 #15 0x56309140a061 in csgjs::Node::addPolygonTreeNodes (this=this@entry=0x563096390300, polyTreeNodes=std::vector of length 60, capacity 64 = {...}) at src/csgjs/Trees.cpp:54 ... #65433 0x56309140a061 in csgjs::Node::addPolygonTreeNodes (this=this@entry=0x563093c99510, polyTreeNodes=std::vector of length 60, capacity 64 = {...}) at src/csgjs/Trees.cpp:54 #65434 0x56309140a061 in csgjs::Node::addPolygonTreeNodes (this=this@entry=0x563093c994b0, polyTreeNodes=std::vector of length 60, capacity 64 = {...}) at src/csgjs/Trees.cpp:54 #65435 0x56309140a061 in csgjs::Node::addPolygonTreeNodes (this=this@entry=0x563093c99880, polyTreeNodes=std::vector of length 60, capacity 64 = {...}) at src/csgjs/Trees.cpp:54 #65436 0x56309140a061 in csgjs::Node::addPolygonTreeNodes (this=this@entry=0x563093c99820, polyTreeNodes=std::vector of length 60, capacity 64 = {...}) at src/csgjs/Trees.cpp:54 #65437 0x56309140a061 in csgjs::Node::addPolygonTreeNodes (this=this@entry=0x563093c997c0, polyTreeNodes=std::vector of length 60, capacity 64 = {...}) at src/csgjs/Trees.cpp:54 #65438 0x56309140a061 in csgjs::Node::addPolygonTreeNodes (this=this@entry=0x563093c99720, polyTreeNodes=std::vector of length 113, capacity 128 = {...}) at src/csgjs/Trees.cpp:54 #65439 0x56309140a061 in csgjs::Node::addPolygonTreeNodes (this=this@entry=0x563093c68e20, polyTreeNodes=std::vector of length 497, capacity 512 = {...}) at src/csgjs/Trees.cpp:54 #65440 0x563091409ff8 in
Bug#1054661: blastem: Segfault when trying to open rom or access system settings
On Sat, 28 Oct 2023 12:52:30 +0200 Tobias Frost wrote: Control: tags -1 confirmed Here's a backtrace when clicking on Settings -> System. Thread 1 "blastem" received signal SIGSEGV, Segmentation fault. tern_foreach_int (head=, fun=0x555c12a0 , data=0x7fffd7f0, keybuf=0x7fffd8c0 "\020", pos=0) at /build/blastem-kipVNx/blastem-0.6.3.4/tern.c:268 268 if (!head->el) { (gdb) bt #0 tern_foreach_int (head=, fun=0x555c12a0 , data=0x7fffd7f0, keybuf=0x7fffd8c0 "\020", pos=0) at /build/blastem-kipVNx/blastem-0.6.3.4/tern.c:268 #1 0x555c7e15 in tern_foreach (data=0x7fffd7f0, fun=0x555c12a0 , head=) at /build/blastem-kipVNx/blastem-0.6.3.4/tern.c:291 #2 get_models (num_out=0x557a8ba0 ) at nuklear_ui/blastem_nuklear.c:1873 #3 view_system_settings (context=0x55611ab8 ) at nuklear_ui/blastem_nuklear.c:1907 #4 0x555c8354 in blastem_nuklear_render () at nuklear_ui/blastem_nuklear.c:2049 #5 0x55589e1b in render_update_display () at /build/blastem-kipVNx/blastem-0.6.3.4/render_sdl.c:1783 #6 0x555caeeb in ui_idle_loop () at nuklear_ui/blastem_nuklear.c:2075 #7 0xdefa in blastem_nuklear_init (file_loaded=0 '\000') at nuklear_ui/blastem_nuklear.c:2332 #8 main (argc=, argv=) at /build/blastem-kipVNx/blastem-0.6.3.4/blastem.c:714 (gdb) Did not investigate further. Hello, tried to take a little deeper look. And it seems it is just a missing packaged config file: (rr) 0x55c0356f0361 1012return NULL; 1: x/i $pc => 0x55c0356f0361 : xor%r13d,%r13d 10: /x $r13 = 0x0 (rr) bt #0 0x55c0356f0361 in read_bundled_file (name=name@entry=0x55c03574ae4a "systems.cfg", sizeret=sizeret@entry=0x7ffc07889c88) at /build/blastem-kipVNx/blastem-0.6.3.4/util.c:1012 #1 0x55c0356f0a2d in parse_bundled_config (config_name=0x55c03574ae4a "systems.cfg") at /build/blastem-kipVNx/blastem-0.6.3.4/config.c:217 #2 0x55c03571ff56 in get_systems_config () at /build/blastem-kipVNx/blastem-0.6.3.4/config.c:331 #3 get_models (num_out=0x55c035900ba0 ) at nuklear_ui/blastem_nuklear.c:1866 #4 view_system_settings (context=0x55c035769ab8 ) at nuklear_ui/blastem_nuklear.c:1907 #5 0x55c035720354 in blastem_nuklear_render () at nuklear_ui/blastem_nuklear.c:2049 #6 0x55c0356e1e1b in render_update_display () at /build/blastem-kipVNx/blastem-0.6.3.4/render_sdl.c:1783 #7 0x55c035722eeb in ui_idle_loop () at nuklear_ui/blastem_nuklear.c:2075 #8 0x55c0356b5efa in blastem_nuklear_init (file_loaded=0 '\000') at nuklear_ui/blastem_nuklear.c:2332 #9 main (argc=, argv=) at /build/blastem-kipVNx/blastem-0.6.3.4/blastem.c:714 Function `read_bundled_file` does not find "systems.cfg", therefore returns NULL, therefore `parse_bundled_config` returns also NULL, which is then also returned by `get_systems_config`. This NULL is given unconditionally into tern_foreach in blasem_nuklear.c line 1873, and gets dereferenced. Following change would add systems.cfg to the Debian package, and did avoid the crash in a short test. Kind regards, Bernhard diff -Nurp orig/blastem-0.6.3.4/debian/blastem.install try2/blastem-0.6.3.4/debian/blastem.install --- orig/blastem-0.6.3.4/debian/blastem.install 2021-09-24 22:14:33.0 +0200 +++ try2/blastem-0.6.3.4/debian/blastem.install 2024-05-06 14:31:55.277695226 +0200 @@ -6,3 +6,4 @@ gamecontrollerdb.txtusr/share/games/bl images usr/share/games/blastem rom.db usr/share/games/blastem shadersusr/share/games/blastem +systems.cfgusr/share/games/blastem
Bug#1069598: cifs-utils: When mounting a samba-share by a client with kernel 6.1.0-20-amd64, some subdirectories and files within the mounted share are missing
Hello, this seems to be the same issue as here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1069102 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1069092 And the fix seems to be prepared here: https://salsa.debian.org/kernel-team/linux/-/commit/37a0ac93027302ffbfae41ddc844312e88e72eef Kind regards, Bernhard
Bug#1057620: doomsday: Crashes on startup
On Tue, 05 Dec 2023 23:39:39 + Witold Baryluk wrote: Thread 1 "doomsday" received signal SIGSEGV, Segmentation fault. 0x75419e83 in _XFlush () from /lib/x86_64-linux-gnu/libX11.so.6 (gdb) bt #0 0x75419e83 in _XFlush () at /lib/x86_64-linux-gnu/libX11.so.6 #1 0x7541cb3d in _XGetRequest () at /lib/x86_64-linux-gnu/libX11.so.6 #2 0x7540fa57 in XQueryExtension () at /lib/x86_64-linux-gnu/libX11.so.6 #3 0x75402b16 in XInitExtension () at /lib/x86_64-linux-gnu/libX11.so.6 #4 0x753cdc9b in XextAddDisplay () at /lib/x86_64-linux-gnu/libXext.so.6 #5 0x7538a860 in () at /lib/x86_64-linux-gnu/libXrandr.so.2 #6 0x7538afc0 in XRRQueryExtension () at /lib/x86_64-linux-gnu/libXrandr.so.2 #7 0x7798bae4 in de::internal::RRInfo::RRInfo() () at /lib/x86_64-linux-gnu/libdeng_gui.so.2.3 #8 0x7798b02d in DisplayMode_Native_Init () at /lib/x86_64-linux-gnu/libdeng_gui.so.2.3 #9 0x7791fd11 in DisplayMode_Init () at /lib/x86_64-linux-gnu/libdeng_gui.so.2.3 #10 0x5573eb1d in ClientApp::initialize() () #11 0x5572175d in main () (gdb) Running under gnome shell. xwayland 2:23.2.2-1 Hello, I am not maintainer of the doomsday package, just tried to collect some more information. Bug 1062969 / Bug 1065714 mentions a workaround to be able to run doomsday with wayland: SDL_VIDEODRIVER=x11 QT_QPA_PLATFORM=xcb doomsday https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1062969 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065714 It looks like upstream removed the relevant code and relies just on SDL functions, but unfortunately did not release a new version yet. https://github.com/skyjake/Doomsday-Engine/commit/5cc4995861 Kind regards, Bernhard # 2024-05-05 Trixie/testing amd64 qemu VM apt update apt dist-upgrade apt install systemd-coredump task-gnome-desktop tmux git gdb rr doomsday doomsday-dbgsym doomsday-common-dbgsym libxrandr2-dbgsym libxext6-dbgsym libx11-6-dbgsym apt build-dep libx11-6 mkdir /home/benutzer/source/libx11-6/orig -p cd/home/benutzer/source/libx11-6/orig apt source libx11-6 benutzer@debian:~$ doomsday QSocketNotifier: Can only be used with threads started with QThread Speicherzugriffsfehler (Speicherabzug geschrieben) benutzer@debian:~$ coredumpctl list TIME PID UID GID SIG COREFILE EXE SIZE Sun 2024-05-05 16:04:00 CEST 2967 1000 1000 SIGSEGV present /usr/games/doomsday-2.3.1 2.7M benutzer@debian:~$ coredumpctl gdb --debugger-arguments=-q 2967 Hint: You are currently not seeing messages from other users and the system. Users in groups 'adm', 'systemd-journal' can see all messages. Pass -q to turn off this notice. PID: 2967 (doomsday) UID: 1000 (benutzer) GID: 1000 (benutzer) Signal: 11 (SEGV) Timestamp: Sun 2024-05-05 16:04:00 CEST (1min 51s ago) Command Line: doomsday Executable: /usr/games/doomsday-2.3.1 Control Group: /user.slice/user-1000.slice/user@1000.service/app.slice/app-org.gnome.Terminal.slice/vte-spawn-1c8dc387-bf63-4b3f-9404-fea9f4d9f742.scope Unit: user@1000.service User Unit: vte-spawn-1c8dc387-bf63-4b3f-9404-fea9f4d9f742.scope Slice: user-1000.slice Owner UID: 1000 (benutzer) Boot ID: 13ee1fcd8e5043bf91db85c4d1c72a51 Machine ID: 16e4d7437c19482b8c85581d3feaba09 Hostname: debian Storage: /var/lib/systemd/coredump/core.doomsday.1000.13ee1fcd8e5043bf91db85c4d1c72a51.2967.171491784000.zst (present) Size on Disk: 2.7M Message: Process 2967 (doomsday) of user 1000 dumped core. Module libblkid.so.1 from deb util-linux-2.40-8.amd64 Module libmount.so.1 from deb util-linux-2.40-8.amd64 Module libsystemd.so.0 from deb systemd-255.5-1.amd64 Module libzstd.so.1 from deb libzstd-1.5.5+dfsg2-2.amd64 Stack trace of thread 2967: #0 0x7effce83 _XFlush (libX11.so.6 + 0x44e83) #1 0x7effc0003b3d _XGetRequest (libX11.so.6 + 0x47b3d) #2 0x7effbfff6a57 XQueryExtension (libX11.so.6 + 0x3aa57) #3 0x7effbffe9b16 XInitExtension (libX11.so.6 + 0x2db16) #4 0x7effc1b9bc9b XextAddDisplay (libXext.so.6 + 0xdc9b) #5 0x7effc0ce484f n/a (libXrandr.so.2 + 0x284f) #6 0x7effc0ce4f88 XRRQueryExtension (libXrandr.so.2 + 0x2f88) #7 0x7effc25af3b1 _ZN2de8internal6RRInfoC1Ev (libdeng_gui.so.2.3 + 0xe03b1) #8 0x7effc25ae7ef DisplayMode_Native_Init (libdeng_gui.so.2.3 + 0xdf7ef) #9 0x7effc253e619 DisplayMode_Init (libdeng_gui.so.2.3 + 0x6f619) #10 0x560786a6520d _ZN9ClientApp10initializeEv (doomsday-2.3.1 + 0x1fc20d) #11 0x560786a469d1 main
Bug#1053128: smbclient: "smbtree -N" causes a segfault when "server min protocol = NT1"
Hello, I am not a samba maintainer, just trying to collect some more information. As far as I see the crash happens because "cli_credentials_get_password(creds)" in line 62 returns a null pointer, which gets forwarded to the call to strlcpy without further check. Kind regards, Bernhard (rr) reverse-finish Run back to call of #0 strlcpy (dst=0x7fff875c0640 "", src=0x0, dsize=) at ./src/strlcpy.c:36 0x5574e9c43c8c in get_auth_data_with_context_fn (context=, server=, share=, domain=, domain_len=, user=, user_len=256, password=0x7fff875c0640 "", password_len=256) at source3/utils/smbtree.c:61 61 len = strlcpy( (rr) bt #0 0x5574e9c43c8c in get_auth_data_with_context_fn (context=, server=, share=, domain=, domain_len=, user=, user_len=256, password=0x7fff875c0640 "", password_len=256) at source3/utils/smbtree.c:61 #1 0x7f9851ec6510 in SMBC_call_auth_fn (ctx=ctx@entry=0x5574eb8ba610, context=context@entry=0x5574eb8b7900, server=server@entry=0x5574eb8c9fe0 "10.0.2.15", share=share@entry=0x7f9851ed46a4 "IPC$", pp_workgroup=pp_workgroup@entry=0x7fff875c09b8, pp_username=pp_username@entry=0x7fff875c09a0, pp_password=0x7fff875c09a8) at source3/libsmb/libsmb_server.c:171 ... (rr) list smbtree.c:42 37 38 static void get_auth_data_with_context_fn( 39 SMBCCTX *context, 40 const char *server, 41 const char *share, 42 char *domain, 43 int domain_len, 44 char *user, 45 int user_len, 46 char *password, 47 int password_len) 48 { 49 struct cli_credentials *creds = samba_cmdline_get_creds(); 50 size_t len; 51 52 len = strlcpy(domain, cli_credentials_get_domain(creds), domain_len); 53 if ((int)len >= domain_len) { 54 return; 55 } 56 len = strlcpy( 57 user, cli_credentials_get_username(creds), user_len); 58 if ((int)len >= user_len) { 59 return; 60 } 61 len = strlcpy( 62 password, cli_credentials_get_password(creds), password_len); 63 if ((int)len >= password_len) { 64 /* pointless, but what can you do... */ 65 return; 66 } # 2024-05-04 Trixie/testing amd64 qemu VM apt install systemd-coredump mc gdb rr samba smbclient smbclient-dbgsym libsmbclient0-dbgsym libbsd0-dbgsym apt build-dep samba mkdir /home/benutzer/source/samba/orig -p cd/home/benutzer/source/samba/orig apt source samba mc -e /etc/samba/smb.conf [global] +server min protocol = NT1 testparm -s systemctl enable --now smb systemctl enable --now nmb systemctl restart smbd nmbd # Maybe a minute waiting is needed or this message appears "main: This is utility doesn't work if netbios name resolution is not configured." smbtree -N --option="client min protocol = NT1" benutzer@debian:~$ rr record smbtree -N --option="client min protocol = NT1" rr: Saving execution to trace directory `/home/benutzer/.local/share/rr/smbtree-0'. === INTERNAL ERROR: Signal 11: Speicherzugriffsfehler in smbtree () () pid 9884 (4.19.6-Debian) If you are running a recent Samba version, and if you think this problem is not yet fixed in the latest versions, please consider reporting this bug, see https://wiki.samba.org/index.php/Bug_Reporting === PANIC (pid 9884): Signal 11: Speicherzugriffsfehler in 4.19.6-Debian BACKTRACE: 14 stack frames: #0 /usr/lib/x86_64-linux-gnu/samba/libgenrand-samba4.so.0(log_stack_trace+0x32) [0x7f9851a105c2] #1 /usr/lib/x86_64-linux-gnu/samba/libgenrand-samba4.so.0(smb_panic+0xd) [0x7f9851a1085d] #2 /usr/lib/x86_64-linux-gnu/samba/libgenrand-samba4.so.0(+0x28f5) [0x7f9851a108f5] #3 /lib/x86_64-linux-gnu/libc.so.6(+0x3c510) [0x7f9851acd510] #4 /lib/x86_64-linux-gnu/libbsd.so.0(strlcpy+0x10) [0x7f9851c7f900] #5 /lib/x86_64-linux-gnu/libsmbclient.so.0(+0x14510) [0x7f9851ec6510] #6 /lib/x86_64-linux-gnu/libsmbclient.so.0(+0x14ab1) [0x7f9851ec6ab1] #7 /lib/x86_64-linux-gnu/libsmbclient.so.0(+0x14bdb) [0x7f9851ec6bdb] #8 /lib/x86_64-linux-gnu/libsmbclient.so.0(+0x156e4) [0x7f9851ec76e4] #9 /lib/x86_64-linux-gnu/libsmbclient.so.0(+0xd37f) [0x7f9851ebf37f] #10 smbtree(main+0x262) [0x5574e9c43692] #11 /lib/x86_64-linux-gnu/libc.so.6(+0x276ca) [0x7f9851ab86ca] #12 /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x85) [0x7f9851ab8785] #13 smbtree(_start+0x21) [0x5574e9c43b21] smb_panic(): calling panic action [/usr/share/samba/panic-action 9884] smb_panic(): action returned status 0 Can not dump core: corepath not set up benutzer@debian:~$ benutzer@debian:~$ rr replay --debugger-option=-q smbtree-0 Reading symbols from /usr/bin/smbtree... (No debugging symbols found in
Bug#1057172: baloo-kf5: Baloo Service Crashes After Enabling 'Index File Contents' Option
On Fri, 1 Dec 2023 00:26:27 +0100 Lucy wrote: #3 0x7fbe9c25afd0 __restore_rt (libc.so.6 + 0x3bfd0) #4 0x557d83358770 n/a (baloo_file + 0x13770) #5 0x557d8335885d n/a (baloo_file + 0x1385d) #6 0x557d83365bf1 n/a (baloo_file + 0x20bf1) #7 0x7fbe9cadd6f0 _ZN7QObject5eventEP6QEvent (libQt5Core.so.5 + 0x2dd6f0) Hello, I am not maintainer of baloo-kf5, just just tried to collect some more information. The interesting lines above in the stacktrace translate to this: ... #3 0x7fbe9c25afd0 __restore_rt (libc.so.6 + 0x3bfd0) | #4 0x557d83358770 n/a (baloo_file + 0x13770) | in QString::QString(QString const&) at /usr/include/x86_64-linux-gnu/qt5/QtCore/qstring.h:1093 #5 0x557d8335885d n/a (baloo_file + 0x1385d) | in QList::append(QString const&) at /usr/include/x86_64-linux-gnu/qt5/QtCore/qlist.h:623 #6 0x557d83365bf1 n/a (baloo_file + 0x20bf1) | in Baloo::FileContentIndexer::slotFinishedIndexingFile(QString const&, bool) at ./src/file/filecontentindexer.cpp:125 #7 0x7fbe9cadd6f0 _ZN7QObject5eventEP6QEvent (libQt5Core.so.5 + 0x2dd6f0) | ... Unfortunately this leads just to some upstream bugs, which are not showing much more information. https://bugs.kde.org/show_bug.cgi?id=441860 https://bugs.kde.org/show_bug.cgi?id=443483 https://bugs.kde.org/show_bug.cgi?id=476479 Kind regards, Bernhard Stack trace of thread 1876: #0 0x7fbe9c2a9d3c __pthread_kill_implementation (libc.so.6 + 0x8ad3c) #1 0x7fbe9c25af32 __GI_raise (libc.so.6 + 0x3bf32) #2 0x7fbe9cfabb46 _ZN6KCrash19defaultCrashHandlerEi (libKF5Crash.so.5 + 0x5b46) #3 0x7fbe9c25afd0 __restore_rt (libc.so.6 + 0x3bfd0) #4 0x557d83358770 n/a (baloo_file + 0x13770) #5 0x557d8335885d n/a (baloo_file + 0x1385d) #6 0x557d83365bf1 n/a (baloo_file + 0x20bf1) #7 0x7fbe9cadd6f0 _ZN7QObject5eventEP6QEvent (libQt5Core.so.5 + 0x2dd6f0) #8 0x7fbe9cab16cd _ZN16QCoreApplication15notifyInternal2EP7QObjectP6QEvent (libQt5Core.so.5 + 0x2b16cd) #9 0x7fbe9cab4681 _ZN23QCoreApplicationPrivate16sendPostedEventsEP7QObjectiP11QThreadData (libQt5Core.so.5 + 0x2b4681) #10 0x7fbe9cb0a153 n/a (libQt5Core.so.5 + 0x30a153) #11 0x7fbe9b11e7a9 g_main_context_dispatch (libglib-2.0.so.0 + 0x547a9) #12 0x7fbe9b11ea38 n/a (libglib-2.0.so.0 + 0x54a38) #13 0x7fbe9b11eacc g_main_context_iteration (libglib-2.0.so.0 + 0x54acc) #14 0x7fbe9cb09836 _ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE (libQt5Core.so.5 + 0x309836) #15 0x7fbe9cab017b _ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE (libQt5Core.so.5 + 0x2b017b) #16 0x7fbe9cab82d6 _ZN16QCoreApplication4execEv (libQt5Core.so.5 + 0x2b82d6) #17 0x557d83353982 n/a (baloo_file + 0xe982) #18 0x7fbe9c2461ca __libc_start_call_main (libc.so.6 + 0x271ca) #19 0x7fbe9c246285 __libc_start_main_impl (libc.so.6 + 0x27285) #20 0x557d83353b61 n/a (baloo_file + 0xeb61) Thread 1 (Thread 0x7fbe9ac86540 (LWP 1876)): [KCrash Handler] #5 0x557d83358770 in ?? () #6 0x557d8335885d in ?? () #7 0x557d83365bf1 in ?? () #8 0x7fbe9cadd6f0 in QObject::event(QEvent*) () from /lib/x86_64-linux-gnu/libQt5Core.so.5 #9 0x7fbe9cab16cd in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /lib/x86_64-linux-gnu/libQt5Core.so.5 #10 0x7fbe9cab4681 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () from /lib/x86_64-linux-gnu/libQt5Core.so.5 #11 0x7fbe9cb0a153 in ?? () from /lib/x86_64-linux-gnu/libQt5Core.so.5 #12 0x7fbe9b11e7a9 in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #13 0x7fbe9b11ea38 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #14 0x7fbe9b11eacc in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #15 0x7fbe9cb09836 in QEventDispatcherGlib::processEvents(QFlags) () from /lib/x86_64-linux-gnu/libQt5Core.so.5 #16 0x7fbe9cab017b in QEventLoop::exec(QFlags) () from /lib/x86_64-linux-gnu/libQt5Core.so.5 #17 0x7fbe9cab82d6 in QCoreApplication::exec() () from /lib/x86_64-linux-gnu/libQt5Core.so.5 #18 0x557d83353982 in ?? () #19 0x7fbe9c2461ca in __libc_start_call_main (main=main@entry=0x557d833536e0, argc=argc@entry=1, argv=argv@entry=0x7ffd6ffbbe18) at ../sysdeps/nptl/libc_start_call_main.h:58 #20 0x7fbe9c246285 in __libc_start_main_impl (main=0x557d833536e0, argc=1, argv=0x7ffd6ffbbe18, init=, fini=, rtld_fini=, stack_end=0x7ffd6ffbbe08) at ../csu/libc-start.c:360 #21 0x557d83353b61 in ?? () # 2024-05-04 Bookworm/stable amd64 qemu VM apt install --no-install-recommends --no-install-suggests gdb baloo-kf5 baloo-kf5-dbgsym apt build-dep baloo-kf5 mkdir /home/benutzer/source/baloo-kf5/orig -p cd/home/benutzer/source/baloo-kf5/orig apt source baloo-kf5 gdb -q set width 0 set pagination off directory
Bug#1059041: Xorg segfault when unlocking from Xscreensaver while video playback
On Tue, 19 Dec 2023 20:22:43 +0100 Eduard Bloch wrote: #7 0x7fb14945a510 __restore_rt (libc.so.6 + 0x3c510) #8 0x7fb149186702 n/a (amdgpu_drv.so + 0x16702) #9 0x7fb149186c96 n/a (amdgpu_drv.so + 0x16c96) #10 0x5577d8e75a6b xf86DPMSSet (Xorg + 0xd3a6b) Hello, I am not maintainer of xserver-xorg-video-amdgpu, just tried to collect some more information. The interesting lines above in the stacktrace translate to this: Stack trace of thread 1011552: ... #7 0x7fb14945a510 __restore_rt (libc.so.6 + 0x3c510) | #8 0x7fb149186702 n/a (amdgpu_drv.so + 0x16702) | in drmmode_set_mode at ../../src/drmmode_display.c:1267 #9 0x7fb149186c96 n/a (amdgpu_drv.so + 0x16c96) | in drmmode_set_mode_major at ../../src/drmmode_display.c:1371 #10 0x5577d8e75a6b xf86DPMSSet (Xorg + 0xd3a6b) | in xf86DPMSSet ... This leads to this [1] upstream issue and merge request [2]. Unfortunately this is not yet part of an upstream release. A workaround could be a local build of xserver-xorg-video-amdgpu containing the two commits. They are the first commits after the 23.0.0 release. Kind regards, Bernhard [1] https://gitlab.freedesktop.org/xorg/driver/xf86-video-amdgpu/-/issues/70 [2] https://gitlab.freedesktop.org/xorg/driver/xf86-video-amdgpu/-/merge_requests/85 # 2024-05-04 Trixie/testing amd64 qemu VM apt install gdb xserver-xorg xserver-xorg-video-amdgpu xserver-xorg-core-dbgsym xserver-xorg-video-amdgpu-dbgsym apt build-dep xserver-xorg-video-amdgpu mkdir /home/benutzer/source/xserver-xorg-video-amdgpu/orig -p cd/home/benutzer/source/xserver-xorg-video-amdgpu/orig apt source xserver-xorg-video-amdgpu gdb -q set width 0 set pagination off directory /home/benutzer/source/xserver-xorg-video-amdgpu/orig/xserver-xorg-video-amdgpu-23.0.0/debian/patches file /usr/lib/xorg/Xorg tb main run call dlopen("/usr/lib/xorg/modules/drivers/amdgpu_drv.so",0x101) print (int)getpid() shell cat /proc/2535/maps | grep amdgpu_drv | head -n1 b *(0x774f9000 + 0x16c96) b *(0x774f9000 + 0x16702) info b pipe disassemble drmmode_set_mode_major | grep -i c96 -C3 pipe disassemble drmmode_set_mode | grep -i 702 -C3 list drmmode_display.c:1371 list drmmode_display.c:1267 benutzer@debian:~$ gdb -q (gdb) set width 0 (gdb) set pagination off (gdb) directory /home/benutzer/source/xserver-xorg-video-amdgpu/orig/xserver-xorg-video-amdgpu-23.0.0/debian/patches Source directories searched: /home/benutzer/source/xserver-xorg-video-amdgpu/orig/xserver-xorg-video-amdgpu-23.0.0/debian/patches:$cdir:$cwd (gdb) file /usr/lib/xorg/Xorg Reading symbols from /usr/lib/xorg/Xorg... Reading symbols from /usr/lib/debug/.build-id/77/6f662cfdbd2d0952921614575518e7c1b90261.debug... (gdb) tb main Temporary breakpoint 1 at 0x4d260: file ../../../../dix/stubmain.c, line 33. (gdb) run Starting program: /usr/lib/xorg/Xorg [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=0x7fffe478, envp=0x7fffe488) at ../../../../dix/stubmain.c:33 33 ../../../../dix/stubmain.c: Datei oder Verzeichnis nicht gefunden. (gdb) call dlopen("/usr/lib/xorg/modules/drivers/amdgpu_drv.so",0x101) $1 = (void *) 0x55803a80 (gdb) info inferior Num Description Connection Executable * 1process 2535 1 (native) /usr/lib/xorg/Xorg (gdb) print (int)getpid() $2 = 2535 (gdb) shell cat /proc/2535/maps | grep amdgpu_drv | head -n1 774f9000-7750 r--p 08:12 681046 /usr/lib/xorg/modules/drivers/amdgpu_drv.so (gdb) b *(0x774f9000 + 0x16c96) Breakpoint 2 at 0x7750fc96: file ../../src/drmmode_display.c, line 1371. (gdb) b *(0x774f9000 + 0x16702) Breakpoint 3 at 0x7750f702: file ../../src/drmmode_display.c, line 1267. (gdb) info b Num Type Disp Enb AddressWhat 2 breakpoint keep y 0x7750fc96 in drmmode_set_mode_major at ../../src/drmmode_display.c:1371 3 breakpoint keep y 0x7750f702 in drmmode_set_mode at ../../src/drmmode_display.c:1267 (gdb) pipe disassemble drmmode_set_mode_major | grep -i c96 -C3 0x7750fc8b <+955>: mov%r14,%rsi 0x7750fc8e <+958>: mov%rbx,%rdi 0x7750fc91 <+961>: call 0x7750f650 0x7750fc96 <+966>: test %eax,%eax 0x7750fc98 <+968>: jne0x7750fef8 0x7750fc9e <+974>: mov0x30(%rsp),%rdi 0x7750fca3 <+979>: lea0x60(%rsp),%rsi (gdb) pipe disassemble drmmode_set_mode | grep -i 702 -C3 0x7750f6f8 <+168>: jne0x7750f710 0x7750f6fa <+170>: mov0x78(%rsi),%rsi 0x7750f6fe <+174>: mov0x10(%rsi),%rsi 0x7750f702 <+178>: mov(%rsi),%r11d 0x7750f705 <+181>: movslq %ecx,%rsi
Bug#1059874: libuhd4.6.0: Segfault in gqrx related to libuhd 4.6.0
Am 04.05.24 um 13:46 schrieb Bernhard Übelacker: These end in some boost::asio functions: boost::asio::detail::scheduler::concurrency_hint() const at /usr/include/boost/asio/detail/scheduler.hpp:142 Forgot to attach how I got there: debugging.txt And for reference the upstream ticket: https://github.com/gqrx-sdr/gqrx/issues/1331 [17674.068551] gqrx[3226752]: segfault at f4 ip 7f5fee944cd6 sp 7f5f967f8870 error 4 [17674.068551] gqrx[3226753]: segfault at f4 ip 7f5fee944cd6 sp 7f5f95ff7870 error 4 in libuhd.so.4.6.0[7f5fee721000+a5e000] [17674.068558] in libuhd.so.4.6.0[7f5fee721000+a5e000] [17674.068557] traps: gqrx[3226749] general protection fault ip:7f5fee944cd6 sp:7f5f977fb7d0 error:0 [17674.068558] gqrx[3226751]: segfault at f4 ip 7f5fee944cd6 sp 7f5f96ff9870 error 4 [17674.068560] likely on CPU 9 (core 1, socket 0) [17674.068560] likely on CPU 10 (core 2, socket 0) [17674.068563] in libuhd.so.4.6.0[7f5fee721000+a5e000] [17674.068562] Code: ec 78 64 48 8b 04 25 28 00 00 00 48 89 44 24 68 31 c0 80 bf c0 00 00 00 00 0f 85 ed 00 00 00 48 8b 45 30 48 8b 9d d0 00 00 00 <44> 8b b8 f4 00 00 00 48 85 db 0f 84 3a 01 00 00 48 8b 43 18 48 89 [17674.068563] Code: ec 78 64 48 8b 04 25 28 00 00 00 48 89 44 24 68 31 c0 80 bf c0 00 00 00 00 0f 85 ed 00 00 00 48 8b 45 30 48 8b 9d d0 00 00 00 <44> 8b b8 f4 00 00 00 48 85 db 0f 84 3a 01 00 00 48 8b 43 18 48 89 [17674.068564] in libuhd.so.4.6.0[7f5fee721000+a5e000] [17674.068569] traps: gqrx[3226745] general protection fault ip:7f5fee944cd6 sp:7f5fbe7f99d0 error:0 [17674.068571] gqrx[3226754]: segfault at f4 ip 7f5fee944cd6 sp 7f5f957f6870 error 4 [17674.068575] in libuhd.so.4.6.0[7f5fee721000+a5e000] [17674.068576] in libuhd.so.4.6.0[7f5fee721000+a5e000] [17674.068578] likely on CPU 12 (core 4, socket 0) [17674.068580] likely on CPU 14 (core 6, socket 0) [17674.068580] Code: ec 78 64 48 8b 04 25 28 00 00 00 48 89 44 24 68 31 c0 80 bf c0 00 00 00 00 0f 85 ed 00 00 00 48 8b 45 30 48 8b 9d d0 00 00 00 <44> 8b b8 f4 00 00 00 48 85 db 0f 84 3a 01 00 00 48 8b 43 18 48 89 [17674.068583] Code: ec 78 64 48 8b 04 25 28 00 00 00 48 89 44 24 68 31 c0 80 bf c0 00 00 00 00 0f 85 ed 00 00 00 48 8b 45 30 48 8b 9d d0 00 00 00 <44> 8b b8 f4 00 00 00 48 85 db 0f 84 3a 01 00 00 48 8b 43 18 48 89 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 "ec 78 64 48 8b 04 25 28 00 00 00 48 89 44 24 68 31 c0 80 bf c0 00 00 00 00 0f 85 ed 00 00 00 48 8b 45 30 48 8b 9d d0 00 00 00 <44> 8b b8 f4 00 00 00 48 85 db 0f 84 3a 01 00 00 48 8b 43 18 48 89" \ | sed 's/[<>]//g' | sed 's/ /, 0x/g' # 2024-05-03 trixie/testing amd64 qemu VM apt dist-upgrade apt install systemd-coredump xserver-xorg slim jwm xterm gdb pipewire gqrx-sdr gqrx-sdr-dbgsym libuhd4.6.0-dbgsym systemctl start slim gdb -q set width 0 set pagination off file /usr/bin/gqrx tb main run pipe info target | grep -E "\.text.*libuhd" find /b 0x743274a0, 0x74d7ee0a, 0xec, 0x78, 0x64, 0x48, 0x8b, 0x04, 0x25, 0x28, 0x00, 0x00, 0x00, 0x48, 0x89, 0x44, 0x24, 0x68, 0x31, 0xc0, 0x80, 0xbf, 0xc0, 0x00, 0x00, 0x00, 0x00, 0x0f, 0x85, 0xed, 0x00, 0x00, 0x00, 0x48, 0x8b, 0x45, 0x30, 0x48, 0x8b, 0x9d, 0xd0, 0x00, 0x00, 0x00, 0x44, 0x8b, 0xb8, 0xf4, 0x00, 0x00, 0x00, 0x48, 0x85, 0xdb, 0x0f, 0x84, 0x3a, 0x01, 0x00, 0x00, 0x48, 0x8b, 0x43, 0x18, 0x48, 0x89 b * (0x74544cac + 42) info b disassemble /r 0x74544cac, 0x74544cac + 62 benutzer@debian:~$ gdb -q (gdb) set width 0 (gdb) set pagination off (gdb) file /usr/bin/gqrx Reading symbols from /usr/bin/gqrx... Reading symbols from /usr/lib/debug/.build-id/99/990c9578178123477597a27d771c5793452e95.debug... (gdb) tb main Temporary breakpoint 1 at 0x9b8a0: file ./src/applications/gqrx/main.cpp, line 49. (gdb) run Starting program: /usr/bin/gqrx [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [New Thread 0x7fffeea006c0 (LWP 18355)] [New Thread 0x7fffee0006c0 (LWP 18356)] [New Thread 0x7fffed6006c0 (LWP 18357)] [New Thread 0x7fffecc006c0 (LWP 18358)] [New Thread 0x7fffec2006c0 (LWP 18359)] [New Thread 0x7fffeb8006c0 (LWP 18360)] [New Thread 0x7fffeae006c0 (LWP 18361)] [New Thread 0x7fffea4006c0 (LWP 18362)] [New Thread 0x7fffe9a006c0 (LWP 18363)] [New Thread 0x7fffe90006c0 (LWP 18364)] Thread 1 "gqrx" hit Temporary breakpoint 1, main (argc=1, argv=0x7fffe488) at ./src/applications/gqrx/main.cpp:49 49 ./src/applications/gqrx/main.cpp: Datei oder Verzeichnis nicht gefunden. (gdb) pipe info target | grep -E "\.text.*libuhd" 0x743274a0 - 0x74d7ee0a is .text in /lib/x86_64-linux-gnu/libuhd.so.4.6.0 (gdb) fin
Bug#1059874: libuhd4.6.0: Segfault in gqrx related to libuhd 4.6.0
Hello, I am not the maintainer of libuhd, just tried to get some more information from the provided dmesg Code lines. These end in some boost::asio functions: boost::asio::detail::scheduler::concurrency_hint() const at /usr/include/boost/asio/detail/scheduler.hpp:142 Unfortunately this allows no guess to where exactly this is called in libuhd. When I start qgrx inside a minimal VM I could not see a crash, but guess this needs some special hardware? If this is still an issue please provide - the exact steps until you receive a crash. - maybe the output which gets written when starting qgrx from a terminal - install systemd-coredump. This should produce in the journal some more information. A lot more information about how to retrieve a backtrace could be found here: https://wiki.debian.org/HowToGetABacktrace Kind regards, Bernhard
Bug#1060293: gnome-nettool: Aborts with assert failure: *** stack smashing detected ***
Hello, I am not maintainer of gnome-nettool, just tried to debug this issue. gnome-nettool collects the information from an execution of a dig command [1] and parses the output. Unfortunately the parsing is done into some fixed size arrays and the dig output overflows those. E.g. the destination buffer is 128 bytes, but 419 bytes from the line get written to it. This parsing is done here [2] with the format string from here [3]. The stack canary is overwritten with this backtrace [4]. Kind regards, Bernhard [1] dig +nocomments +search +nocmd +nostats +noadditional codethink.co.uk ANY [2] https://sources.debian.org/src/gnome-nettool/42.0-1/src/lookup.c/#L260 [3] https://sources.debian.org/src/gnome-nettool/42.0-1/src/lookup.h/#L25 [4] (rr) bt #0 0x7f28a2aa5735 in __vfscanf_internal (s=s@entry=0x7fff90ce11c0, format=format@entry=0x5572c3ef6a71 "%s %d %s %s %[^\n]", argptr=argptr@entry=0x7fff90ce11a8, mode_flags=mode_flags@entry=2) at ./stdio-common/vfscanf-internal.c:2896 #1 0x7f28a2a9791d in __GI___isoc99_sscanf (s=0x5572c5b75e70 "codethink.co.uk.\t20762\tIN\tRRSIG\tSOA 10 3 86400 20240531041601 20240501031601 19848 codethink.co.uk. m9sD9b/i+u7lOqOp/I/DSSxR8XoF8nA4bjCkHKdx3w8RdvFUGjOwsH77 5t2+sFagf7qZ2YLcABs+mDpOe3UFzrGcMbNGRkXGYcW"..., format=format@entry=0x5572c3ef6a71 "%s %d %s %s %[^\n]") at ./stdio-common/isoc99_sscanf.c:31 #2 0x5572c3ef1f1d in strip_line (data=0x7fff90ce1400, line=) at ../src/lookup.c:260 #3 lookup_foreach_with_tree (netinfo=, line=, len=, user_data=) at ../src/lookup.c:189 #4 0x5572c3eeb7f2 in netinfo_io_text_buffer_dialog (channel=, condition=, data=0x5572c59204a0) at ../src/nettool.c:409 #5 0x7f28a2c7e0d9 in g_main_dispatch (context=context@entry=0x5572c552dbd0) at ../../../glib/gmain.c:3476 #6 0x7f28a2c81317 in g_main_context_dispatch_unlocked (context=0x5572c552dbd0) at ../../../glib/gmain.c:4284 #7 g_main_context_iterate_unlocked (context=0x5572c552dbd0, block=block@entry=1, dispatch=dispatch@entry=1, self=) at ../../../glib/gmain.c:4349 #8 0x7f28a2c81c1f in g_main_loop_run (loop=loop@entry=0x5572c568a510) at ../../../glib/gmain.c:4551 #9 0x7f28a33fd65d in gtk_main () at ../../../gtk/gtkmain.c:1329 #10 0x5572c3ee95ba in main (argc=, argv=) at ../src/main.c:231 # 2024-05-01 trixie/testing amd64 qemu VM apt install systemd-coredump task-gnome-desktop mc tmux htop git gdb valgrind rr gnome-nettool gnome-nettool-dbgsym libglib2.0-0t64-dbgsym libgtk-3-0t64-dbgsym apt build-dep gnome-nettool apt build-dep rr mkdir /home/benutzer/source/gnome-nettool/orig -p cd/home/benutzer/source/gnome-nettool/orig apt source gnome-nettool mkdir /home/benutzer/source/net-tools/orig -p cd/home/benutzer/source/net-tools/orig apt source net-tools root@debian:~# journalctl -e Mai 01 17:56:52 debian gnome-nettool.desktop[4366]: *** stack smashing detected ***: terminated Mai 01 17:56:52 debian systemd[1]: Created slice system-systemd\x2dcoredump.slice - Slice /system/systemd-coredump. Mai 01 17:56:52 debian systemd[1]: Started systemd-coredump@0-4400-0.service - Process Core Dump (PID 4400/UID 0). Mai 01 17:56:52 debian systemd-coredump[4401]: [] Process 4366 (gnome-nettool) of user 1000 dumped core. root@debian:~# coredumpctl list TIME PID UID GID SIG COREFILE EXE SIZE Wed 2024-05-01 17:56:52 CEST 4366 1000 1000 SIGABRT present /usr/bin/gnome-nettool 1.8M root@debian:~# coredumpctl gdb --debugger-arguments=-q 4366 PID: 4366 (gnome-nettool) UID: 1000 (benutzer) GID: 1000 (benutzer) Signal: 6 (ABRT) Timestamp: Wed 2024-05-01 17:56:52 CEST (4min 14s ago) Command Line: /usr/bin/gnome-nettool Executable: /usr/bin/gnome-nettool Control Group: /user.slice/user-1000.slice/user@1000.service/app.slice/app-gnome-gnome\x2dnettool-4366.scope Unit: user@1000.service User Unit: app-gnome-gnome\x2dnettool-4366.scope Slice: user-1000.slice Owner UID: 1000 (benutzer) Boot ID: 7408197c36284bc295b6d821669a3071 Machine ID: 16e4d7437c19482b8c85581d3feaba09 Hostname: debian Storage: /var/lib/systemd/coredump/core.gnome-nettool.1000.7408197c36284bc295b6d821669a3071.4366.171457901200.zst (present) Size on Disk: 1.8M Message: Process 4366 (gnome-nettool) of user 1000 dumped core. Module libzstd.so.1 from deb libzstd-1.5.5+dfsg2-2.amd64 Module libsystemd.so.0 from deb systemd-255.4-1.amd64 Stack trace of thread 4366: #0 0x7fdb1d71a16c n/a (libc.so.6 + 0x8a16c) #1 0x7fdb1d6cc472 raise (libc.so.6 + 0x3c472) #2 0x7fdb1d6b64b2 abort (libc.so.6 + 0x264b2) #3 0x7fdb1d6b71ed n/a (libc.so.6 + 0x271ed) #4 0x7fdb1d7a8465 __fortify_fail (libc.so.6 + 0x118465) #5
Bug#1060224: bluetoothd started segfaulting
Hello, I am just trying to get the source line from the dmesg code line. [ 97.073761] bluetoothd[838]: segfault at 561314652a23 ip 56167406a375 sp 7fffb128a200 error 4 in bluetoothd[561674048000+ec000] likely on CPU 11 (core 5, socket 0) [ 97.073799] Code: 00 31 c0 e9 54 ff ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 66 90 f3 0f 1e fa 41 55 41 54 55 53 48 83 ec 08 48 8b 2a 48 8b 7a 08 <48> 8b 45 20 4c 8b ad 88 00 00 00 4c 8b 20 48 85 ff 74 19 c7 47 08 And it points to function a2dp_suspend_complete, [transport.c:431]. This function leads to upstream report [701], which should be fixed since release 5.72 [83cfad1]. Kind regards, Bernhard [transport.c:431] https://sources.debian.org/src/bluez/5.71-1/profiles/audio/transport.c/#L431 [701] https://github.com/bluez/bluez/issues/701 [83cfad1] https://github.com/bluez/bluez/commit/83cfad1badee6aae77eb15177ccc917249ab9bb3 [ 97.073761] bluetoothd[838]: segfault at 561314652a23 ip 56167406a375 sp 7fffb128a200 error 4 in bluetoothd[561674048000+ec000] likely on CPU 11 (core 5, socket 0) [ 97.073799] Code: 00 31 c0 e9 54 ff ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 66 90 f3 0f 1e fa 41 55 41 54 55 53 48 83 ec 08 48 8b 2a 48 8b 7a 08 <48> 8b 45 20 4c 8b ad 88 00 00 00 4c 8b 20 48 85 ff 74 19 c7 47 08 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 . # 2024-05-01 trixie/testing amd64 qemu VM apt dist-upgrade apt install gdb bluez bluez-dbgsym apt build-dep bluez mkdir /home/benutzer/source/bluez/orig -p cd/home/benutzer/source/bluez/orig apt source bluez echo -n "find /b ..., ..., 0x" && \ echo "00 31 c0 e9 54 ff ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 66 90 f3 0f 1e fa 41 55 41 54 55 53 48 83 ec 08 48 8b 2a 48 8b 7a 08 <48> 8b 45 20 4c 8b ad 88 00 00 00 4c 8b 20 48 85 ff 74 19 c7 47 08" \ | sed 's/[<>]//g' | sed 's/ /, 0x/g' gdb -q set width 0 set pagination off file /usr/sbin/bluetoothd tb main run pipe info target | grep -E "\.text$" find /b 0x555798f0, 0x55663b30, 0x00, 0x31, 0xc0, 0xe9, 0x54, 0xff, 0xff, 0xff, 0x66, 0x66, 0x2e, 0x0f, 0x1f, 0x84, 0x00, 0x00, 0x00, 0x00, 0x00, 0x66, 0x90, 0xf3, 0x0f, 0x1e, 0xfa, 0x41, 0x55, 0x41, 0x54, 0x55, 0x53, 0x48, 0x83, 0xec, 0x08, 0x48, 0x8b, 0x2a, 0x48, 0x8b, 0x7a, 0x08, 0x48, 0x8b, 0x45, 0x20, 0x4c, 0x8b, 0xad, 0x88, 0x00, 0x00, 0x00, 0x4c, 0x8b, 0x20, 0x48, 0x85, 0xff, 0x74, 0x19, 0xc7, 0x47, 0x08 b * (0x5559a34b + 42) info b disassemble /r 0x5559a34b, 0x5559a34b + 62 directory /home/benutzer/source/bluez/orig/bluez-5.71 benutzer@debian:~$ gdb -q (gdb) set width 0 (gdb) set pagination off (gdb) file /usr/sbin/bluetoothd Reading symbols from /usr/sbin/bluetoothd... Reading symbols from /usr/lib/debug/.build-id/b3/ec9634ecf4f0995fa44119b844150cc8d98db5.debug... (gdb) tb main Temporary breakpoint 1 at 0x25bd0: file src/main.c, line 1355. (gdb) run Starting program: /usr/sbin/bluetoothd [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=0x7fffe478) at src/main.c:1355 1355src/main.c: Datei oder Verzeichnis nicht gefunden. (gdb) pipe info target | grep -E "\.text$" 0x555798f0 - 0x55663b30 is .text (gdb) find /b 0x555798f0, 0x55663b30, 0x00, 0x31, 0xc0, 0xe9, 0x54, 0xff, 0xff, 0xff, 0x66, 0x66, 0x2e, 0x0f, 0x1f, 0x84, 0x00, 0x00, 0x00, 0x00, 0x00, 0x66, 0x90, 0xf3, 0x0f, 0x1e, 0xfa, 0x41, 0x55, 0x41, 0x54, 0x55, 0x53, 0x48, 0x83, 0xec, 0x08, 0x48, 0x8b, 0x2a, 0x48, 0x8b, 0x7a, 0x08, 0x48, 0x8b, 0x45, 0x20, 0x4c, 0x8b, 0xad, 0x88, 0x00, 0x00, 0x00, 0x4c, 0x8b, 0x20, 0x48, 0x85, 0xff, 0x74, 0x19, 0xc7, 0x47, 0x08 0x5559a34b 1 pattern found. (gdb) b * (0x5559a34b + 42) Breakpoint 2 at 0x5559a375: file profiles/audio/transport.c, line 431. (gdb) info b Num Type Disp Enb AddressWhat 2 breakpoint keep y 0x5559a375 in a2dp_suspend_complete at profiles/audio/transport.c:431 (gdb) disassemble /r 0x5559a34b, 0x5559a34b + 62 Dump of assembler code from 0x5559a34b to 0x5559a389: ... 0x5559a360 :f3 0f 1e fa endbr64 0x5559a364 :41 55 push %r13 0x5559a366 :41 54 push %r12 0x5559a368 :55 push %rbp 0x5559a369 :53 push %rbx 0x5559a36a : 48 83 ec 08 sub$0x8,%rsp 0x5559a36e : 48 8b 2a mov(%rdx),%rbp 0x5559a371 : 48 8b 7a 08 mov0x8(%rdx),%rdi 0x5559a375 : 48 8b 45 20 mov0x20(%rbp),%rax < 0x5559a379 : 4c 8b ad
Bug#1062205: Crashes desktop when attempting to make a network display
On Fri, 2 Feb 2024 00:58:31 -0800 Josh Triplett wrote: Feb 02 00:28:37 o kernel: gnome-shell[1083]: segfault at 20 ip 7fececdf8f04 sp 7ffc5ad85ed8 error 4 in libmutter-clutter-12.so.0.0.0[7fececda5000+9] likely on CPU 3 (core 4, socket 0) Feb 02 00:28:37 o kernel: Code: c3 0f 1f 44 00 00 48 8d 15 e1 1a 04 00 48 8d 35 d2 7e 05 00 48 8d 3d 4e f4 03 00 e9 d6 f2 fa ff 66 0f 1f 44 00 00 f3 0f 1e fa <48> 8b 47 20 c3 0f 1f 80 00 00 00 00 f3 0f 1e fa 48 8b 47 28 c3 0f Hello, I am not involved in maintaining this package, just looking through some crash reports. My attempt to resolve the dmesg lines from the crash to a source line information led me here: clutter_paint_context_get_redraw_clip at ../clutter/clutter/clutter-paint-context.c:140 https://sources.debian.org/src/mutter/44.8-3.1/clutter/clutter/clutter-paint-context.c/#L140 137 const cairo_region_t * 138 clutter_paint_context_get_redraw_clip (ClutterPaintContext *paint_context) 139 { 140 return paint_context->redraw_clip; 141 } This function name leads to following bug report, which sounds interesting: https://gitlab.gnome.org/GNOME/mutter/-/issues/2876 And which got fixed by this merge request: https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3283 First upstream release containing this fix would be 45.1, unfortunately not yet in unstable or testing. But a proper backtrace might still help to confirm, if this crash is really the same which is described in the mentioned mutter bug report. https://wiki.debian.org/HowToGetABacktrace Simplest version could be to install systemd-coredump and inspecting the journal after a crash. Kind regards, Bernhard https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1062205 https://wiki.debian.org/HowToGetABacktrace https://wiki.debian.org/InterpretingKernelOutputAtProcessCrash Feb 02 00:28:37 o kernel: gnome-shell[1083]: segfault at 20 ip 7fececdf8f04 sp 7ffc5ad85ed8 error 4 in libmutter-clutter-12.so.0.0.0[7fececda5000+9] likely on CPU 3 (core 4, socket 0) Feb 02 00:28:37 o kernel: Code: c3 0f 1f 44 00 00 48 8d 15 e1 1a 04 00 48 8d 35 d2 7e 05 00 48 8d 3d 4e f4 03 00 e9 d6 f2 fa ff 66 0f 1f 44 00 00 f3 0f 1e fa <48> 8b 47 20 c3 0f 1f 80 00 00 00 00 f3 0f 1e fa 48 8b 47 28 c3 0f error 4 == 0b0100: * bit 0 ==0: no page found * bit 1 ==0: read access * bit 2 ==1: user-mode access . # 2024-04-28 Trixie/testing amd64 qemu VM apt update apt dist-upgrade apt build-dep libmutter-12-0 apt install systemd-coredump gdb libmutter-12-0 libmutter-12-0-dbgsym coreutils-dbgsym mkdir /home/benutzer/source/libmutter-12-0/orig -p cd/home/benutzer/source/libmutter-12-0/orig apt source libmutter-12-0 echo -n "find /b ..., ..., 0x" && \ echo "c3 0f 1f 44 00 00 48 8d 15 e1 1a 04 00 48 8d 35 d2 7e 05 00 48 8d 3d 4e f4 03 00 e9 d6 f2 fa ff 66 0f 1f 44 00 00 f3 0f 1e fa <48> 8b 47 20 c3 0f 1f 80 00 00 00 00 f3 0f 1e fa 48 8b 47 28 c3 0f" \ | sed 's/[<>]//g' | sed 's/ /, 0x/g' gdb -q set width 0 set pagination off file /usr/bin/true tb main run call dlopen("/usr/lib/x86_64-linux-gnu/mutter-12/libmutter-clutter-12.so.0.0.0",0x102) pipe info target | grep "\.text.*libmutter-clutter" find /b 0x77cf0f30, 0x77d7a6de, 0xc3, 0x0f, 0x1f, 0x44, 0x00, 0x00, 0x48, 0x8d, 0x15, 0xe1, 0x1a, 0x04, 0x00, 0x48, 0x8d, 0x35, 0xd2, 0x7e, 0x05, 0x00, 0x48, 0x8d, 0x3d, 0x4e, 0xf4, 0x03, 0x00, 0xe9, 0xd6, 0xf2, 0xfa, 0xff, 0x66, 0x0f, 0x1f, 0x44, 0x00, 0x00, 0xf3, 0x0f, 0x1e, 0xfa, 0x48, 0x8b, 0x47, 0x20, 0xc3, 0x0f, 0x1f, 0x80, 0x00, 0x00, 0x00, 0x00, 0xf3, 0x0f, 0x1e, 0xfa, 0x48, 0x8b, 0x47, 0x28, 0xc3, 0x0f b * (0x77d3eeda + 42) info b disassemble /r 0x77d3eeda, 0x77d3eeda + 62 directory /home/benutzer/source/libmutter-12-0/orig/mutter-44.8/clutter benutzer@debian:~$ gdb -q (gdb) set width 0 (gdb) set pagination off (gdb) file /usr/bin/true Reading symbols from /usr/bin/true... Reading symbols from /usr/lib/debug/.build-id/04/6669aefa60ba9f99cc1c829bf6aac6e0d05d4c.debug... (gdb) tb main Temporary breakpoint 1 at 0x2310: file src/true.c, line 56. (gdb) run Starting program: /usr/bin/true [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=0x7fffe488) at src/true.c:56 56 src/true.c: Datei oder Verzeichnis nicht gefunden. (gdb) call dlopen("/usr/lib/x86_64-linux-gnu/mutter-12/libmutter-clutter-12.so.0.0.0",0x102) $1 = (void *) 0xe340 (gdb) pipe info target | grep "\.text.*libmutter-clutter" 0x77cf0f30 - 0x77d7a6de is .text in /usr/lib/x86_64-linux-gnu/mutter-12/libmutter-clutter-12.so.0.0.0 (gdb) find /b 0x77cf0f30, 0x77d7a6de, 0xc3, 0x0f, 0x1f, 0x44, 0x00, 0x00, 0x48, 0x8d, 0x15, 0xe1, 0x1a, 0x04, 0x00, 0x48, 0x8d, 0x35, 0xd2, 0x7e, 0x05, 0x00, 0x48, 0x8d, 0x3d, 0x4e, 0xf4, 0x03, 0x00, 0xe9, 0xd6, 0xf2,
Bug#1064372: evolution: segfault during startup
Hello, just tried to extract the backtrace from the attached core dump. Kind regards, Bernhard Core was generated by `/usr/bin/evolution'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x in ?? () (gdb) bt #0 0x in ?? () #1 0x7f5ad98da8b6 in g_get_worker_context () at ../../../glib/gmain.c:6598 #2 0x7f5ad98dac0c in ref_unix_signal_handler_unlocked (signum=15) at ../../../glib/gmain.c:5726 #3 _g_main_create_unix_signal_watch (signum=15) at ../../../glib/gmain.c:5834 #4 0x7f5ad992f8de in g_unix_signal_add_full (priority=priority@entry=0, signum=signum@entry=15, handler=handler@entry=0x556725eb22e0 , user_data=user_data@entry=0x0, notify=notify@entry=0x0) at ../../../glib/glib-unix.c:231 #5 0x556725eb1b08 in main (argc=, argv=) at ./src/shell/main.c:729 (gdb) up #1 0x7f5ad98da8b6 in g_get_worker_context () at ../../../glib/gmain.c:6598 6598 pthread_sigmask (SIG_SETMASK, , _mask); (gdb) # 2024-04-26 Trixie/testing amd64 qemu VM apt update apt dist-upgrade apt install systemd-coredump wget zstd ncdu gdb evolution-dbgsym libglib2.0-0-dbgsym apt build-dep glib2.0 mkdir /home/benutzer/source/glib2.0/orig -p cd/home/benutzer/source/glib2.0/orig apt source glib2.0 wget "https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=1064372;filename=core.evolution.1000.1a4c16b6b1594876901650d63de977bc.12161.170846511800.zst;msg=5; -O core.evolution.1000.1a4c16b6b1594876901650d63de977bc.12161.170846511800.zst unzstd --keep core.evolution.1000.1a4c16b6b1594876901650d63de977bc.12161.170846511800.zst export DEBUGINFOD_URLS="https://debuginfod.debian.net; echo "set debuginfod enabled on" >> .gdbinit gdb -q --core core.evolution.1000.1a4c16b6b1594876901650d63de977bc.12161.170846511800 /usr/bin/evolution set width 0 set pagination off directory /home/benutzer/source/glib2.0/orig/glib2.0-2.78.4/glib/tests/markups Core was generated by `/usr/bin/evolution'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x in ?? () (gdb) set width 0 (gdb) set pagination off (gdb) directory /home/benutzer/source/glib2.0/orig/glib2.0-2.78.4/glib/tests/markups Source directories searched: /home/benutzer/source/glib2.0/orig/glib2.0-2.78.4/glib/tests/markups:$cdir:$cwd (gdb) bt #0 0x in ?? () #1 0x7f5ad98da8b6 in g_get_worker_context () at ../../../glib/gmain.c:6598 #2 0x7f5ad98dac0c in ref_unix_signal_handler_unlocked (signum=15) at ../../../glib/gmain.c:5726 #3 _g_main_create_unix_signal_watch (signum=15) at ../../../glib/gmain.c:5834 #4 0x7f5ad992f8de in g_unix_signal_add_full (priority=priority@entry=0, signum=signum@entry=15, handler=handler@entry=0x556725eb22e0 , user_data=user_data@entry=0x0, notify=notify@entry=0x0) at ../../../glib/glib-unix.c:231 #5 0x556725eb1b08 in main (argc=, argv=) at ./src/shell/main.c:729 (gdb) up #1 0x7f5ad98da8b6 in g_get_worker_context () at ../../../glib/gmain.c:6598 6598 pthread_sigmask (SIG_SETMASK, , _mask); (gdb)
Bug#1068680: din: Process 166294 (din) of user 1000 dumped core
Hello Cláudio, I am not maintainer of the din package, just reading through some crash reports. Unfortunately I cannot follow your claim "The crash occurred in the module libzstd.so.1". None of the 5 threads show a frame inside libzstd. It seems just listed in the Module list. Thread 166294 shows all the last frames in the din executable, all other visible threads may just be "waiting", therefore the epoll_wait frame. I would suggest to install systemd-coredump and gdb if not happened yet. If it was, following sequence of command should enable the debugger to load debug information for involved executables and print out function names with source file and line number information. export DEBUGINFOD_URLS="https://debuginfod.debian.net; coredumpctl gdb 166294 y thread apply all bt full quit This downloads several megabytes into $HOME/.cache/debuginfod_client. And would show way more details for the maintainer to look at. I tried to reconstruct the line information to your first thread, which I suspect is the crashing one. More information about debugging crashes can be found in this page: https://wiki.debian.org/HowToGetABacktrace Kind regards, Bernhard Stack trace of thread 166294: #0 0x5617dbae42ab n/a (din + 0xc02ab)in font::draw_char(char, int, int, int) at ./src/font.cc:203 #1 0x5617dbae4a75 n/a (din + 0xc0a75)in draw_string(std::__cxx11::basic_string, std::allocator > const&, int, int, int) at ./src/font.cc:220 #2 0x5617dba8c2e4 n/a (din + 0x682e4)in options_list::draw() at ./src/options_list.h:93 #3 0x5617dbb73b55 n/a (din + 0x14fb55) in settings::draw() at ./src/settings.cc:281 #4 0x5617dbb8aab0 n/a (din + 0x166ab0) in ui_list::draw() at ./src/ui.cc:151 #5 0x5617dba5a15b main (din + 0x3615b) in main(int, char**) at ./src/main.cc:1606 https://sources.debian.org/src/din/56-1/src/font.cc/#L203
Bug#1064347: openssh-server: sshd crashes under heavy traffic
Hello, I am no maintainer, just tried to reproduce this issue which I could inside a minimal Bullseye amd64 qemu VM with the instructions from the linked Ubuntu bug. I could not reproduce it within Bookworm or Trixie/testing. Without "LogLevel DEBUG" it was also not observable. Unfortunately did also not happen with a ssh package built with asan enabled. And I upgraded step by step via snapshot.d.o, around 2021-11-15 it stopped to be an issue. This step brought openssh 8.7p1-1. Downgrading just openssh 8.4p1-6 in this exact VM showed it again. Therefore I assume this issue got fixed between openssh 8.4p1-6 and 8.7p1-1. Kind regards, Bernhard #13 #14 malloc_consolidate (av=av@entry=0x7faa3b64cb80 ) at malloc.c:4518 #15 0x7faa3b5023d5 in _int_malloc (av=av@entry=0x7faa3b64cb80 , bytes=bytes@entry=8193) at malloc.c:3699 #16 0x7faa3b503063 in malloc_check (sz=8192, caller=) at hooks.c:239 #17 0x7faa3b504cea in __libc_calloc (n=n@entry=1, elem_size=elem_size@entry=8192) at malloc.c:3387 #18 0x7faa3b4f6ef4 in __GI___open_memstream (bufloc=bufloc@entry=0x7ffe636eb6e0, sizeloc=sizeloc@entry=0x7ffe636eb6e8) at memstream.c:83 #19 0x7faa3b5726e1 in __vsyslog_internal (pri=39, fmt=0x55b451dcb150 "%.500s", ap=0x7ffe636eb7d0, mode_flags=2) at ../misc/syslog.c:181 #20 0x7faa3b572d5f in __syslog_chk (pri=pri@entry=7, flag=flag@entry=1, fmt=fmt@entry=0x55b451dcb150 "%.500s") at ../misc/syslog.c:136 #21 0x55b451d87e16 in syslog (__fmt=0x55b451dcb150 "%.500s", __pri=7) at /usr/include/x86_64-linux-gnu/bits/syslog.h:31 #22 do_log (level=level@entry=SYSLOG_LEVEL_DEBUG1, fmt=fmt@entry=0x55b451dba421 "Forked child %ld.", args=args@entry=0x7ffe636ec110) at ../../log.c:484 #23 0x55b451d88254 in debug (fmt=fmt@entry=0x55b451dba421 "Forked child %ld.") at ../../log.c:229 #24 0x55b451d3c86e in server_accept_loop (config_s=0x7ffe636ec270, newsock=, sock_out=, sock_in=) at ../../sshd.c:1377 #25 main (ac=, av=) at ../../sshd.c:2089 # 2024-04-23 Bullseye/stable amd64 qemu VM apt update apt dist-upgrade apt install systemd-coredump moreutils parallel htop fakeroot mc ccache gdb openssh-server-dbgsym apt build-dep glibc apt build-dep openssh-server mkdir /home/benutzer/source/glibc/orig -p cd/home/benutzer/source/glibc/orig apt source glibc mkdir /home/benutzer/source/openssh-server/orig -p cd/home/benutzer/source/openssh-server/orig apt source openssh-server sed -i.bak 's/#LogLevel INFO/LogLevel DEBUG/g' /etc/ssh/sshd_config systemctl restart sshd ssh-keygen -b 4096 ssh-copy-id -i .ssh/id_rsa.pub benutzer@localhost parallel -j 32 -N0 "ssh benutzer@localhost 'true'" ::: {1..2} benutzer@debian:~/.ssh$ ssh-keygen -b 4096 Generating public/private rsa key pair. Enter file in which to save the key (/home/benutzer/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/benutzer/.ssh/id_rsa Your public key has been saved in /home/benutzer/.ssh/id_rsa.pub The key fingerprint is: SHA256:Hgx6dUtFBhKiI0wBYKtXMkwZeRcP/eEZCUsU69bbO+o benutzer@debian The key's randomart image is: +---[RSA 4096]+ |+o== ++B+.++| |.=+ ...=.++o | | .*.+.. =oo+ | |. = o = ++. | |. . . . S o | | . . o . o | |. . .| |.. | | .E... | +[SHA256]-+ benutzer@debian:~$ ssh-copy-id -i .ssh/id_rsa.pub benutzer@localhost /usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: ".ssh/id_rsa.pub" /usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed /usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys benutzer@localhost's password: Number of key(s) added: 1 Now try logging into the machine, with: "ssh 'benutzer@localhost'" and check to make sure that only the key(s) you wanted were added. parallel -j 800 -N0 "ssh benutzer@localhost 'mount; sleep 1; cat /proc/cpuinfo; free -h; dd if=/dev/zero of=/dev/null bs=1 count=8192; mount -av; sleep $(($RANDOM % 5)); lscpu'" ::: {1..1} # AMD Ryzen 1700, VM, 16 threads root@debian:~# coredumpctl list TIMEPID UID GID SIG COREFILE EXE Tue 2024-04-23 00:20:53 CEST 124297 0 0 6 present /usr/sbin/sshd Tue 2024-04-23 00:23:02 CEST 159284 0 0 6 present /usr/sbin/sshd Tue 2024-04-23 00:23:47 CEST 229261 0 0 11 present /usr/sbin/sshd Tue 2024-04-23 00:24:32 CEST 277265 0 0 11 present /usr/sbin/sshd Tue 2024-04-23 00:24:54 CEST 301567 0 0 6 present /usr/sbin/sshd root@debian:~# coredumpctl gdb 301567 PID: 301567 (sshd) UID: 0 (root) GID: 0 (root) Signal: 6 (ABRT) Timestamp: Tue 2024-04-23 00:24:53 CEST (47s ago) Command Line: sshd: /usr/sbin/sshd -D [listener] 4 of 10-100 startups Executable: /usr/sbin/sshd
Bug#1064613: vtun: Segmentation fault with default config
On Sat, 24 Feb 2024 23:55:18 + =?utf-8?q?Lucas_L=C3=B3pez?= wrote: I copied the example server file /usr/share/doc/vtun/examples/vtund-server.conf into /etc/vtund.conf and enabled server mode in /etc/default/vtun. When I start the service with systemctl I get the following error on the dmesg log: [343358.769324] vtund[3002]: segfault at 0 ip 5572cac05e34 sp 7ffc9a47f610 error 4 in vtund[5572cabff000+b000] likely on CPU 0 (core 0, socket 0) [343358.769342] Code: 24 10 e8 2f 96 ff ff 85 c0 0f 88 0d 01 00 00 48 8b 44 24 10 48 89 44 24 08 48 85 c0 0f 84 f0 00 00 00 48 89 c3 90 48 8b 6b 18 <66> 44 39 7d 00 0f 85 d1 00 00 00 48 8b 73 08 4c 89 ef e8 55 97 ff I checked the config and the manual but I haven't been able to use the package due to the segfault. BTW, the autogenerated systemd unit has the attributes RemainAfterExit=yes, SuccessExitStatus=5 6, so even on failure the unit appears as "active (exited)". Hence it needs a "systemctl restart", "systemctl start" won't do anything which is a bit counterintuitive. Hello, I am not the maintainer of vtun, just tried to find some more informations about the crash. I was not able to reproduce it inside a minimal VM, but I think from the dmesg lines it happened in netlib.c line 156. This looks like ifa->ifa_addr is no valid pointer but gets dereferenced. I guess it might be related to the network configuration of this specific host, maybe containing an interface without having an address assigned. Kind regards, Bernhard 148 int getifaddr(struct sockaddr_storage *addr, char * ifname, sa_family_t af) ... 154 155 for (ifa = ifas; ifa; ifa = ifa->ifa_next) { 156 if( ifa->ifa_addr->sa_family != af || 157strcmp(ifname, ifa->ifa_name) ) https://sources.debian.org/src/vtun/3.0.4-2/netlib.c/#L156 https://man7.org/linux/man-pages/man3/getifaddrs.3.html # 2024-04-22 Trixie/testing amd64 qemu VM apt update apt install systemd-coredump mc htop gdb # with unstable apt install vtun vtun-dbgsym devscripts apt build-dep vtun mkdir /home/benutzer/source/vtun/orig -p cd/home/benutzer/source/vtun/orig dget https://snapshot.debian.org/archive/debian-debug/20191112T220504Z/pool/main/v/vtun/vtun_3.0.4-2.dsc dpkg-source -x vtun_3.0.4-2.dsc cp -a /usr/share/doc/vtun/examples/vtund-server.conf /etc/vtund.conf cp -a /etc/default/vtun /etc/default/vtun.orig sed -i 's/# RUN_SERVER=no/RUN_SERVER=yes/g' /etc/default/vtun wget https://snapshot.debian.org/archive/debian/20220514T093947Z/pool/main/v/vtun/vtun_3.0.4-2%2Bb1_amd64.deb wget https://snapshot.debian.org/archive/debian-debug/20220514T091215Z/pool/main/v/vtun/vtun-dbgsym_3.0.4-2%2Bb1_amd64.deb dpkg -i *.deb systemctl start vtun.service -> Could not reproduce the crash [343358.769324] vtund[3002]: segfault at 0 ip 5572cac05e34 sp 7ffc9a47f610 error 4 in vtund[5572cabff000+b000] likely on CPU 0 (core 0, socket 0) [343358.769342] Code: 24 10 e8 2f 96 ff ff 85 c0 0f 88 0d 01 00 00 48 8b 44 24 10 48 89 44 24 08 48 85 c0 0f 84 f0 00 00 00 48 89 c3 90 48 8b 6b 18 <66> 44 39 7d 00 0f 85 d1 00 00 00 48 8b 73 08 4c 89 ef e8 55 97 ff # 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 "24 10 e8 2f 96 ff ff 85 c0 0f 88 0d 01 00 00 48 8b 44 24 10 48 89 44 24 08 48 85 c0 0f 84 f0 00 00 00 48 89 c3 90 48 8b 6b 18 <66> 44 39 7d 00 0f 85 d1 00 00 00 48 8b 73 08 4c 89 ef e8 55 97 ff" \ | sed 's/[<>]//g' | sed 's/ /, 0x/g' gdb -q --pid $(pgrep vtund) (gdb) pipe info target | grep -E ".text$" 0x55c1fbd0f7f0 - 0x55c1fbd19ba1 is .text (gdb) find /b 0x55c1fbd0f7f0, 0x55c1fbd19ba1, 0x24, 0x10, 0xe8, 0x2f, 0x96, 0xff, 0xff, 0x85, 0xc0, 0x0f, 0x88, 0x0d, 0x01, 0x00, 0x00, 0x48, 0x8b, 0x44, 0x24, 0x10, 0x48, 0x89, 0x44, 0x24, 0x08, 0x48, 0x85, 0xc0, 0x0f, 0x84, 0xf0, 0x00, 0x00, 0x00, 0x48, 0x89, 0xc3, 0x90, 0x48, 0x8b, 0x6b, 0x18, 0x66, 0x44, 0x39, 0x7d, 0x00, 0x0f, 0x85, 0xd1, 0x00, 0x00, 0x00, 0x48, 0x8b, 0x73, 0x08, 0x4c, 0x89, 0xef, 0xe8, 0x55, 0x97, 0xff 0x55c1fbd15e0a 1 pattern found. (gdb) b * (0x55c1fbd15e0a + 42) Breakpoint 1 at 0x55c1fbd15e34: file ./netlib.c, line 156. (gdb) info b Num Type Disp Enb AddressWhat 1 breakpoint keep y 0x55c1fbd15e34 in getifaddr at ./netlib.c:156 (gdb) disassemble /r 0x55c1fbd15e0a, 0x55c1fbd15e0a + 62 Dump of assembler code from 0x55c1fbd15e0a to 0x55c1fbd15e48: 0x55c1fbd15e0a : 24 10 and$0x10,%al 0x55c1fbd15e0c : e8 2f 96 ff ff call 0x55c1fbd0f440 0x55c1fbd15e11 : 85 c0 test %eax,%eax 0x55c1fbd15e13 : 0f 88 0d 01 00 00 js 0x55c1fbd15f26 0x55c1fbd15e19 : 48 8b 44 24 10 mov 0x10(%rsp),%rax 0x55c1fbd15e1e : 48 89 44 24 08
Bug#1067691: FTBFS: double free or corruption
Hello, I found this one interesting and tried to reproduce it, and hit this issue quite reliable with an unstable armel chroot, inside an armhf unstable qemu VM, or with a Android/LineageOS with real arm CPU. Unfortunately valgrind is no longer built for armel, and a local armel rebuild shows issues with latest "-fstack-protector-strong -fstack-clash-protection". Finally I found this issue leads not to a crash at amd64, but valgrind uncovers it there reliable [1]. dpkg-buildpackage with valgrind installed uses it automatically. Therefore the change in [2] might be an improvement? Increasing the allocation of the input buffer like in [3] makes the valgrind errors go away. Unfortunately I don't know what exact size this buffer is expected to have. Kind regards, Bernhard [1] ... fft const ==1105453== Invalid write of size 4 ==1105453==at 0x60BFC25: ??? (in /usr/lib/x86_64-linux-gnu/libavutil.so.58.29.100) ==1105453==by 0x4CE1880: av_rdft_calc (in /usr/lib/x86_64-linux-gnu/libavcodec.so.60.31.102) ==1105453==by 0x11246F: FFTPlanImpl::execute() (spek-fft.cc:38) ==1105453==by 0x110A76: test_const() (test-fft.cc:21) ==1105453==by 0x1105F5: test_fft() (test-fft.cc:77) ==1105453==by 0x10BF5C: main (test.cc:11) ==1105453== Address 0x11a828c4 is 4 bytes after a block of size 64 alloc'd ==1105453==at 0x4845DA0: memalign (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so) ==1105453==by 0x4845F01: posix_memalign (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so) ==1105453==by 0x608CC14: av_malloc (in /usr/lib/x86_64-linux-gnu/libavutil.so.58.29.100) ==1105453==by 0x1126A0: FFTPlan (spek-fft.h:29) ==1105453==by 0x1126A0: FFTPlanImpl::FFTPlanImpl(int) (spek-fft.cc:27) ==1105453==by 0x112745: FFT::create(int) (spek-fft.cc:24) ==1105453==by 0x1109AE: test_const() (test-fft.cc:13) ==1105453==by 0x1105F5: test_fft() (test-fft.cc:77) ==1105453==by 0x10BF5C: main (test.cc:11) ... [2] --- debian/control.orig 2023-01-11 07:25:51.0 +0100 +++ debian/control 2024-04-21 16:30:57.545576734 +0200 @@ -11,3 +11,4 @@ Build-Depends: debhelper-compat (= 13), libwxgtk3.2-dev, - wx-common + wx-common, + valgrind-if-available Standards-Version: 4.6.2 [3] --- src/spek-fft.h.orig 2023-01-10 05:00:39.0 +0100 +++ src/spek-fft.h 2024-04-21 16:28:07.0 +0200 @@ -28,3 +28,3 @@ public: // input data to be aligned by up to 32 bytes (e.g. AVX) -this->input = (float*) av_malloc(sizeof(float) * input_size); +this->input = (float*) av_malloc(sizeof(float) * (input_size + 2)); }
Bug#1067907: flam3-utils: flam3-genome randomly segfaults on ppc64el
Hello, tried to reproduce the issue and got on a first run this stack: (gdb) bt #0 iter_thread_int (fth=0x157681210) at rect.c:500 #1 0x7fffaa36bad0 in iter_thread_float () at rect.c:253 #2 0x7fffa9c9b010 in start_thread (arg=0x7fffa740f100) at pthread_create.c:444 #3 0x7fffa9d3e364 in .LY__clone () at ../sysdeps/unix/sysv/linux/powerpc/powerpc64/clone.S:107 (gdb) More details in attached file. Kind regards, Bernhardhttps://people.debian.org/~gio/dqib/ https://gitlab.com/giomasce/dqib/-/jobs/6565595570/artifacts/download?file_type=archive echo "set enable-bracketed-paste off" >> /etc/inputrc echo "deb-src http://deb.debian.org/debian/ unstable main" >> /etc/apt/sources.list apt update apt install systemd-coredump flam3-utils htop gdb libflam3-0-dbgsym flam3-utils-dbgsym apt build-dep flam3 mkdir /home/benutzer/source/flam3/orig -p cd/home/benutzer/source/flam3/orig apt source flam3 benutzer@debian:~$ env seed=$RANDOM issac_seed=$RANDOM flam3-genome > /dev/null Segmentation fault (core dumped) benutzer@debian:~$ benutzer@debian:~$ coredumpctl list -q TIMEPID UID GID SIG COREFILE EXE SIZE Sat 2024-04-13 08:59:01 UTC 819 1001 1001 SIGSEGV present /usr/bin/flam3-genome 1.8M export DEBUGINFOD_URLS="https://debuginfod.debian.net; echo "set debuginfod enabled on" >> .gdbinit cd /home/benutzer/source/flam3/orig/flam3-3.1.1+ds2 benutzer@debian:~$ coredumpctl gdb --debugger-arguments=-q 819 Hint: You are currently not seeing messages from other users and the system. Users in groups 'adm', 'systemd-journal' can see all messages. Pass -q to turn off this notice. PID: 819 (flam3-genome) UID: 1001 (benutzer) GID: 1001 (benutzer) Signal: 11 (SEGV) Timestamp: Sat 2024-04-13 08:58:58 UTC (8min ago) Command Line: flam3-genome Executable: /usr/bin/flam3-genome Control Group: /system.slice/ssh.service Unit: ssh.service Slice: system.slice Boot ID: 264b6d6ac02b49fcbf29cf0bda4825ba Machine ID: 9d83830458974e43a3f2f91f73a6969d Hostname: debian Storage: /var/lib/systemd/coredump/core.flam3-genome.1001.264b6d6ac02b49fcbf29cf0bda4825ba.819.171299873800.zst (present) Size on Disk: 1.8M Message: Process 819 (flam3-genome) of user 1001 dumped core. Stack trace of thread 1051: #0 0x7fffaa36b444 n/a (libflam3.so.0 + 0x2b444) #1 0x7fffaa36bad0 n/a (libflam3.so.0 + 0x2bad0) #2 0x7fffa9c9b010 n/a (libc.so.6 + 0x9b010) #3 0x7fffa9d3e364 __clone (libc.so.6 + 0x13e364) ELF object binary architecture: PowerPC64 Reading symbols from /usr/bin/flam3-genome... (No debugging symbols found in /usr/bin/flam3-genome) [New LWP 1051] [New LWP 819] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/powerpc64-linux-gnu/libthread_db.so.1". Core was generated by `flam3-genome '. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x7fffaa36b444 in ?? () from /lib/powerpc64-linux-gnu/libflam3.so.0 [Current thread is 1 (Thread 0x7fffa740f100 (LWP 1051))] (gdb) bt #0 0x7fffaa36b444 in ?? () from /lib/powerpc64-linux-gnu/libflam3.so.0 #1 0x7fffaa36bad0 in ?? () from /lib/powerpc64-linux-gnu/libflam3.so.0 #2 0x7fffa9c9b010 in start_thread (arg=0x7fffa740f100) at pthread_create.c:444 #3 0x7fffa9d3e364 in .LY__clone () at ../sysdeps/unix/sysv/linux/powerpc/powerpc64/clone.S:107 (gdb) (gdb) noshare (gdb) share ... (gdb) bt #0 iter_thread_int (fth=0x157681210) at rect.c:500 #1 0x7fffaa36bad0 in iter_thread_float () at rect.c:253 #2 0x7fffa9c9b010 in start_thread (arg=0x7fffa740f100) at pthread_create.c:444 #3 0x7fffa9d3e364 in .LY__clone () at ../sysdeps/unix/sysv/linux/powerpc/powerpc64/clone.S:107 (gdb) (gdb) directory /home/benutzer/source/flam3/orig/flam3-3.1.1+ds2 Source directories searched: /home/benutzer/source/flam3/orig/flam3-3.1.1+ds2:$cdir:$cwd (gdb) list iter_thread_int 248 pthread_exit((void *)0); 249#endif 250 251 } 252 253 static void iter_thread(void *fth) { 254double sub_batch; 255int j; 256flam3_thread_helper *fthp = (flam3_thread_helper *)fth; 257flam3_iter_constants *ficp = fthp->fic; 258struct timespec pauset; 259int SBS = ficp->spec->sub_batch_size; 260int fuse; 261int cmap_size = ficp->cmap_size; 262int cmap_size_m1 = ficp->cmap_size-1; 263 264double eta = 0.0;
Bug#1067639: sasl2-bin: terminates with smashed stack and kills qemu-user?!
Hello, I tried to find some more information, with the help of a prebuilt full-system VM image. On Thu, 4 Apr 2024 21:00:59 + (UTC) Thorsten Glaser wrote: Sometimes, it does not crash with a smashed stack but instead: Setting up sasl2-bin (2.1.28+dfsg1-6+b1) ... BDB0002 __fop_file_setup: Retry limit (100) exceeded saslpasswd2: generic failure This looks to be a result of the pre-existing /etc/__db.sasldb2. If this file gets removed the stack smashing occurs again. By some experimenting I could convince gdb to load the debug symbols. And the stack seems to point into function __os_unique_id from libdb-5.3.so. Unfortunately I am not sure where the canary gets overwritten. Kind regards, Bernhard https://people.debian.org/~gio/dqib/ https://gitlab.com/giomasce/dqib/-/artifacts https://gitlab.com/giomasce/dqib/-/jobs/6565595565/artifacts/download?file_type=archive apt install gdb sasl2-bin sasl2-bin-dbgsym libsasl2-2-dbgsym libsasl2-modules-db-dbgsym apt install libc6-dbg libc6-dbgsym db-util db5.3-util libldap-2.5-0 libldap-common libsasl2-2 libsasl2-2-dbgsym libsasl2-modules libsasl2-modules-db export DEBUGINFOD_URLS="https://debuginfod.debian.net; rm /etc/__db.sasldb2 echo -e "test\ntest" > exclam gdb -q file /usr/sbin/saslpasswd2 run -c 'no:such:user' https://debuginfod.debian.net> Enable debuginfod for this session? (y or [n]) y Debuginfod has been enabled. To make this setting permanent, add 'set debuginfod enabled on' to .gdbinit. Downloading separate debug info for /usr/sbin/saslpasswd2 (No debugging symbols found in /usr/sbin/saslpasswd2) (gdb) run -c 'no:such:user' , fname=0xc0605cb9 "/etc/sasldb2", dname=0x0, type=DB_HASH, flags=1, mode=432) at ../src/db/db_iface.c:1193 #13 0xc0604248 in ?? () #14 0xd00087b0 in ?? () #15 0x in ?? () (gdb) shell objdump --all-headers /usr/lib/m68k-linux-gnu/sasl2/libsasldb.so.2.0.25 | grep .text 11 .text 27f0 138c 138c 138c 2**2 (gdb) print/x 0x138c + 0xc0602000 $4 = 0xc060338c (gdb) add-symbol-file /usr/lib/m68k-linux-gnu/sasl2/libsasldb.so.2.0.25 0xc060338c add symbol table from file "/usr/lib/m68k-linux-gnu/sasl2/libsasldb.so.2.0.25" at .text_addr = 0xc060338c (y or n) y Reading symbols from /usr/lib/m68k-linux-gnu/sasl2/libsasldb.so.2.0.25... Reading symbols from /usr/lib/debug/.build-id/29/c8e688eb61b57bcd21794b5403feefe1272dfd.debug... (gdb) bt ... #15 0xc0603572 in sasldb_auxprop_store (glob_context=0x0, sparams=0xd00077b8, ctx=0xd0007a58, user=0xeed9 "no:such:user", ulen=12) at ../../plugins/sasldb.c:258 #16 0xc002d26c in ?? () #17 0x in ?? () (gdb) shell cat /proc/10276/maps | grep -i -E "^c00" c000-c002 r-xp 08:01 535730 /usr/lib/m68k-linux-gnu/ld.so.1 c002-c0021000 rw-p 00:00 0 c0021000-c0022000 r--p 00021000 08:01 535730 /usr/lib/m68k-linux-gnu/ld.so.1 c0022000-c0024000 rw-p 00022000 08:01 535730 /usr/lib/m68k-linux-gnu/ld.so.1 c0028000-c003c000 r-xp 08:01 539155 /usr/lib/m68k-linux-gnu/libsasl2.so.2.0.25 c003c000-c003d000 ---p 00014000 08:01 539155 /usr/lib/m68k-linux-gnu/libsasl2.so.2.0.25 c003d000-c003e000 r--p 00015000 08:01 539155 /usr/lib/m68k-linux-gnu/libsasl2.so.2.0.25 c003e000-c003f000 rw-p 00016000 08:01 539155 /usr/lib/m68k-linux-gnu/libsasl2.so.2.0.25 c004-c01b1000 r-xp 08:01 535733 /usr/lib/m68k-linux-gnu/libc.so.6 (gdb) shell objdump --all-headers /usr/lib/m68k-linux-gnu/libsasl2.so.2.0.25 | grep .text 12 .text e284 3db0 3db0 3db0 2**2 (gdb) print/x 0x3db0 + 0xc0028000 $5 = 0xc002bdb0 (gdb) add-symbol-file /usr/lib/m68k-linux-gnu/libsasl2.so.2.0.25 0xc002bdb0 add symbol table from file "/usr/lib/m68k-linux-gnu/libsasl2.so.2.0.25" at .text_addr = 0xc002bdb0 (y or n) y Reading symbols from /usr/lib/m68k-linux-gnu/libsasl2.so.2.0.25... Reading symbols from /usr/lib/debug/.build-id/0f/8954c0644d1a9efec7973fb3198b8fd7649d5f.debug... (gdb) set width 0 (gdb) set pagination off (gdb) bt ... #17 0xc00366dc in sasl_setpass (conn=0xd0006670, user=0xeed9 "no:such:user", pass=0xd0006608 "test\ntest", passlen=9, oldpass=0x0, oldpasslen=0, flags=1) at ../../lib/server.c:186 #18 0xd0001534 in ?? () ... (gdb) shell cat /proc/10276/maps | grep -i -E "^d00" d000-d0002000 r-xp 08:01 539212 /usr/sbin/saslpasswd2 d0003000-d0004000 r--p 3000 08:01 539212 /usr/sbin/saslpasswd2 d0004000-d0005000 rw-p 4000 08:01 539212 /usr/sbin/saslpasswd2 d0005000-d0026000 rwxp 00:00 0 [heap] (gdb) shell objdump --all-headers /usr/sbin/saslpasswd2 | grep .text 13 .text 0950 10b8 10b8 10b8 2**2 (gdb) print/x 0x10b8 + 0xd000 $6 = 0xd00010b8 (gdb) add-symbol-file /usr/sbin/saslpasswd2 0xd00010b8 add symbol table from file "/usr/sbin/saslpasswd2" at .text_addr = 0xd00010b8 (y or n) y Reading symbols from /usr/sbin/saslpasswd2... Reading symbols from
Bug#1056555: thunar: segfault when ejecting drive
Hello ng, On Wed, 22 Nov 2023 22:47:01 -0300 ng wrote: [18950.426861] Thunar[3027]: segfault at 0 ip 5615a96c98cc sp 7ffd2dbd7320 error 4 in thunar[5615a964+92000] likely on CPU 7 (core 3, socket 0) [18950.426895] Code: f3 48 83 ec 38 64 48 8b 04 25 28 00 00 00 48 89 44 24 28 31 c0 48 c7 44 24 20 00 00 00 00 48 85 f6 0f 84 77 02 00 00 48 8b 06 <48> 39 10 0f 84 f1 01 00 00 4c 8b bf 28 01 00 00 4c 39 fe 0f 84 cb This lines point to following source location: thunar/thunar-window.c, line 4000 https://sources.debian.org/src/thunar/4.18.4-1/thunar/thunar-window.c/#L4000 3999 /* if the view already has the correct type then just return */ 4000 if (view != NULL && G_TYPE_FROM_INSTANCE (view) == view_type) 4001 return; Unfortunately this might yet not be enough for the maintainer to fix the issue. Following link contains a few pointers how to get a backtrace of a crash: https://wiki.debian.org/HowToGetABacktrace Kind regards, Bernhard https://wiki.debian.org/InterpretingKernelOutputAtProcessCrash [18950.426861] Thunar[3027]: segfault at 0 ip 5615a96c98cc sp 7ffd2dbd7320 error 4 in thunar[5615a964+92000] likely on CPU 7 (core 3, socket 0) [18950.426895] Code: f3 48 83 ec 38 64 48 8b 04 25 28 00 00 00 48 89 44 24 28 31 c0 48 c7 44 24 20 00 00 00 00 48 85 f6 0f 84 77 02 00 00 48 8b 06 <48> 39 10 0f 84 f1 01 00 00 4c 8b bf 28 01 00 00 4c 39 fe 0f 84 cb 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 "f3 48 83 ec 38 64 48 8b 04 25 28 00 00 00 48 89 44 24 28 31 c0 48 c7 44 24 20 00 00 00 00 48 85 f6 0f 84 77 02 00 00 48 8b 06 <48> 39 10 0f 84 f1 01 00 00 4c 8b bf 28 01 00 00 4c 39 fe 0f 84 cb" \ | sed 's/[<>]//g' | sed 's/ /, 0x/g' # Bookworm/stable amd64 qemu VM 2024-04-09 apt update apt install gdb thunar thunar-dbgsym gdb -q set width 0 set pagination off file /usr/bin/thunar tb main run pipe info target | grep "\.text" find /b 0x5557fdb0, 0x5560bad9, 0xf3, 0x48, 0x83, 0xec, 0x38, 0x64, 0x48, 0x8b, 0x04, 0x25, 0x28, 0x00, 0x00, 0x00, 0x48, 0x89, 0x44, 0x24, 0x28, 0x31, 0xc0, 0x48, 0xc7, 0x44, 0x24, 0x20, 0x00, 0x00, 0x00, 0x00, 0x48, 0x85, 0xf6, 0x0f, 0x84, 0x77, 0x02, 0x00, 0x00, 0x48, 0x8b, 0x06, 0x48, 0x39, 0x10, 0x0f, 0x84, 0xf1, 0x01, 0x00, 0x00, 0x4c, 0x8b, 0xbf, 0x28, 0x01, 0x00, 0x00, 0x4c, 0x39, 0xfe, 0x0f, 0x84, 0xcb b * (0x556038a2 + 42) info b disassemble /r 0x556038a2, 0x556038a2 + 62 benutzer@debian:~$ gdb -q (gdb) set width 0 (gdb) set pagination off (gdb) file /usr/bin/thunar Reading symbols from /usr/bin/thunar... Reading symbols from /usr/lib/debug/.build-id/1c/0053bee14d3fb731923319e68ac183a810d9db.debug... (gdb) tb main Temporary breakpoint 1 at 0x2bdd0: file ./thunar/main.c, line 49. (gdb) run Starting program: /usr/bin/thunar [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=0x7fffe4d8) at ./thunar/main.c:49 49 ./thunar/main.c: Datei oder Verzeichnis nicht gefunden. (gdb) pipe info target | grep "\.text" 0x5557fdb0 - 0x5560bad9 is .text ... (gdb) find /b 0x5557fdb0, 0x5560bad9, 0xf3, 0x48, 0x83, 0xec, 0x38, 0x64, 0x48, 0x8b, 0x04, 0x25, 0x28, 0x00, 0x00, 0x00, 0x48, 0x89, 0x44, 0x24, 0x28, 0x31, 0xc0, 0x48, 0xc7, 0x44, 0x24, 0x20, 0x00, 0x00, 0x00, 0x00, 0x48, 0x85, 0xf6, 0x0f, 0x84, 0x77, 0x02, 0x00, 0x00, 0x48, 0x8b, 0x06, 0x48, 0x39, 0x10, 0x0f, 0x84, 0xf1, 0x01, 0x00, 0x00, 0x4c, 0x8b, 0xbf, 0x28, 0x01, 0x00, 0x00, 0x4c, 0x39, 0xfe, 0x0f, 0x84, 0xcb 0x556038a2 1 pattern found. (gdb) b * (0x556038a2 + 42) Breakpoint 2 at 0x556038cc: file ./thunar/thunar-window.c, line 4000. (gdb) info b Num Type Disp Enb AddressWhat 2 breakpoint keep y 0x556038cc in thunar_window_replace_view at ./thunar/thunar-window.c:4000 (gdb) disassemble /r 0x556038a2, 0x556038a2 + 62 Dump of assembler code from 0x556038a2 to 0x556038e0: 0x556038a2 : f3 48 83 ec 38 repz sub $0x38,%rsp 0x556038a7 : 64 48 8b 04 25 28 00 00 00 mov%fs:0x28,%rax 0x556038b0 : 48 89 44 24 28 mov%rax,0x28(%rsp) 0x556038b5 : 31 c0 xor%eax,%eax 0x556038b7 : 48 c7 44 24 20 00 00 00 00 movq $0x0,0x20(%rsp) 0x556038c0 : 48 85 f6 test %rsi,%rsi 0x556038c3 : 0f 84 77 02 00 00 je 0x55603b40 0x556038c9 : 48 8b 06 mov(%rsi),%rax 0x556038cc : 48 39 10 cmp%rdx,(%rax)<<< 0x556038cf : 0f 84 f1 01 00 00 je 0x55603ac6 0x556038d5 : 4c 8b bf 28 01 00 00 mov
Bug#1053433: mate-panel: mate-clock segfaults on return from hibernation
Hello Olly, (gdb) bt #0 __pthread_kill_implementation (threadid=, signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44 #1 0x7fa84248315f in __pthread_kill_internal (signo=6, threadid=) at ./nptl/pthread_kill.c:78 #2 0x7fa842435472 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 #3 0x7fa84241f4b2 in __GI_abort () at ./stdlib/abort.c:79 #4 0x7fa84276d5dd in () #5 0x in () I read that as it's already aborting when it segfaults, so maybe that's not helpful in knowing the root cause. I'm happy to debug further if someone tells me what to try. This means the instruction just before 0x7fa84276d5dd is most probably a call to function abort. Usually this is done if some assertion fails. Therefore there might something like "assertion failed" in the logs at this time. Unfortunately 0x7fa84276d5dd might be inside of a shared object. And for it is no -dbgsym package installed. To find out which shared object you might have a look into the output of `info share`. If you receive such a crash you could create a core dump with gdb command `generate-core-file`. Or install some core dump collector, e.g. systemd-coredump. With this after a crash happened one can inspect it via coredumpctl list coredumpctl gdb This link contains some more ways to debug and to install the dbgsym packages: https://wiki.debian.org/HowToGetABacktrace Kind regards, Bernhard
Bug#993018: valgrind: vgcore files unusable in gdb / does not load debug symbols
control: forwarded 993018 https://bugs.kde.org/show_bug.cgi?id=485134 control: found 993018 1:3.20.0-2.1 Hello, I got recently remembered about this bug and patch. So I try to find out what upstream thinks about this. It can still be observed with current version in Trixie/testing. Kind regards, Bernhard
Bug#1040496: qt6-virtualkeyboard FTBFS with parallel=1: qmlcachegen segfaults
Hello, I tried to reproduce this inside a minimal stable/bookworm VM and received a qmlcachegen crash. See attached file for details. The resulting backtrace is quite similar to that found in: https://bugreports.qt.io/browse/QTBUG-117361 Might avoid the crash, but cannot say if this would make the build succeed. Kind regards, Bernhard # 2024-04-02 stable/bookworm amd64 qemu VM apt install systemd-coredump gdb libqt6qmlcompiler6-dbgsym apt build-dep qt6-virtualkeyboard mkdir /home/benutzer/source/qt6-virtualkeyboard/orig -p cd/home/benutzer/source/qt6-virtualkeyboard/orig apt source qt6-virtualkeyboard cd /home/benutzer/source/qt6-virtualkeyboard cp orig try1 -a cd try1/qt6-virtualkeyboard-6.4.2+dfsg DEB_BUILD_OPTIONS=parallel=1 dpkg-buildpackage ... [110/301] cd /home/benutzer/source/qt6-virtualkeyboard/try1/qt6-virtualkeyboard-6.4.2+dfsg/obj-x86_64-linux-gnu/src/components && /usr/bin/cmake -E make_directory /home/benutzer/source/qt6-virtualkeyboard/try1/qt6-virtualkeyboard-6.4.2+dfsg/obj-x86_64-linux-gnu/src/components/.rcc/qmlcache && /usr/lib/qt6/libexec/qmlcachegen --bare --resource-path /qt-project.org/imports/QtQuick/VirtualKeyboard/Components/Keyboard.qml -I /home/benutzer/source/qt6-virtualkeyboard/try1/qt6-virtualkeyboard-6.4.2+dfsg/obj-x86_64-linux-gnu/lib/x86_64-linux-gnu/qt6/qml -I /usr/lib/x86_64-linux-gnu/qt6/qml -i /home/benutzer/source/qt6-virtualkeyboard/try1/qt6-virtualkeyboard-6.4.2+dfsg/obj-x86_64-linux-gnu/lib/x86_64-linux-gnu/qt6/qml/QtQuick/VirtualKeyboard/Components/qmldir --resource /home/benutzer/source/qt6-virtualkeyboard/try1/qt6-virtualkeyboard-6.4.2+dfsg/obj-x86_64-linux-gnu/src/components/.rcc/qmake_QtQuick_VirtualKeyboard_Components.qrc --resource /home/benutzer/source/qt6-virtualkeyboard/try1/qt6-virtualkeyboard-6.4.2+dfsg/obj-x86_64-linux-gnu/src/components/.rcc/qtvkbcomponentsplugin_raw_qml_0.qrc -o /home/benutzer/source/qt6-virtualkeyboard/try1/qt6-virtualkeyboard-6.4.2+dfsg/obj-x86_64-linux-gnu/src/components/.rcc/qmlcache/qtvkbcomponentsplugin_Keyboard_qml.cpp /home/benutzer/source/qt6-virtualkeyboard/try1/qt6-virtualkeyboard-6.4.2+dfsg/src/components/Keyboard.qml FAILED: src/components/.rcc/qmlcache/qtvkbcomponentsplugin_Keyboard_qml.cpp /home/benutzer/source/qt6-virtualkeyboard/try1/qt6-virtualkeyboard-6.4.2+dfsg/obj-x86_64-linux-gnu/src/components/.rcc/qmlcache/qtvkbcomponentsplugin_Keyboard_qml.cpp cd /home/benutzer/source/qt6-virtualkeyboard/try1/qt6-virtualkeyboard-6.4.2+dfsg/obj-x86_64-linux-gnu/src/components && /usr/bin/cmake -E make_directory /home/benutzer/source/qt6-virtualkeyboard/try1/qt6-virtualkeyboard-6.4.2+dfsg/obj-x86_64-linux-gnu/src/components/.rcc/qmlcache && /usr/lib/qt6/libexec/qmlcachegen --bare --resource-path /qt-project.org/imports/QtQuick/VirtualKeyboard/Components/Keyboard.qml -I /home/benutzer/source/qt6-virtualkeyboard/try1/qt6-virtualkeyboard-6.4.2+dfsg/obj-x86_64-linux-gnu/lib/x86_64-linux-gnu/qt6/qml -I /usr/lib/x86_64-linux-gnu/qt6/qml -i /home/benutzer/source/qt6-virtualkeyboard/try1/qt6-virtualkeyboard-6.4.2+dfsg/obj-x86_64-linux-gnu/lib/x86_64-linux-gnu/qt6/qml/QtQuick/VirtualKeyboard/Components/qmldir --resource /home/benutzer/source/qt6-virtualkeyboard/try1/qt6-virtualkeyboard-6.4.2+dfsg/obj-x86_64-linux-gnu/src/components/.rcc/qmake_QtQuick_VirtualKeyboard_Components.qrc --resource /home/benutzer/source/qt6-virtualkeyboard/try1/qt6-virtualkeyboard-6.4.2+dfsg/obj-x86_64-linux-gnu/src/components/.rcc/qtvkbcomponentsplugin_raw_qml_0.qrc -o /home/benutzer/source/qt6-virtualkeyboard/try1/qt6-virtualkeyboard-6.4.2+dfsg/obj-x86_64-linux-gnu/src/components/.rcc/qmlcache/qtvkbcomponentsplugin_Keyboard_qml.cpp /home/benutzer/source/qt6-virtualkeyboard/try1/qt6-virtualkeyboard-6.4.2+dfsg/src/components/Keyboard.qml Segmentation fault (core dumped) ninja: build stopped: subcommand failed. dh_auto_build: error: cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8 ninja -j1 -v returned exit code 1 make: *** [debian/rules:8: binary] Fehler 1 dpkg-buildpackage: Fehler: Unterprozess debian/rules binary lieferte Exitstatus 2 benutzer@debian:~/source/qt6-virtualkeyboard/try1/qt6-virtualkeyboard-6.4.2+dfsg$ dmesg [ 431.390156] qmlcachegen[5680]: segfault at 0 ip 7fde080d0672 sp 7ffe33185b60 error 4 in libQt6QmlCompiler.so.6.4.2[7fde0804d000+106000] likely on CPU 5 (core 5, socket 0) [ 431.390173] Code: 64 cd f7 ff 0f 1f 40 00 41 57 41 56 41 55 41 54 55 48 89 fd 53 48 89 f3 48 83 ec 28 64 48 8b 04 25 28 00 00 00 48 89 44 24 18 <48> 8b 06 48 c7 06 00 00 00 00 4c 8b 27 48 89 07 4d 85 e4 74 10 4c journalctl -e Apr 02 22:45:36 debian systemd-coredump[5682]: [] Process 5680 (qmlcachegen) of user 1000 dumped core. Stack trace of thread 5680: #0 0x7fde080d0672 n/a (libQt6QmlCompiler.so.6 + 0xa8672)
Bug#1040382: slapd: debian12 ships with slapd-2.5.13+dfsg-5 which crashes (segfault in dynlist.la).
On Wed, 24 Jan 2024 15:07:46 +0100 wouldsmina wrote: 2024-01-24T09:38:16.810558+01:00 ldap kernel: [ 1553.168747] slapd[13335]: segfault at 0 ip 7fc2370b49c1 sp 7fbd359fc0c0 error 4 in dynlist-2.5.so.0.1.8[7fc2370b1000+6000] likely on CPU 1 (core 0, socket 2) 2024-01-24T09:38:16.810568+01:00 ldap kernel: [ 1553.168761] Code: 48 29 d0 48 89 d7 48 89 c1 31 c0 83 c1 6c c1 e9 03 f3 48 ab 48 8b 84 24 10 02 00 00 4c 89 ef c7 84 24 a0 00 00 00 03 00 00 00 <48> 8b 00 ff 50 78 44 39 73 64 74 09 45 84 e4 0f 85 22 03 00 00 48 Hello, I tried to get back to the source line of this dmesg output, maybe it is of any help. It points to: dynlist_search at ../../../../../servers/slapd/overlays/dynlist.c:1817 1817(void)o.o_bd->be_search( , ); This is the same line shown in the attachment of the upstream bug report. Attached file shows how I got to this line. Kind regards, Bernhardslapd[13335]: segfault at 0 ip 7fc2370b49c1 sp 7fbd359fc0c0 error 4 in dynlist-2.5.so.0.1.8[7fc2370b1000+6000] likely on CPU 1 (core 0, socket 2) Code: 48 29 d0 48 89 d7 48 89 c1 31 c0 83 c1 6c c1 e9 03 f3 48 ab 48 8b 84 24 10 02 00 00 4c 89 ef c7 84 24 a0 00 00 00 03 00 00 00 <48> 8b 00 ff 50 78 44 39 73 64 74 09 45 84 e4 0f 85 22 03 00 00 48 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 "48 29 d0 48 89 d7 48 89 c1 31 c0 83 c1 6c c1 e9 03 f3 48 ab 48 8b 84 24 10 02 00 00 4c 89 ef c7 84 24 a0 00 00 00 03 00 00 00 <48> 8b 00 ff 50 78 44 39 73 64 74 09 45 84 e4 0f 85 22 03 00 00 48" \ | sed 's/[<>]//g' | sed 's/ /, 0x/g' find /b ..., ..., 0x48, 0x29, 0xd0, 0x48, 0x89, 0xd7, 0x48, 0x89, 0xc1, 0x31, 0xc0, 0x83, 0xc1, 0x6c, 0xc1, 0xe9, 0x03, 0xf3, 0x48, 0xab, 0x48, 0x8b, 0x84, 0x24, 0x10, 0x02, 0x00, 0x00, 0x4c, 0x89, 0xef, 0xc7, 0x84, 0x24, 0xa0, 0x00, 0x00, 0x00, 0x03, 0x00, 0x00, 0x00, 0x48, 0x8b, 0x00, 0xff, 0x50, 0x78, 0x44, 0x39, 0x73, 0x64, 0x74, 0x09, 0x45, 0x84, 0xe4, 0x0f, 0x85, 0x22, 0x03, 0x00, 0x00, 0x48 # 2024-04-02 stable/bookworm amd64 qemu VM apt install gdb slapd slapd-dbgsym mkdir /home/benutzer/source/slapd/orig -p cd/home/benutzer/source/slapd/orig apt source slapd gdb -q set width 0 set pagination off file /usr/sbin/slapd tb main run call dlopen("/usr/lib/ldap/dynlist-2.5.so.0.1.8",0x102) pipe info target | grep "\.text" find /b 0x774874a0, 0x7748ccaa, 0x48, 0x29, 0xd0, 0x48, 0x89, 0xd7, 0x48, 0x89, 0xc1, 0x31, 0xc0, 0x83, 0xc1, 0x6c, 0xc1, 0xe9, 0x03, 0xf3, 0x48, 0xab, 0x48, 0x8b, 0x84, 0x24, 0x10, 0x02, 0x00, 0x00, 0x4c, 0x89, 0xef, 0xc7, 0x84, 0x24, 0xa0, 0x00, 0x00, 0x00, 0x03, 0x00, 0x00, 0x00, 0x48, 0x8b, 0x00, 0xff, 0x50, 0x78, 0x44, 0x39, 0x73, 0x64, 0x74, 0x09, 0x45, 0x84, 0xe4, 0x0f, 0x85, 0x22, 0x03, 0x00, 0x00, 0x48 b * (0x7748a997 + 42) info b disassemble /r 0x7748a997, 0x7748a997 + 62 directory /home/benutzer/source/slapd/orig/openldap-2.5.13+dfsg/servers/slapd/overlays benutzer@debian:~$ gdb -q (gdb) set width 0 (gdb) set pagination off (gdb) file /usr/sbin/slapd Reading symbols from /usr/sbin/slapd... Reading symbols from /usr/lib/debug/.build-id/40/63a68f1de0ddfe5b5d68cb4f6869587bda460a.debug... (gdb) tb main Temporary breakpoint 1 at 0x20b50: file ../../../../servers/slapd/main.c, line 408. (gdb) run Starting program: /usr/sbin/slapd [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=0x7fffe4d8) at ../../../../servers/slapd/main.c:408 408 ../../../../servers/slapd/main.c: Datei oder Verzeichnis nicht gefunden. (gdb) call dlopen("/usr/lib/ldap/dynlist-2.5.so.0.1.8",0x102) $1 = (void *) 0x557231f0 (gdb) pipe info target | grep "\.text" 0x55574aa0 - 0x556375c4 is .text 0x77fcc060 - 0x77ff0d51 is .text in /lib64/ld-linux-x86-64.so.2 0x77fc96b0 - 0x77fc9ced is .text in system-supplied DSO at 0x77fc9000 0x77f72260 - 0x77fa8f06 is .text in /lib/x86_64-linux-gnu/libldap-2.5.so.0 0x77f53670 - 0x77f5a22a is .text in /lib/x86_64-linux-gnu/liblber-2.5.so.0 0x77f365b0 - 0x77f47005 is .text in /lib/x86_64-linux-gnu/libsasl2.so.2 0x77ef9040 - 0x77f0e33c is .text in /lib/x86_64-linux-gnu/libcrypt.so.1 0x77edf010 - 0x77eeefdd is .text in /lib/x86_64-linux-gnu/libslapi-2.5.so.0 0x77ecb490 - 0x77ecf5e6 is .text in /lib/x86_64-linux-gnu/libltdl.so.7 0x77ec06e0 - 0x77ec415e is .text in /lib/x86_64-linux-gnu/libwrap.so.0 0x77d02380 - 0x77e55f2d is .text in /lib/x86_64-linux-gnu/libc.so.6 0x77a3aac0 - 0x77b69520 is .text
Bug#1035595: gl-117: Crash on exit
> malloc(): unsorted double linked list corrupted > abort Hello, I could not reproduce this in a minimal bullseye or trixie amd64 VM, and also not in a bookworm i386 VM. But valgrind shows a few "Mismatched free() / delete / delete []" or "Conditional jump or move depends on uninitialised value(s)". Maybe those are responsible for the malloc abort. Attached file fixes most of the issues shown by valgrind entering the main menu. Kind regards, BernhardDescription: Fix a few delete and uninitilised values shown by valgrind Author: Bernhard Übelacker Last-Update: 2024-03-30 Index: gl-117-1.3.2/src/3ds.cpp === --- gl-117-1.3.2.orig/src/3ds.cpp +++ gl-117-1.3.2/src/3ds.cpp @@ -69,7 +69,7 @@ BinaryFile::BinaryFile (char *filename) BinaryFile::~BinaryFile () { - delete data; + delete[] data; } int BinaryFile::readFloat (float *f) @@ -503,7 +503,7 @@ void CLoad3DS::ReadUVCoordinates (CObjec for (int i = 0; i < object->numTexVertex; i ++) object->vertex [i].tex.take ( [i]); - delete p; + delete[] p; } void CLoad3DS::ReadVertices (CObject *object, Chunk *previousChunk) @@ -532,7 +532,7 @@ void CLoad3DS::ReadVertices (CObject *ob object->vertex [i].vector.y = object->vertex [i].vector.z; object->vertex [i].vector.z = -fTempY; } - delete p; + delete[] p; } void CLoad3DS::ReadObjectMaterial (CModel *model, CObject *object, Chunk *previousChunk) Index: gl-117-1.3.2/src/model.cpp === --- gl-117-1.3.2.orig/src/model.cpp +++ gl-117-1.3.2/src/model.cpp @@ -616,7 +616,7 @@ CModel::~CModel () delete object [i]; if (refpoint) { -delete refpoint; +delete[] refpoint; } } Index: gl-117-1.3.2/src/gl.cpp === --- gl-117-1.3.2.orig/src/gl.cpp +++ gl-117-1.3.2/src/gl.cpp @@ -239,10 +239,11 @@ void GL::shadeSmooth () void GL::enableFog (float view) { - float fcol [3]; + float fcol [4]; fcol [0] = fogcolor [0] * foglum; fcol [1] = fogcolor [1] * foglum; fcol [2] = fogcolor [2] * foglum; + fcol [3] = 0.0; glEnable (GL_FOG); glFogfv (GL_FOG_COLOR, fcol); glFogf (GL_FOG_DENSITY, 0.1); Index: gl-117-1.3.2/src/aiobject.cpp === --- gl-117-1.3.2.orig/src/aiobject.cpp +++ gl-117-1.3.2/src/aiobject.cpp @@ -87,6 +87,7 @@ void DynamicObj::dinit () forcex = 0; forcez = 0; forcey = 0; maxthrust = 0.3; braking = 0/*0.99*/; manoeverability = 0.5; thrust = maxthrust; recthrust = thrust; recheight = 5.0; + realspeed = 1.0; ttl = -1; shield = 0.01F; maxshield = 0.01F; immunity = 0;
Bug#1034685: glob2: Clicking “Settings” and then clicking “Ok” crashes/hangs glob2
Hello, this issue is still present with current testing. For some weird reason this loop in line 195 is never left. Putting a printf into this loop confirms that n counts correctly, but the loop is not left when it reaches 13 (NB_BUILDING). Strangely a similar loop with the same condition in line 186 works. Not being able to explain it, I wonder if this might be a GCC issue? Upstream made a change to this line in [1], changing the condition from "n, filename=) at /usr/include/c++/13/bits/basic_string.h:222 222 _M_data() const (gdb) bt #0 0x55723317 in Settings::save (this=, filename=) at /usr/include/c++/13/bits/basic_string.h:222 #1 0x5572d613 in SettingsScreen::onAction (this=0x7fff93c0, source=, action=, par1=, par2=) at src/SettingsScreen.cpp:373 #2 0x557d1445 in GAGGUI::Screen::dispatchEvents (this=this@entry=0x7fff93c0, event=event@entry=0x7fff9260) at libgag/src/GUIBase.cpp:596 #3 0x557d185b in GAGGUI::Screen::execute (this=this@entry=0x7fff93c0, gfx=0x55920560, stepLength=stepLength@entry=40) at libgag/src/GUIBase.cpp:506 #4 0x5566cfb0 in Glob2::run (this=this@entry=0x7fffe357, argc=, argv=) at src/Glob2.cpp:348 #5 0x555b58fa in main (argc=, argv=) at src/Glob2.cpp:409 (gdb) print n $2 = 8331033 (gdb) print keyname $3 = "defaultFlagRadius[8331033]" src/Settings.cpp: 195 for(int n=0; n(n)+"]"; 198 Utilities::streamprintf(stream, "%s=%i\n", keyname.c_str(), defaultFlagRadius[n]); 199 } [1] https://github.com/Globulation2/glob2/commit/30d272363d14cb2f3494e8dc7ef86e147b6b
Bug#1033222: libgl1-mesa-dri: Segmentation fault with nouveau_dri.so
On Mon, 20 Mar 2023 11:34:43 +0100 Christophe Lohr wrote: Package: libgl1-mesa-dri Version: 22.3.3-1 Severity: normal X-Debbugs-Cc: christophe.l...@cegetel.net Dear Maintainer, Xorg is carshing with a segfault: (EE) Backtrace: (EE) 0: /usr/lib/xorg/Xorg (OsLookupColor+0x139) [0x55c365ce4cf9] (EE) 1: /lib/x86_64-linux-gnu/libc.so.6 (__sigaction+0x40) [0x7f00ef25af90] (EE) 2: /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so (nouveau_drm_screen_create+0x4406c) [0x7f00ed75999c] (EE) 3: /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so (nouveau_drm_screen_create+0x1e4c9) [0x7f00ed733df9] (EE) 4: /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so (nouveau_drm_screen_create+0x266) [0x7f00ed715b96] (EE) unw_get_proc_name failed: no unwind info found [-10] ../.. Fatal server error: (EE) Caught signal 11 (Segmentation fault). Server aborting (EE) Hello, tried to get some symbols for the given backtrace. 2: 0x76b5999c : mov0x20(%rax),%rdi in nouveau_pushbuf_destroy at ../src/gallium/drivers/nouveau/nouveau_screen.c:244 3:0x76b33df4 :call 0x76b59950 in nvc0_screen_destroy at ../src/gallium/drivers/nouveau/nvc0/nvc0_screen.c:740 4:0x76b15b93 : call *0x10(%rax) in nouveau_drm_screen_create at ../src/gallium/winsys/nouveau/drm/nouveau_drm_winsys.c:133 An internet search leads to: https://docs.mesa3d.org/relnotes/22.3.7.html Sam Edwards (1): nouveau: Fix null dereference in nouveau_pushbuf_destroy So this looks exactly like the place of above frame 2, and the issue might be fixed by this commit: https://gitlab.freedesktop.org/mesa/mesa/-/commit/4585f21de47af5e2b1a018a052ac0aaf5f1f3ac5 https://gitlab.freedesktop.org/italove/mesa/-/commit/9de997bde67df43a9e10a05f9b48419ee4cfec25 https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21611 Unfortunately stable/bookworm seems to just have received mesa 22.3.6: https://sources.debian.org/src/mesa/22.3.6-1%2Bdeb12u1/src/gallium/drivers/nouveau/nouveau_screen.c/#L244 A workaround might be to locally rebuild mesa with this patch applied. And testing/trixie might no longer be affected with a mesa version above 22.3.7. Kind regards, Bernhard # 2024-03-26 Debian stable/bookworm qemu x86_64 VM apt install libgl1-mesa-dri gdb coreutils-dbgsym wget https://snapshot.debian.org/archive/debian/20230113T215719Z/pool/main/m/mesa/libgl1-mesa-dri_22.3.3-1_amd64.deb wget https://snapshot.debian.org/archive/debian/20230113T215719Z/pool/main/m/mesa/libglapi-mesa_22.3.3-1_amd64.deb wget https://snapshot.debian.org/archive/debian-debug/20230113T151646Z/pool/main/m/mesa/libglapi-mesa-dbgsym_22.3.3-1_amd64.deb dpkg -i *22.3.3* gdb -q --args /bin/true set pagination off set width 0 set environment LD_DEBUG = libs tb main run call dlopen("/usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so",0x101) disassemble nouveau_drm_screen_create+0x266-20,nouveau_drm_screen_create+0x266+20 b *nouveau_drm_screen_create+611 disassemble nouveau_drm_screen_create+0x1e4c9-20,nouveau_drm_screen_create+0x1e4c9+20 b* 0x76b33df4 disassemble nouveau_drm_screen_create+0x4406c-20,nouveau_drm_screen_create+0x4406c+20 b *0x76b5999c info b
Bug#1055607: gmemusage crashes immediately
Hello, On Wed, 08 Nov 2023 20:17:49 +0100 =?utf-8?q?Andr=C3=A9_Offringa?= wrote: $ gmemusage realloc(): invalid next size Aborted Looks like caused by having not enough space for process names longer than 13 characters. A package built with the modification below shows no longer this crash. Kind regard, Bernhard (gdb) bt #0 __pthread_kill_implementation (threadid=, signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44 #1 0x7f43d244b15f in __pthread_kill_internal (signo=6, threadid=) at ./nptl/pthread_kill.c:78 #2 0x7f43d23fd472 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 #3 0x7f43d23e74b2 in __GI_abort () at ./stdlib/abort.c:79 #4 0x7f43d23e81ed in __libc_message (fmt=fmt@entry=0x7f43d255a78c "%s\n") at ../sysdeps/posix/libc_fatal.c:150 #5 0x7f43d2454a75 in malloc_printerr (str=str@entry=0x7f43d2558326 "realloc(): invalid next size") at ./malloc/malloc.c:5658 #6 0x7f43d245876c in _int_realloc (av=av@entry=0x7f43d2594c80 , oldp=oldp@entry=0x564149c00680, oldsize=oldsize@entry=912, nb=nb@entry=1808) at ./malloc/malloc.c:4836 #7 0x7f43d2459596 in __GI___libc_realloc (oldmem=oldmem@entry=0x564149c00690, bytes=bytes@entry=1792) at ./malloc/malloc.c:3477 #8 0x564148a039a5 in addProc (procname=procname@entry=0x7fffa8056900 "cpuhp/3", mem=0, rss=0) at hash.c:89 #9 0x564148a03f20 in makeProcs () at proc.c:215 #10 0x564148a02e32 in draw_window () at gmemusage.c:489 #11 0x564148a02b85 in main (argc=, argv=) at gmemusage.c:300 benutzer@debian:~$ valgrind gmemusage ==1246== Memcheck, a memory error detector ==1246== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al. ==1246== Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info ==1246== Command: gmemusage ==1246== ==1246== Invalid write of size 1 ==1246==at 0x48468E4: strcpy (vg_replace_strmem.c:553) ==1246==by 0x10B958: addProc (hash.c:101) ==1246==by 0x10BF1F: makeProcs (proc.c:215) ==1246==by 0x10AE31: draw_window (gmemusage.c:489) ==1246==by 0x10AB84: main (gmemusage.c:300) ==1246== Address 0x4e6b740 is 0 bytes after a block of size 3,584 alloc'd ==1246==at 0x484582F: realloc (vg_replace_malloc.c:1437) ==1246==by 0x10B9A4: addProc (hash.c:89) ==1246==by 0x10BF1F: makeProcs (proc.c:215) ==1246==by 0x10AE31: draw_window (gmemusage.c:489) ==1246==by 0x10AB84: main (gmemusage.c:300) ==1246== --- hash.c.orig 1998-01-14 17:43:13.0 +0100 +++ hash.c 2023-11-25 11:26:06.292932169 +0100 @@ -10,2 +10,3 @@ #include +#include #include "common.h" @@ -73,3 +74,4 @@ addProc ( char *procname , int mem , int thisproc = nextproc = procs ; - strcpy ( thisproc -> procname , procname ) ; + strncpy ( thisproc -> procname , procname , sizeof(thisproc -> procname) ) ; + thisproc -> procname[sizeof(thisproc -> procname)-1] = '\0'; thisproc -> totMem = mem ; @@ -100,3 +102,4 @@ addProc ( char *procname , int mem , int thisproc = procs + nProcs ; - strcpy ( thisproc -> procname , procname ) ; + strncpy ( thisproc -> procname , procname , sizeof(thisproc -> procname) ) ; + thisproc -> procname[sizeof(thisproc -> procname)-1] = '\0'; thisproc -> totMem = mem ;
Bug#1039695: libtracker-sparql-3.0-0: keeps segfaulting and restarting endlessly
Hell Mulas, I tried to get to the source line of you dmesg output: [254868.778098] tracker-miner-f[1916712]: segfault at 8 ip 7f9bf641bc18 sp 7fff0ca38e10 error 4 in libtracker-sparql-3.0.so.0.402.0[7f9bf63f9000+6a000] likely on CPU 2 (core 2, socket 0) [254868.778109] Code: 18 64 48 2b 04 25 28 00 00 00 75 35 48 83 c4 20 5b c3 48 8b 44 24 10 48 8d 15 84 dd 04 00 be 08 00 00 00 48 8d 3d fd 77 04 00 <48> 8b 48 08 31 c0 e8 5d de fd ff 48 8b 7c 24 10 e8 03 da fd ff eb I think this relates to this source line: https://sources.debian.org/src/tracker/3.4.2-3/src/libtracker-sparql/core/tracker-data-manager.c/#L4050 g_critical ("Could not set up interface : %s", error->message); But a full backtrace is probably still needed by the maintainer. You could probably collect one by installing systemd-coredump. Then journalctl should contain a more detailed information on which functions are involved. Kind regards, Bernhard https://wiki.debian.org/HowToGetABacktrace https://wiki.debian.org/InterpretingKernelOutputAtProcessCrash error 4 == 0b100 * bit 0 ==0: no page found * bit 1 ==0: read access * bit 2 ==1: user-mode access . [254868.778098] tracker-miner-f[1916712]: segfault at 8 ip 7f9bf641bc18 sp 7fff0ca38e10 error 4 in libtracker-sparql-3.0.so.0.402.0[7f9bf63f9000+6a000] likely on CPU 2 (core 2, socket 0) [254868.778109] Code: 18 64 48 2b 04 25 28 00 00 00 75 35 48 83 c4 20 5b c3 48 8b 44 24 10 48 8d 15 84 dd 04 00 be 08 00 00 00 48 8d 3d fd 77 04 00 <48> 8b 48 08 31 c0 e8 5d de fd ff 48 8b 7c 24 10 e8 03 da fd ff eb echo -n "find /b ..., ..., 0x" && \ echo "18 64 48 2b 04 25 28 00 00 00 75 35 48 83 c4 20 5b c3 48 8b 44 24 10 48 8d 15 84 dd 04 00 be 08 00 00 00 48 8d 3d fd 77 04 00 <48> 8b 48 08 31 c0 e8 5d de fd ff 48 8b 7c 24 10 e8 03 da fd ff eb" \ | sed 's/[<>]//g' | sed 's/ /, 0x/g' # apt install gdb tracker-miner-fs tracker-miner-fs-dbgsym libtracker-sparql-3.0-0-dbgsym gdb -q --args /usr/libexec/tracker-miner-fs-3 set width 0 set pagination off tb main run pipe info share | grep libtracker-sparql-3.0 find /b 0x77b4e120, 0x77bb49f2, 0x18, 0x64, 0x48, 0x2b, 0x04, 0x25, 0x28, 0x00, 0x00, 0x00, 0x75, 0x35, 0x48, 0x83, 0xc4, 0x20, 0x5b, 0xc3, 0x48, 0x8b, 0x44, 0x24, 0x10, 0x48, 0x8d, 0x15, 0x84, 0xdd, 0x04, 0x00, 0xbe, 0x08, 0x00, 0x00, 0x00, 0x48, 0x8d, 0x3d, 0xfd, 0x77, 0x04, 0x00, 0x48, 0x8b, 0x48, 0x08, 0x31, 0xc0, 0xe8, 0x5d, 0xde, 0xfd, 0xff, 0x48, 0x8b, 0x7c, 0x24, 0x10, 0xe8, 0x03, 0xda, 0xfd, 0xff, 0xeb b * (0x77b6dbee + 42) (gdb) info b Num Type Disp Enb AddressWhat 2 breakpoint keep y 0x77b6dc18 in setup_interface_cb at ../src/libtracker-sparql/core/tracker-data-manager.c:4050 (gdb) disassemble /r 0x77b6dbee, 0x77b6dbee + 62 Dump of assembler code from 0x77b6dbee to 0x77b6dc2c: 0x77b6dbee : 18 64 48 2b sbb %ah,0x2b(%rax,%rcx,2) 0x77b6dbf2 : 04 25 add $0x25,%al 0x77b6dbf4 : 28 00 sub %al,(%rax) 0x77b6dbf6 : 00 00 add %al,(%rax) 0x77b6dbf8 : 75 35 jne 0x77b6dc2f 0x77b6dbfa : 48 83 c4 20 add $0x20,%rsp 0x77b6dbfe : 5b pop %rbx 0x77b6dbff : c3 ret 0x77b6dc00 : 48 8b 44 24 10 mov 0x10(%rsp),%rax 0x77b6dc05 : 48 8d 15 84 dd 04 00lea 0x4dd84(%rip),%rdx# 0x77bbb990 0x77b6dc0c : be 08 00 00 00 mov $0x8,%esi 0x77b6dc11 : 48 8d 3d fd 77 04 00lea 0x477fd(%rip),%rdi# 0x77bb5415 >>>0x77b6dc18 : 48 8b 48 08 mov >>>0x8(%rax),%rcx 0x77b6dc1c : 31 c0 xor %eax,%eax 0x77b6dc1e : e8 5d de fd ff call 0x77b4ba80 0x77b6dc23 : 48 8b 7c 24 10 mov 0x10(%rsp),%rdi 0x77b6dc28 : e8 03 da fd ff call 0x77b4b630 End of assembler dump. https://sources.debian.org/src/tracker/3.4.2-3/src/libtracker-sparql/core/tracker-data-manager.c/#L4050 g_critical ("Could not set up interface : %s", error->message);
Bug#1037481: Bug #1037481: outguess: Stack smashing detected and SIGABRT during finding of best embedding
Hello, just tried to get some more information where this stack smashing happens. The stack canary gets at least overwritten here: 165 memmove(detect + n + 1, detect + n, 166 (j - n) * sizeof(int)); The variable detect has a size of 12. The parameter to memove is the second element, therefore the size parameter to memove should be <= 8. But actually the size parameter to memove is 12, therefore memove writes beyond the variable detect. Attached file shows some debugging attempts. Kind regards, Bernhard # 2023-07-11 bookworm/stable amd64 qemu VM apt update apt dist-upgrade apt install systemd-coredump gdb rr valgrind outguess outguess-dbgsym apt build-dep outguess mkdir /home/benutzer/source/outguess/orig -p cd/home/benutzer/source/outguess/orig apt source outguess benutzer@debian:~$ wget -q https://upload.wikimedia.org/wikipedia/commons/3/3f/JPEG_example_flower.jpg benutzer@debian:~$ echo msg1 > msg1.txt benutzer@debian:~$ echo msg2 > msg2.txt benutzer@debian:~$ outguess -k "key1" -d msg1.txt -E -K "key2" -D msg2.txt -p 100 JPEG_example_flower.jpg JPEG_example_flower.steg.jpg Initialize encoding/decoding tables Reading JPEG_example_flower.jpg JPEG compression quality set to 100 Extracting usable bits: 70325 bits Correctable message size: 17434 bits, 24.79% Encoded 'msg1.txt': 40 bits, 5 bytes Finding best embedding... 0:33(45.8%)[82.5%], bias28(0.85), saved:-1, total: 0.05% 1:28(38.9%)[70.0%], bias25(0.89), saved:-1, total: 0.04% 6:30(42.3%)[75.0%], bias19(0.63), saved:-1, total: 0.04% 11:28(38.9%)[70.0%], bias13(0.46), saved:-1, total: 0.04% 11, 41: Embedding data: 40 in 70325 Bits embedded: 72, changed: 28(38.9%)[70.0%], bias: 13, tot: 68673, skip: 68601 Encoded 'msg2.txt' with ECC: 96 bits, 12 bytes Finding best embedding... *** stack smashing detected ***: terminated Abgebrochen (Speicherabzug geschrieben) cd /home/benutzer/source/outguess/orig/outguess-0.4 coredumpctl list TIME PID UID GID SIG COREFILE EXE SIZE Tue 2023-07-11 10:00:02 CEST 1136 1000 1000 SIGABRT present /usr/bin/outguess 412.4K coredumpctl gdb --debugger-argument=-q 1136 (gdb) bt #0 __pthread_kill_implementation (threadid=, signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44 #1 0x7f83ca05bd2f in __pthread_kill_internal (signo=6, threadid=) at ./nptl/pthread_kill.c:78 #2 0x7f83ca00cef2 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 #3 0x7f83c9ff7472 in __GI_abort () at ./stdlib/abort.c:79 #4 0x7f83ca0502d0 in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7f83ca16a210 "*** %s ***: terminated\n") at ../sysdeps/posix/libc_fatal.c:155 #5 0x7f83ca0e8e82 in __GI___fortify_fail (msg=msg@entry=0x7f83ca16a1f8 "stack smashing detected") at ./debug/fortify_fail.c:26 #6 0x7f83ca0e8e60 in __stack_chk_fail () at ./debug/stack_chk_fail.c:24 #7 0x5627c3781422 in steg_adjust_errors (bitmap=bitmap@entry=0x7ffda38f0c30, flags=flags@entry=8) at ./src/outguess.c:187 #8 0x5627c37814ba in steg_embedchunk (bitmap=bitmap@entry=0x7ffda38f0c30, iter=iter@entry=0x7ffda38f0670, data=0, bits=1, bits@entry=8, embed=embed@entry=8) at ./src/outguess.c:206 #9 0x5627c3781aa8 in steg_embed (bitmap=bitmap@entry=0x7ffda38f0c30, iter=iter@entry=0x7ffda38f0670, as=as@entry=0x7ffda38f0560, data=data@entry=0x5627c4d96b30 "BU\026\330E\315>ۆL\260\246\203\177", datalen=datalen@entry=12, seed=seed@entry=0, embed=8) at ./src/outguess.c:285 #10 0x5627c3781e44 in steg_find (bitmap=bitmap@entry=0x7ffda38f0c30, iter=iter@entry=0x7ffda38f0a30, as=as@entry=0x7ffda38f0810, siter=, siterstart=, data=data@entry=0x5627c4d96b30 "BU\026\330E\315>ۆL\260\246\203\177", datalen=12, flags=8) at ./src/outguess.c:444 #11 0x5627c3782a04 in do_embed (bitmap=bitmap@entry=0x7ffda38f0c30, filename=filename@entry=0x7ffda38f16ec "msg2.txt", key=key@entry=0x7ffda38f0fe0 "key2", klen=, cfg=cfg@entry=0x7ffda38f0c24, result=result@entry=0x7ffda38f0c08) at ./src/outguess.c:719 #12 0x5627c3780d12 in main (argc=, argv=0x7ffda38f1488) at ./src/outguess.c:1025 (gdb) up #7 0x5627c3781422 in steg_adjust_errors (bitmap=bitmap@entry=0x7ffda38f0c30, flags=flags@entry=8) at ./src/outguess.c:187 187 } (gdb) list 138, 188 138 void 139 steg_adjust_errors(bitmap *bitmap, int flags) 140 { 141 int i, j, n, many, flag; 142 int priority[ERRORBITS], detect[ERRORBITS]; 143 144 many = ERRORBITS - steg_errors; 145 for (j = 0; j < many && j < steg_err_cnt; j++) { 146 priority[j] = steg_err_buf[j]; 147 detect[j] = bitmap->detect[priority[j]]; 148 } 149 150 /* Very simple sort */ 151 do { 152 for (flag = 0, i = 0; i < j - 1; i++)
Bug#1036302: free(): double free detected in tcache 2 during history search
Hello, below is the top of a valgrind run with dbgsym package installed. Kind regards, Bernhard benutzer@debian:~$ valgrind bash ==1114== Memcheck, a memory error detector ==1114== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al. ==1114== Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info ==1114== Command: bash ==1114== benutzer@debian:~$ bind '"\C-p": history-search-backward' benutzer@debian:~$ bind '"\C-n": history-search-forward' benutzer@debian:~$ Control-P # history-search-backward Control-U # unix-line-discard Control-P # history-search-backward Control-U # unix-line-discard Control-N # history-search-forward Control-J # accept-line ==1114== Invalid read of size 4 ==1114==at 0x1E9D04: rl_do_undo (undo.c:186) ==1114==by 0x1EA0B4: rl_revert_line (undo.c:337) ==1114==by 0x1CD86C: readline_internal_teardown (readline.c:498) ==1114==by 0x1CEC7B: readline_internal (readline.c:734) ==1114==by 0x1CEC7B: readline (readline.c:387) ==1114==by 0x13AFE1: yy_readline_get (parse.y:1528) ==1114==by 0x13DAE0: yy_getc (parse.y:1462) ==1114==by 0x13DAE0: shell_getc (parse.y:2393) ==1114==by 0x13FF5A: read_token.constprop.0 (parse.y:3402) ==1114==by 0x1440BA: yylex (parse.y:2890) ==1114==by 0x1440BA: yyparse (y.tab.c:1854) ==1114==by 0x13A5B5: parse_command (eval.c:348) ==1114==by 0x13A743: read_command (eval.c:392) ==1114==by 0x13A8F5: reader_loop (eval.c:139) ==1114==by 0x1393D8: main (shell.c:833) ==1114== Address 0x53ba808 is 24 bytes inside a block of size 32 free'd ==1114==at 0x484317B: free (vg_replace_malloc.c:872) ==1114==by 0x1E9ABA: _rl_free_undo_list (undo.c:111) ==1114==by 0x1F03DF: _rl_free_saved_history_line (misc.c:396) ==1114==by 0x1D4286: rl_history_search_forward (search.c:647) ==1114==by 0x1CDD96: _rl_dispatch_subseq (readline.c:916) ==1114==by 0x1CE371: _rl_dispatch (readline.c:860) ==1114==by 0x1CE371: readline_internal_char (readline.c:675) ==1114==by 0x1CEC64: readline_internal_charloop (readline.c:721) ==1114==by 0x1CEC64: readline_internal (readline.c:733) ==1114==by 0x1CEC64: readline (readline.c:387) ==1114==by 0x13AFE1: yy_readline_get (parse.y:1528) ==1114==by 0x13DAE0: yy_getc (parse.y:1462) ==1114==by 0x13DAE0: shell_getc (parse.y:2393) ==1114==by 0x13FF5A: read_token.constprop.0 (parse.y:3402) ==1114==by 0x1440BA: yylex (parse.y:2890) ==1114==by 0x1440BA: yyparse (y.tab.c:1854) ==1114==by 0x13A5B5: parse_command (eval.c:348) ==1114== Block was alloc'd at ==1114==at 0x48407B4: malloc (vg_replace_malloc.c:381) ==1114==by 0x1A2C8D: xmalloc (xmalloc.c:114) ==1114==by 0x1E9A4E: alloc_undo_entry (undo.c:75) ==1114==by 0x1E9A4E: rl_add_undo (undo.c:92) ==1114==by 0x1EDB41: rl_delete_text (text.c:152) ==1114==by 0x1E8E4C: rl_kill_text (kill.c:177) ==1114==by 0x1E9466: rl_unix_line_discard (kill.c:412) ==1114==by 0x1CDD96: _rl_dispatch_subseq (readline.c:916) ==1114==by 0x1CE371: _rl_dispatch (readline.c:860) ==1114==by 0x1CE371: readline_internal_char (readline.c:675) ==1114==by 0x1CEC64: readline_internal_charloop (readline.c:721) ==1114==by 0x1CEC64: readline_internal (readline.c:733) ==1114==by 0x1CEC64: readline (readline.c:387) ==1114==by 0x13AFE1: yy_readline_get (parse.y:1528) ==1114==by 0x13DAE0: yy_getc (parse.y:1462) ==1114==by 0x13DAE0: shell_getc (parse.y:2393) ==1114==by 0x13FF5A: read_token.constprop.0 (parse.y:3402) ==1114== ==1114== Invalid read of size 4 ... ==1114== benutzer@debian:~$ exit ... ==1114== ERROR SUMMARY: 85 errors from 13 contexts (suppressed: 0 from 0) benutzer@debian:~$
Bug#973894: rr: Improve reproducibility
Hello, upstream uses now macro-prefix-map, therefore e.g. source files using __FILE__ should no longer contain absolute paths. So there are still the *.S files embedding their absolute paths. In the long run maybe dpkg-buildflags might help there [1], [2]. But there is also mentioned to "just" feed c-flags into asm-flags. (See patch below.) This produces from different build directories a deb file with the same md5sum. Kind regards, Bernhard [1] https://salsa.debian.org/debian/debhelper/-/merge_requests/50 [2] https://git.dpkg.org/cgit/dpkg/dpkg.git/commit/scripts/Dpkg/BuildFlags.pm?id=ce5af1eeb795c6fa8ce122b801930ccd7adc8516 --- rr-5.6.0.orig/CMakeLists.txt +++ rr-5.6.0/CMakeLists.txt @@ -50,6 +50,9 @@ configure_file( ${CMAKE_BINARY_DIR}/git_revision.h ) +# For reproducibility, e.g. -ffile-prefix-map +set(CMAKE_ASM_FLAGS "${CMAKE_ASM_FLAGS} ${CMAKE_C_FLAGS}") + set(FLAGS_COMMON "-D__USE_LARGEFILE64 -pthread") set(supports32bit true) set(x86ish false)
Bug#1032834: freecad: Segmentation fault while redoing
Why isn't there a symbol package, just for some ports? Hello Patrick, there are symbol packages for nearly all Debian packages nowadays. You can add the debug component [1] to be able to install the dbgsym packages, or if you like you can just use the DEBUGINFOD_URLS environment variable [2]. Kind regards, Bernhard [1] https://wiki.debian.org/HowToGetABacktrace#Installing_the_debugging_symbols [2] https://wiki.debian.org/HowToGetABacktrace#Automatically_loading_debugging_symbol_from_the_Internet
Bug#1032423: lldb-15: Bug "No module named lldb.embedded_interpreter" reappeared again in lldb-15
Dear Maintainer, it looks like the searched file ends up here in the current package: /usr/lib/llvm-15/lib/python3.11/dist-packages/lldb/embedded_interpreter.py But by inspecting the strace output it should probably be in this directory: /usr/lib/llvm-15/lib/python3/dist-packages/lldb For a test I moved the files that way manually, and it makes the error message go away. Kind regards, Bernhard newfstatat(AT_FDCWD, "/usr/lib/python3/dist-packages/lldb", {st_mode=S_IFDIR|0755, st_size=4096, ...}, 0) = 0 newfstatat(AT_FDCWD, "/usr/lib/python3/dist-packages/lldb", {st_mode=S_IFDIR|0755, st_size=4096, ...}, 0) = 0 newfstatat(AT_FDCWD, "/usr/lib/python3/dist-packages/lldb", {st_mode=S_IFDIR|0755, st_size=4096, ...}, 0) = 0 openat(AT_FDCWD, "/usr/lib/python3/dist-packages/lldb", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 3 newfstatat(3, "", {st_mode=S_IFDIR|0755, st_size=4096, ...}, AT_EMPTY_PATH) = 0 getdents64(3, 0x55ab0a60fdf0 /* 5 entries */, 32768) = 160 getdents64(3, 0x55ab0a60fdf0 /* 0 entries */, 32768) = 0 close(3)= 0 write(2, "Traceback (most recent call last"..., 35Traceback (most recent call last): ) = 35 write(2, " File \"\", line 1, in ", line 1, in ) = 39 write(2, "ModuleNotFoundError: No module n"..., 65ModuleNotFoundError: No module named 'lldb.embedded_interpreter' ) = 65 $ ls -lisah /usr/lib/python3/dist-packages/lldb 1045401 0 lrwxrwxrwx 1 root root 44 3. Jan 20:55 /usr/lib/python3/dist-packages/lldb -> ../../llvm-15/lib/python3/dist-packages/lldb $ ls -lisah /usr/lib/llvm-15/lib/python3/dist-packages/lldb insgesamt 8,0K 674672 4,0K drwxr-xr-x 2 root root 4,0K 25. Mär 11:02 . 674671 4,0K drwxr-xr-x 3 root root 4,0K 25. Mär 11:02 .. 6747020 lrwxrwxrwx 1 root root 51 3. Jan 20:55 libLLVM-15.0.6.so.1 -> ../../../../../x86_64-linux-gnu/libLLVM-15.0.6.so.1 6747030 lrwxrwxrwx 1 root root 51 3. Jan 20:55 libLLVM-15.so.1 -> ../../../../../x86_64-linux-gnu/libLLVM-15.0.6.so.1 6747010 lrwxrwxrwx 1 root root 47 3. Jan 20:55 _lldb.so -> ../../../../../x86_64-linux-gnu/liblldb-15.so.1 $ dpkg -S embedded python3-lldb-15: /usr/lib/llvm-15/lib/python3.11/dist-packages/lldb/embedded_interpreter.py
Bug#1032642: iproute2: ip tunnel change ip6gre to gre crashes with stack smash
Dear Maintainer, I tried to find out where exactly the stack smashing takes place. And found the ioctl SIOCCHGTUNNEL did write more than the 52 bytes allocated in variable old_p, by that overwriting the stack canary. Kind regards, Bernhard (gdb) 0x5557589f 62 { 1: x/i $pc => 0x5557589f : mov%fs:0x28,%rax (gdb) 0x555758a8 62 { 1: x/i $pc => 0x555758a8 : mov%rax,0x68(%rsp) (gdb) print/x $rax $1 = 0xbf9b77d893accd00 (gdb) print/x $rsp + 0x68 $2 = 0x7fffea28 (gdb) 0x77e575f5 120 in ../sysdeps/unix/syscall-template.S 1: x/i $pc => 0x77e575f5 :syscall 2: /x *(uint64_t*)0x7fffea28 = 0xbf9b77d893accd00 (gdb) bt #0 0x77e575f5 in ioctl () at ../sysdeps/unix/syscall-template.S:120 #1 0x55578230 in tnl_get_ioctl (basedev=0x7fffee8f "gre1", p=) at tunnel.c:77 #2 0x55576243 in parse_args (argc=9, argv=0x7fffec50, cmd=35315, p=0x7fffea70) at iptunnel.c:181 #3 0x555762fb in do_add (cmd=35315, argc=, argv=) at iptunnel.c:260 #4 0x5556258b in do_cmd (argv0=0x7fffee81 "tunnel", argc=11, argv=0x7fffec40) at ip.c:133 #5 0x55561fc2 in main (argc=12, argv=0x7fffec38) at ip.c:344 (gdb) stepi 0x77e575f7 120 in ../sysdeps/unix/syscall-template.S 1: x/i $pc => 0x77e575f7 :cmp$0xf001,%rax 2: /x *(uint64_t*)0x7fffea28 = 0x200 (gdb) print _p $7 = (struct ip_tunnel_parm *) 0x7fffe9f0 (gdb) print sizeof(old_p) $8 = 52 (gdb) print/x 0x7fffe9f0 + 52 $9 = 0x7fffea24 (gdb) list iptunnel.c:181 178 if (cmd == SIOCCHGTUNNEL && count == 0) { 179 struct ip_tunnel_parm old_p = {}; 180 181 if (tnl_get_ioctl(*argv, _p)) 182 return -1;
Bug#1018061: pads: segfault at 3a ip
Am 23.03.23 um 17:38 schrieb Tim McConnell: Bernhard, Just cause I said it was fixed this happens to show up in journalctl: systemd-coredump[3614]: Process 1704 (pads) of user 0 dumped core. Module libsystemd.so.0 from deb systemd-252.5-2.amd64 Stack trace of thread 1704: #0 0x5600f24f6954 print_arp_asset_screen (pads + 0x9954) #1 0x5600f24f66f0 print_arp_asset (pads + 0x96f0) #2 0x7fdc7fdb54f6 n/a (libpcap.so.0.8 + 0x84f6) #3 0x7fdc7fdb58ec n/a (libpcap.so.0.8 + 0x88ec) #4 0x7fdc7fdbcd1d pcap_loop (libpcap.so.0.8 + 0xfd1d) #5 0x5600f24efe5b main_pads (pads + 0x2e5b) #6 0x5600f24ef47b main (pads + 0x247b) #7 0x7fdc7fbec18a __libc_start_call_main (libc.so.6 + 0x2718a) #8 0x7fdc7fbec245 __libc_start_main_impl (libc.so.6 + 0x27245) #9 0x5600f24ef4b1 _start (pads + 0x24b1) ELF object binary architecture: AMD x86-64 Mar 04 14:31:02 DebianTim systemd[1]: systemd-coredump@0-3613-0.service: Deactivated successfully. Well I thought it was fixed :-( Hello Time, are you sure that your rebuilt package is still in place? The offsets in your new backtrace are exactly the same as in the email from 8 Feb 2023. We have not changed the version of the rebuilt package. Additionally built with "-b". Then with a "apt dist-upgrade" always the Debian version gets reinstalled. Sorry for not mentioning that extra care has to be taken to hold the rebuilt package version in place. Kind regards, Bernhard
Bug#1032426: xsane: Help>About XSane crashes without opening a window
On Mon, 06 Mar 2023 14:40:12 + Reuben Thomas wrote: If I select Help→About XSane, the application pauses for a couple of seconds then crashes. (The changes in Ubuntu’s version are just to depend on a different JPEG library, so I think it’s reasonable to file a bug here.) Dear Maintainer, I could reproduce it also with a current Bookworm/testing system. It looks like between 0.999-6 (buster/oldstable) and 0.999-12 (bullseye/stable) the file xsane-logo.xpm got moved from path /usr/share/sane/xsane to /usr/share/doc/xsane-common. Unfortunately the about dialog still constructs the old path, does not find there the pixmap and handles this case not carefully. A workaround is to create a symlink and the dialog shows up without crash. Kind regards, Bernhard Core was generated by `xsane'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x7fd785b1b665 in IA__gtk_image_set_from_pixmap (image=0x557b947ccdb0, pixmap=0x0, mask=0x557b9456e230) at ../../../../gtk/gtkimage.c:858 858 g_return_if_fail (mask == NULL || (gdb) bt #0 0x7fd785b1b665 in IA__gtk_image_set_from_pixmap (image=0x557b947ccdb0 [GtkImage], pixmap=0x0, mask=0x557b9456e230) at ../../../../gtk/gtkimage.c:858 #1 0x7fd785b1b83d in IA__gtk_image_new_from_pixmap (pixmap=pixmap@entry=0x0, mask=0x557b9456e230) at ../../../../gtk/gtkimage.c:606 #2 0x557b92ea2d1b in xsane_about_dialog (data=, widget=) at ./src/xsane.c:3523 #6 0x7fd785f31dbf in (instance=instance@entry=0x557b946d60d0, signal_id=, detail=detail@entry=0) at ../../../gobject/gsignal.c:3606 #3 0x7fd785f183b0 in g_closure_invoke (closure=0x557b946d88e0, return_value=return_value@entry=0x0, n_param_values=1, param_values=param_values@entry=0x7ffc72ce6750, invocation_hint=invocation_hint@entry=0x7ffc72ce66d0) at ../../../gobject/gclosure.c:832 #4 0x7fd785f2b076 in signal_emit_unlocked_R (node=node@entry=0x557b946c4540, detail=detail@entry=0, instance=instance@entry=0x557b946d60d0, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7ffc72ce6750) at ../../../gobject/gsignal.c:3796 #5 0x7fd785f31bf5 in g_signal_emit_valist (instance=, signal_id=, detail=, var_args=var_args@entry=0x7ffc72ce68d0) at ../../../gobject/gsignal.c:3549 #7 0x7fd785c57d94 in IA__gtk_widget_activate (widget=widget@entry=0x557b946d60d0 [GtkMenuItem]) at ../../../../gtk/gtkwidget.c:5041 #8 0x7fd785b4baf5 in IA__gtk_menu_shell_activate_item (menu_shell=0x557b94544d80 [GtkMenu], menu_item=0x557b946d60d0 [GtkMenuItem], force_deactivate=) at ../../../../gtk/gtkmenushell.c:1278 #9 0x7fd785b4be09 in gtk_menu_shell_button_release (widget=0x557b94544d80 [GtkMenu], event=0x557b9489ca70) at ../../../../gtk/gtkmenushell.c:703 #14 0x7fd785f31dbf in (instance=instance@entry=0x557b94544d80, signal_id=, detail=detail@entry=0) at ../../../gobject/gsignal.c:3606 #10 0x7fd785b391ab in _gtk_marshal_BOOLEAN__BOXED (closure=0x557b944dfd30, return_value=0x7ffc72ce6be0, n_param_values=, param_values=0x7ffc72ce6c40, invocation_hint=, marshal_data=) at ../../../../gtk/gtkmarshalers.c:84 #11 0x7fd785f183b0 in g_closure_invoke (closure=closure@entry=0x557b944dfd30, return_value=return_value@entry=0x7ffc72ce6be0, n_param_values=2, param_values=param_values@entry=0x7ffc72ce6c40, invocation_hint=invocation_hint@entry=0x7ffc72ce6bc0) at ../../../gobject/gclosure.c:832 #12 0x7fd785f2b1a5 in signal_emit_unlocked_R (node=, detail=detail@entry=0, instance=instance@entry=0x557b94544d80, emission_return=emission_return@entry=0x7ffc72ce6d30, instance_and_params=instance_and_params@entry=0x7ffc72ce6c40) at ../../../gobject/gsignal.c:3835 #13 0x7fd785f3142d in g_signal_emit_valist (instance=, signal_id=, detail=, var_args=var_args@entry=0x7ffc72ce6de0) at ../../../gobject/gsignal.c:3559 #15 0x7fd785c58fe4 in gtk_widget_event_internal (widget=widget@entry=0x557b94544d80 [GtkMenu], event=event@entry=0x557b9489ca70) at ../../../../gtk/gtkwidget.c:5010 #16 0x7fd785c592d5 in IA__gtk_widget_event (widget=widget@entry=0x557b94544d80 [GtkMenu], event=event@entry=0x557b9489ca70) at ../../../../gtk/gtkwidget.c:4807 #17 0x7fd785b377d4 in IA__gtk_propagate_event (widget=0x557b94544d80 [GtkMenu], event=0x557b9489ca70) at ../../../../gtk/gtkmain.c:2503 #18 0x7fd785b37c4b in IA__gtk_main_do_event (event=0x557b9489ca70) at ../../../../gtk/gtkmain.c:1698 #19 IA__gtk_main_do_event (event=) at ../../../../gtk/gtkmain.c:1503 #20 0x7fd785fc0afc in gdk_event_dispatch (source=, callback=, user_data=) at ../../../../../gdk/x11/gdkevents-x11.c:2425 #21 0x7fd7860f97a9 in g_main_dispatch (context=0x557b94477800) at ../../../glib/gmain.c:3454 #22 g_main_context_dispatch (context=context@entry=0x557b94477800) at ../../../glib/gmain.c:4172 #23 0x7fd7860f9a38 in g_main_context_iterate (context=0x557b94477800, block=block@entry=1,
Bug#1032510: packagekit: pkcon what-provides application/x-keepass2 makes PK crash
On Wed, 08 Mar 2023 10:47:25 +0100 Laurent Bigonville wrote: $ pkcon what-provides application/x-keepass2 Getting provides[=] Loading cache [=] Querying[=] e daemon crashed mid-transaction! Finished[ ] (0%) Stack trace of thread 10447: #0 0x7faf3ef75ccc __pthread_kill_implementation (libc.so.6 + 0x8accc) #1 0x7faf3ef26ef2 __GI_raise (libc.so.6 + 0x3bef2) #2 0x7faf3ef11472 __GI_abort (libc.so.6 + 0x26472) #3 0x7faf3c89d919 _ZN9__gnu_cxx27__verbose_terminate_handlerEv (libstdc++.so.6 + 0x9d919) #4 0x7faf3c8a8e1a _ZN10__cxxabiv111__terminateEPFvvE (libstdc++.so.6 + 0xa8e1a) #5 0x7faf3c8a8e85 _ZSt9terminatev (libstdc++.so.6 + 0xa8e85) #6 0x7faf3c8a90d8 __cxa_throw (libstdc++.so.6 + 0xa90d8) #7 0x7faf3c8a00e4 _ZSt19__throw_logic_errorPKc (libstdc++.so.6 + 0xa00e4) #8 0x7faf3e96cb3a _ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEC4IS3_EEPKcRKS3_ (libpk_backend_apt.so + 0x2cb3a) #9 0x7faf3e95d122 backend_what_provides_thread (libpk_backend_apt.so + 0x1d122) #10 0x5644cb0c7aca pk_backend_job_thread_setup (packagekitd + 0x23aca) #11 0x7faf3f5dbcfd g_thread_proxy (libglib-2.0.so.0 + 0x7ecfd) #12 0x7faf3ef73fd4 start_thread (libc.so.6 + 0x88fd4) #13 0x7faf3eff466c __clone3 (libc.so.6 + 0x10966c) Hello Laurent, I am just looking at some random crash reports. Unfortunately I cannot reproduce the crash in a current QEMU VM, neither minimal nor with a Gnome desktop. I cannot even convince the pkcon processes to load the library libpk_backend_apt.so. Can you still reproduce it. And do you probably have done some changes to the configuration? It looks like the system wide packagekitd is contacted, maybe that shows something in the journal. Kind regards, Bernhard
Bug#1018061: pads: segfault at 3a ip
control: tags -1 +patch Hello Tim, nice to hear it helps. Therefore adding the patch tag. Kind regards, Bernhard Am 21.03.23 um 17:53 schrieb Tim McConnell: Hi Bernhard, I believe the patch has fixed the issue. I haven't seen any messages about psad since installing the patch. Thanks so much for the fix & patience with me.
Bug#1031868: kde-cli-tools: kstart5 : does not return after launching command since upgrade to KDE Fralework 5.103
Dear Maintainer, I tried to reproduce this issue and found a difference between a minimal Bookworm VM with just running jwm window manager and my regular Plasma desktop. In the minimal VM a `kstart5 kcalc` returns immediately, while at my regular Plasma desktop it blocks until the started application is closed. I found in the non-blocking case `KStart::windowAdded` gets executed and therefore `QCoreApplication::exit` is called. This seems to be caused by having useRule to be true in the `KStart::KStart` constructor, and therefore the connect call is not reached. Kind regards, Bernhard (rr) bt #0 0x7ffb802b1860 in QCoreApplication::exit (returnCode=returnCode@entry=0) at kernel/qcoreapplication.cpp:1430 #1 0x55a5e93fd065 in KStart::windowAdded (this=0x7fff2864b760, w=6291470) at ./kstart/kstart.cpp:201 #2 0x7ffb802e8f4f in QtPrivate::QSlotObjectBase::call (a=0x7fff2864adc0, r=0x7fff2864b760, this=0x55a5e9b58230) at ../../include/QtCore/../../src/corelib/kernel/qobjectdefs_impl.h:398 #3 doActivate (sender=0x7ffb8174a440 <(anonymous namespace)::Q_QGS_g_kwmInstanceContainer::innerFunction()::holder>, signal_index=4, argv=0x7fff2864adc0) at kernel/qobject.cpp:3923 #4 0x7ffb802e21ef in QMetaObject::activate (sender=sender@entry=0x7ffb8174a440 <(anonymous namespace)::Q_QGS_g_kwmInstanceContainer::innerFunction()::holder>, m=m@entry=0x7ffb81748700 , local_signal_index=local_signal_index@entry=1, argv=argv@entry=0x7fff2864adc0) at kernel/qobject.cpp:3983 #5 0x7ffb8170e522 in KWindowSystem::windowAdded (this=this@entry=0x7ffb8174a440 <(anonymous namespace)::Q_QGS_g_kwmInstanceContainer::innerFunction()::holder>, _t1=, _t1@entry=6291470) at ./obj-x86_64-linux-gnu/src/KF5WindowSystem_autogen/EWIEGA46WW/moc_kwindowsystem.cpp:409 #6 0x7ffb7b07363d in NETEventFilter::addClient (this=0x55a5e9b6baf0, w=6291470) at ./src/platforms/xcb/kwindowsystem.cpp:412 #7 0x7ffb8172ea51 in NETRootInfo::update (this=0x55a5e9b6baf0, properties=..., properties2=...) at ./src/platforms/xcb/netwm.cpp:2033 #8 0x7ffb7b071af7 in NETEventFilter::activate (this=) at ./src/platforms/xcb/kwindowsystem.cpp:183 #9 KWindowSystemPrivateX11::init (this=this@entry=0x7ffb74006730, what=what@entry=KWindowSystemPrivateX11::INFO_BASIC) at ./src/platforms/xcb/kwindowsystem.cpp:575 #10 0x7ffb7b071d4c in KWindowSystemPrivateX11::connectNotify (this=0x7ffb74006730, signal=...) at ./src/platforms/xcb/kwindowsystem.cpp:536 #11 0x7ffb8171fc35 in KWindowSystem::connectNotify (this=0x7ffb8174a440 <(anonymous namespace)::Q_QGS_g_kwmInstanceContainer::innerFunction()::holder>, signal=...) at ./src/kwindowsystem.cpp:380 #12 0x7ffb802dea6a in QObjectPrivate::connectImpl (sender=sender@entry=0x7ffb8174a440 <(anonymous namespace)::Q_QGS_g_kwmInstanceContainer::innerFunction()::holder>, signal_index=4, receiver=receiver@entry=0x7fff2864b760, slot=slot@entry=0x7fff2864b670, slotObj=slotObj@entry=0x55a5e9b58230, type=, types=, senderMetaObject=) at kernel/qobject.cpp:5108 #13 0x7ffb802ded45 in QObject::connectImpl (sender=0x7ffb8174a440 <(anonymous namespace)::Q_QGS_g_kwmInstanceContainer::innerFunction()::holder>, signal=signal@entry=0x7fff2864b660, receiver=receiver@entry=0x7fff2864b760, slot=slot@entry=0x7fff2864b670, slotObj=0x55a5e9b58230, type=Qt::AutoConnection, types=0x0, senderMetaObject=) at kernel/qobject.cpp:5038 #14 0x55a5e93fc7bb in QObject::connect (type=Qt::AutoConnection, slot=(void (KStart::*)(KStart * const, unsigned long long)) 0x55a5e93fcfc0 , receiver=0x7fff2864b760, signal=(void (KWindowSystem::*)(KWindowSystem * const, unsigned long long)) 0x7ffb8170e4e0 , sender=) at /usr/include/x86_64-linux-gnu/qt5/QtCore/qobject.h:268 #15 KStart::KStart (this=0x7fff2864b760) at ./kstart/kstart.cpp:78 #16 0x55a5e93fac84 in main (argc=, argv=) at ./kstart/kstart.cpp:424 kde-cli-tools-5.27.2/kstart/kstart.cpp 62 KStart::KStart() 63 : QObject() 64 { 65 bool useRule = false; 66 67 #ifdef HAVE_X11 68 if (QX11Info::isPlatformX11()) { 69 NETRootInfo i(QX11Info::connection(), NET::Supported); 70 useRule = i.isSupported(NET::WM2KDETemporaryRules); 71 } 72 #endif 73 74 if (useRule) { 75 sendRule(); 76 } else { 77 // connect to window add to get the NEW windows 78 connect(KWindowSystem::self(), ::windowAdded, this, ::windowAdded); 79 }
Bug#1032039: xorg: xserver fails to recover session after locking (xfce4 / lightdm)
Dear Maintainer, I tried to add source line information to the Xorg backtrace: fdd in inl at /usr/include/x86_64-linux-gnu/sys/io.h:83 (pci_device_linux_sysfs_read32+93) f1a in x86emuOp_in_word_AX_DX at ../../../../../../hw/xfree86/int10/../x86emu/ops.c:10364 024 in X86EMU_exec at ../../../../../../hw/xfree86/int10/../x86emu/decode.c:135 995 in xf86ExecX86int10 at ../../../../../../hw/xfree86/int10/xf86x86emu.c:39 486 in VBESetVBEMode at ../../../../../../hw/xfree86/int10/vbe.c:473 200 in VESASetMode at ../../src/vesa.c:1247 405 in VESAEnterVT at ../../src/vesa.c:1166 127 in CMapEnterVT at ../../../../../../hw/xfree86/common/xf86cmap.c:475 e31 in xf86VTEnter at ../../../../../../hw/xfree86/common/xf86Events.c:456 243 in WakeupHandler at ../../../../dix/dixutils.c:427 6b8 in WaitForSomething at ../../../../os/WaitFor.c:210 473 in Dispatch at ../../../../dix/dispatch.c:492 6cc in dix_main at ../../../../dix/main.c:272 [ 6.584] Current Operating System: Linux keats 4.19.0-5-amd64 #1 SMP Debian 4.19.37-6 (2019-07-18) x86_64 The used kernel version is not from current testing. Could that be the reason why the vesa driver gets selected at all in the first place? Kind regards, Bernhard
Bug#1018061: pads: segfault at 3a ip
Am 26.02.23 um 16:47 schrieb Tim McConnell: Hi Bernhard, The delay is fine, I'm sure it takes a minute to figure it out ;-) and no I didn't have anything other than defaults for GDB set. I'm not a programmer so I don't know all the tricks to GDB or when is best to use them. With that said, how would I go about installing /testing the patch you provide? I'm happy to test it out for you, I just need the knowledge of how to. Thanks! Hello Tim, if you are fine with installing a bunch of build dependencies you could use following steps to rebuild the package with the patch. As root: # apt build-dep pads As user: $ mkdir -p source/pads Put attached patch to the new directory and continue as user: $ cd source/pads $ apt source pads $ cd pads-1.2/ $ patch -p1 < ../pads_print_arp_asset_initialize.patch $ dpkg-buildpackage -b As root (with the directory adjusted to your user): # dpkg -i /home/benutzer/source/pads/{pads_1.2-14_amd64.deb,pads-dbgsym_1.2-14_amd64.deb} And then see if it still works as expected and see if the crash happens again. Kind regards, Bernhard --- a/src/output/output.c2023-02-26 15:19:32.0 +0100 +++ b/src/output/output.c2023-02-26 15:54:54.007679051 +0100 @@ -182,7 +182,7 @@ int print_arp_asset (struct in_addr ip_a /* Find Asset */ ArpAsset *list; -ArpAsset *rec; +ArpAsset *rec = NULL; list = (ArpAsset *)get_arp_pointer(); while (list != NULL) {
Bug#1030842: fontforge: segfault during Open() of femkeklaver (inside pbuilder/lxc)
Dear Maintainer, with the help of the core saved in the artifacts I found that the crash happens when fontforge tries to print some logging. It just started to crash if I run the command with LANG=C. It seems to be caused by the call to function iconv returns with errno==EILSEQ (Illegal byte sequence). This could possibly be this "©" in the string to be processed. Kind regards, Bernhard $ LANG=C rr record fontforge -script /home/benutzer/source/fonts-femkeklaver/git/fonts-femkeklaver/debian/clear-fstype.pe /home/benutzer/source/fonts-femkeklaver/git/fonts-femkeklaver/femkeklaver.ttf $ rr replay -o-q ... Breakpoint 3, iconv (cd=cd@entry=0x55b4437f72d0, inbuf=inbuf@entry=0x7fff48abee88, inbytesleft=inbytesleft@entry=0x7fff48abee80, outbuf=outbuf@entry=0x7fff48abeea0, outbytesleft=outbytesleft@entry=0x7fff48abee98) at ./iconv/iconv.c:32 32 { (rr) finish Run till exit from #0 iconv (cd=cd@entry=0x55b4437f72d0, inbuf=inbuf@entry=0x7fff48abee88, inbytesleft=inbytesleft@entry=0x7fff48abee80, outbuf=outbuf@entry=0x7fff48abeea0, outbytesleft=outbytesleft@entry=0x7fff48abee98) at ./iconv/iconv.c:32 0x7fd0fc8a0b69 in do_iconv (cd=0x55b4437f72d0, inbuf=, inbuf@entry=0x7fff48abeef0, incount=, inunitsize=inunitsize@entry=1, outunitsize=outunitsize@entry=1) at ./Unicode/ucharmap.c:101 101 if (iconv(cd, (iconv_arg2_t), , , ) == (size_t)-1) { Value returned is $19 = 18446744073709551615 (rr) next 102 if (errno == E2BIG) { (rr) print errno $20 = 84 (rr) print inbuf $21 = (rr) up #1 0x7fd0fc8a0fd5 in utf82def_copy (ufrom=ufrom@entry=0x7fff48abeef0 "Warning: Mac and Windows entries in the 'name' table differ for the\n Copyright string in the language English (US)\n Mac String: Typeface © (your company). 2008. All Rights Reserved\nWindows String: Typeface © (femkeklaver.nl). 2008. All Rights Reserved\n") at ./Unicode/ucharmap.c:159 159 return do_iconv(from_utf8, ufrom, strlen(ufrom), sizeof(ufrom[0]), sizeof(char)); (rr) print ufrom $22 = 0x7fff48abeef0 "Warning: Mac and Windows entries in the 'name' table differ for the\n Copyright string in the language English (US)\n Mac String: Typeface © (your company). 2008. All Rights Reserved\nWindows String: Typeface © (femkeklaver.nl). 2008. All Rights Reserved\n" (rr) bt #0 do_iconv (cd=0x55b4437f72d0, inbuf=, inbuf@entry=0x7fff48abeef0, incount=, inunitsize=inunitsize@entry=1, outunitsize=outunitsize@entry=1) at ./Unicode/ucharmap.c:102 #1 0x7fd0fc8a0fd5 in utf82def_copy (ufrom=ufrom@entry=0x7fff48abeef0 "Warning: Mac and Windows entries in the 'name' table differ for the\n Copyright string in the language English (US)\n Mac String: Typeface © (your company). 2008. All Rights Reserved\nWindows String: Typeface © (femkeklaver.nl). 2008. All Rights Reserved\n") at ./Unicode/ucharmap.c:159 #2 0x7fd0fc958a84 in NOUI__LogError (format=, ap=ap@entry=0x7fff48abf0b0) at ./fontforge/nouiutil.c:55 #3 0x7fd0fc958c49 in NOUI_LogError (format=) at ./fontforge/nouiutil.c:66 #4 0x7fd0fc98555a in TTFAddLangStr (language=, spec=, plat=, stroff=, strlength=, id=0, info=0x7fff48abf220, ttf=0x55b4437ff990) at ./fontforge/parsettf.c:1609 #5 readttfcopyrights (info=0x7fff48abf220, ttf=0x55b4437ff990) at ./fontforge/parsettf.c:1748 #6 readttfpreglyph (info=0x7fff48abf220, ttf=0x55b4437ff990) at ./fontforge/parsettf.c:1814 #7 readttf (filename=0x55b4437ff930 "/home/benutzer/source/fonts-femkeklaver/git/fonts-femkeklaver/femkeklaver.ttf", info=0x7fff48abf220, ttf=0x55b4437ff990) at ./fontforge/parsettf.c:5554 #8 _SFReadTTF (ttf=ttf@entry=0x55b4437ff990, flags=flags@entry=0, openflags=openflags@entry=0, filename=filename@entry=0x55b4437ff930 "/home/benutzer/source/fonts-femkeklaver/git/fonts-femkeklaver/femkeklaver.ttf", chosenname=chosenname@entry=0x0, fd=fd@entry=0x0) at ./fontforge/parsettf.c:6342 #9 0x7fd0fca66a7a in _ReadSplineFont (file=, file@entry=0x0, filename=filename@entry=0x55b4437ff870 "/home/benutzer/source/fonts-femkeklaver/git/fonts-femkeklaver/femkeklaver.ttf", openflags=openflags@entry=0) at ./fontforge/splinefont.c:1130 #10 0x7fd0fca6794c in ReadSplineFont (filename=filename@entry=0x55b4437ff870 "/home/benutzer/source/fonts-femkeklaver/git/fonts-femkeklaver/femkeklaver.ttf", openflags=openflags@entry=0) at ./fontforge/splinefont.c:1310 #11 0x7fd0fca67a51 in LoadSplineFont (filename=filename@entry=0x55b4437ff810 "/home/benutzer/source/fonts-femkeklaver/git/fonts-femkeklaver/femkeklaver.ttf", openflags=openflags@entry=0) at ./fontforge/splinefont.c:1361 #12 0x7fd0fca0701e in bOpen (c=0x7fff48abfc10) at ./fontforge/scripting.c:1802 #13 0x7fd0fca0a273 in docall (c=c@entry=0x7fff48ac03e0, name=name@entry=0x7fff48abfe60 "Open", val=val@entry=0x7fff48ac0280) at ./fontforge/scripting.c:9241 #14 0x7fd0fca0a6ee in handlename (c=c@entry=0x7fff48ac03e0, val=val@entry=0x7fff48ac0280) at ./fontforge/scripting.c:9354 #15 0x7fd0fca0ba77 in term
Bug#1030854: kded5: It keeps on crashing everytime I boot into the system
Stack trace of thread 67345: #0 0x7f8daa6a9ccc n/a (libc.so.6 + 0x8accc) #1 0x7f8daa65aef2 raise (libc.so.6 + 0x3bef2) #2 0x7f8dabf4c83d _ZN6KCrash19defaultCrashHandlerEi (libKF5Crash.so.5 + 0x583d) #3 0x7f8daa65af90 n/a (libc.so.6 + 0x3bf90) #4 0x7f8d5553b740 _ZNK10PackageKit11Transaction3tidEv (libpackagekitqt5.so.1 + 0x1a740) #5 0x7f8d555f16f3 n/a (kded_apperd.so + 0xf6f3) #6 0x7f8d555f1df6 n/a (kded_apperd.so + 0xfdf6) #7 0x7f8daaae8f4f n/a (libQt5Core.so.5 + 0x2e8f4f) #8 0x7f8d5552f095 _ZN10PackageKit6Daemon22transactionListChangedERK11QStringList (libpackagekitqt5.so.1 + 0xe095) #9 0x7f8daaae8f7c n/a (libQt5Core.so.5 + 0x2e8f7c) #10 0x7f8d55547b38 n/a (libpackagekitqt5.so.1 + 0x26b38) #11 0x7f8d55548d73 n/a (libpackagekitqt5.so.1 + 0x27d73) #12 0x7f8dab6c861b n/a (libQt5DBus.so.5 + 0x2361b) #13 0x7f8daaadd6f0 _ZN7QObject5eventEP6QEvent (libQt5Core.so.5 + 0x2dd6f0) #14 0x7f8dab962fae _ZN19QApplicationPrivate13notify_helperEP7QObjectP6QEvent (libQt5Widgets.so.5 + 0x162fae) Hello, this seems similar to the backtrace in bug #1026062. Kind regards, Bernhard https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1026062
Bug#1031655: Lutris: "The wine build you have selected does not support Esync/Fsync"
On Sun, 19 Feb 2023 21:38:22 +0100 =?utf-8?q?Linus_L=C3=BCssing?= wrote: ... They sound like build options to me ... Hello Linus, I tried to have a look how Lutris detects fsync support. It looks like Lutris extracts the version from the path the wine executable was found. (see the is_version_fsync link below) Unfortunately there is not any version information from "/usr/bin/wine". Therefore this does not yet sound like an wine issue. Kind regards, Bernhard https://github.com/lutris/lutris/blob/v0.5.12/lutris/runners/wine.py#L310 https://github.com/lutris/lutris/blob/v0.5.12/lutris/runners/wine.py#L145 # fsync_support_callback https://github.com/lutris/lutris/blob/v0.5.12/lutris/util/wine/wine.py#L308 # is_version_fsync
Bug#1030919: xserver-xorg-video-intel: The server crashes when the mouse pointer hovers over a gtk button
Dear Maintainer, I tried to add line information using the dbgsym packages. That led me to libc trying to print the message "double free or corruption (out)". Kind regards, Bernhard https://sources.debian.org/src/glibc/2.36-8/malloc/malloc.c/ 4584malloc_printerr ("double free or corruption (out)"); 0: Xorg (OsLookupColor+0x139) [0x55e578a89cc9] in OsSigHandler at ../../../../os/osinit.c:138 1: libc.so.6(__sigaction+0x40) [0x7fee08244f90] 2: libc.so.6(pthread_key_delete+0x14c) [0x7fee08293ccc] in __pthread_kill_implementation at ./nptl/pthread_kill.c:43 3: libc.so.6(gsignal+0x12) [0x7fee08244ef2] in __GI_raise at ../sysdeps/posix/raise.c:26 4: libc.so.6(abort+0xd3) [0x7fee0822f472] in __GI_abort at ./stdlib/abort.c:79 5: libc.so.6(__fsetlocking+0x290) [0x7fee082882d0] in __libc_message at ../sysdeps/posix/libc_fatal.c:155 6: libc.so.6(timer_settime+0x37a) [0x7fee0829d64a] in malloc_printerr at ./malloc/malloc.c:5660 7: libc.so.6(__default_morecore+0x8a0) [0x7fee0829f6b0] in _int_free at ./malloc/malloc.c:4584 8: libc.so.6(__libc_free+0x6f) [0x7fee082a1d2f] in __GI___libc_free at ./malloc/malloc.c:3385 9: intel_drv.so (?+0x0)[0x7fee075d8a0f] in I810SetPortAttribute / RegionUninit at /usr/include/xorg/regionstr.h:166 10: Xorg (DamageDestroy+0x23e) [0x55e5789f627e] in damageDestroyPixmap at ../../../../../miext/damage/damage.c:1504 11: Xorg (ShmRegisterFbFuncs+0x80e) [0x55e5789b084e] in XvDestroyPixmap at ../../../../Xext/xvmain.c:369 12: Xorg (SyncVerifyFence+0x3354) [0x55e5789af214] in ShmDestroyPixmap at ../../../../Xext/shm.c:260 13: Xorg (RegisterExtensionNames+0x1dd) [0x55e57893d22d] in doFreeResource at ../../../../dix/resource.c:885 14: Xorg (FreeResource+0xe9)[0x55e57893de19] in FreeResource at ../../../../dix/resource.c:915 15: Xorg (dixDestroyPixmap+0x27e) [0x55e57891196e] in ProcFreePixmap at ../../../../dix/dispatch.c:1538 16: Xorg (SendErrorToClient+0x3d4) [0x55e578916734] in Dispatch at ../../../../dix/dispatch.c:550 17: Xorg (InitFonts+0x3bc) [0x55e57891a6cc] in dix_main at ../../../../dix/main.c:272
Bug#1018061: pads: segfault at 3a ip
Am 08.02.23 um 19:31 schrieb Tim McConnell: Opppss I thought I had, here it is. bt full Hello Tim, sorry for the delay. For some reason the debug information for libpcap.so.0.8 was missing in your backtrace (was the DEBUGINFOD_URLS variable set in that console?). But I guess I could fill in the gaps [2]. And I think in function print_arp_asset the variable rec might get used uninitialized. This is also warned about in the build log [3]. Therefore the crash could possibly avoided with the patch below [1]. Kind regards, Bernhard [1] --- src/output/output.c.orig2023-02-26 15:19:32.0 +0100 +++ src/output/output.c 2023-02-26 15:54:54.007679051 +0100 @@ -182,7 +182,7 @@ int print_arp_asset (struct in_addr ip_a /* Find Asset */ ArpAsset *list; -ArpAsset *rec; +ArpAsset *rec = NULL; list = (ArpAsset *)get_arp_pointer(); while (list != NULL) { [2] (gdb) #0 0x5641638af954 in print_arp_asset_screen (rec=0x2a) at ./src/output/output-screen.c:115 #1 0x5641638af6f0 in print_arp_asset (ip_addr=..., mac_addr=0x7fa6db692384 "") at ./src/output/output.c:210 head = 0x5641654a33f0 list = rec = 0x2a #2 0x7fa6dbe004f6 in pcap_handle_packet_mmap () at ./pcap-linux.c:4072 from /lib/x86_64-linux-gnu/libpcap.so.0.8 #3 0x7fa6dbe008ec in pcap_read_linux_mmap_v3 () at ./pcap-linux.c:4248 from /lib/x86_64-linux-gnu/libpcap.so.0.8 #4 0x7fa6dbe07d1d in pcap_loop () at ./pcap.c:2923 from /lib/x86_64-linux-gnu/libpcap.so.0.8 #5 0x5641638a8e5b in main_pads () at ./src/pads.c:278 #6 0x5641638a847b in main (argc=, argv=) at ./src/pads.c:491 (gdb) list output.c:210 179 int print_arp_asset (struct in_addr ip_addr, char mac_addr[MAC_LEN]) 180 { 181 OutputPluginList *head; 182 183 /* Find Asset */ 184 ArpAsset *list; 185 ArpAsset *rec; 186 187 list = (ArpAsset *)get_arp_pointer(); 188 while (list != NULL) { 189 if (ip_addr.s_addr == list->ip_addr.s_addr 190 && (strcmp(mac_addr, list->mac_addr) == 0)) { 191 192 /* Found! */ 193 rec = list; 194 break; 195 } else { 196 list = list->next; 197 } 198 } 199 200 /* Make sure that a record was found. */ 201 if (rec == NULL) 202 return 1; 203 204 /* Cycle through output plugins and print to those that are active. */ 205 head = output_plugin_list; 206 while (head != NULL) { 207 /* Only print to active plugins. */ 208 if (head->active == 1) { 209 if (head->plugin->print_arp) 210 (*head->plugin->print_arp)(rec); 211 } 212 213 head = head->next; 214 } [3] https://buildd.debian.org/status/fetch.php?pkg=pads=amd64=1.2-14=1665671920=0 output.c: In function ‘print_arp_asset’: output.c:210:18: warning: ‘rec’ may be used uninitialized [-Wmaybe-uninitialized] 210 | (*head->plugin->print_arp)(rec); | ~^~ output.c:185:15: note: ‘rec’ was declared here 185 | ArpAsset *rec; | ^~~
Bug#1029536: wine64-stable ENOENT
On Sun, 12 Feb 2023 18:53:01 +0900 Junichi Uekawa wrote: /usr/bin/wine64-stable fails because of missing files. Should /usr/bin/wine64-stable be there at all? I guess having just package wine64 without package wine installed should also work? Then /usr/bin/wine64-stable would be needed. Otherwise the user might really be expected to start it via "/usr/lib/wine/wine64 wineboot", like proposed before. At least the wrapper /usr/bin/wine from package wine looks like it would not need "/usr/bin/wine64-stable". Am 13.02.23 um 21:52 schrieb Jens Reyer: On 12.02.23 10:53, Junichi Uekawa wrote: /usr/bin/wine64-stable fails because of missing files. Should /usr/bin/wine64-stable be there at all? I don't know if we really need /usr/bin/wine64, or could just go with /usr/bin/wine and the rest in /usr/lib/wine. But if we want /usr/bin/wine64 then we also need /usr/bin/wine64-stable (for the alternatives system). Currently this is a link to /usr/lib/wine/wine64. Current maintainers may replace it with a wrapper script or provide the link suggested previously. (Or figure out why the -stable suffix in the link is now expected by the binary, while it wasn't in the past.) Before following commit [1] wine iterated through PATH environment to find finally /usr/bin/wine64-stable, which is a link to ../lib/wine/wine64. Afterwards it looks like it is "just" searching for /usr/lib/wine/wine64-stable. Kind regards, Bernhard [1] https://gitlab.winehq.org/wine/wine/-/commit/ae8562ed2277a5c051e131dc317e94aa3d5413c8 ntdll: Always use the name of the current loader to exec a new process. [7.21] https://gitlab.winehq.org/wine/wine/-/blob/053ee2d23d825f800baa16e455a218834aa2dec0/dlls/ntdll/unix/loader.c#L685 [7.22] https://gitlab.winehq.org/wine/wine/-/blob/20d86f34a066657048610803e7143232efa6c0d3/dlls/ntdll/unix/loader.c#L695
Bug#1031411: approx: starts to dislike spaces-only lines in configuration
Package: approx Version: 5.11-1 Severity: normal X-Debbugs-Cc: bernha...@mailbox.org Dear Maintainer, approx got sensitive to lines in /etc/approx/approx.conf which are empty except of spaces. This did not harm previous approx versions. Unfortunately there is no error message in journal: Started app...@347-xxx.xxx.xxx.xxx:-xxx.xxx.xxx.xxx:47158.service - caching proxy server for Debian archive files (xxx.xxx.xxx.xxx:47158). app...@347-xxx.xxx.xxx.xxx:-xxx.xxx.xxx.xxx:47158.service: Deactivated successfully. The error message seems just to get delivered to the requester: $ wget --quiet --tries=1 -O- http://xxx.xxx.xxx.xxx:/debian-12-bookworm-deb.debian.org Fatal error: exception Failure("malformed line in /etc/approx/approx.conf: ") Version 5.12-1 seems also affected. Removing my spaces-only lines made approx 5.12-1 work again. Kind regards, Bernhard -- System Information: Debian Release: bookworm/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-3-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE 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 approx depends on: ii adduser 3.131 ii bzip21.0.8-5+b1 ii curl 7.87.0-2 ii libc62.36-8 ii rsyslog [system-log-daemon] 8.2212.0-1 ii xz-utils 5.4.1-0.1 approx recommends no packages. Versions of packages approx suggests: pn libconfig-model-approx-perl -- debconf information: approx/port: Thank you for using reportbug
Bug#1018061: pads: segfault at 3a ip
Am 08.02.23 um 18:42 schrieb Tim McConnell: Hi Bernhard, Okay I did that. Let me know if that was of any use. Hello Tim, could you send the actual output below the `bt full`? Kind regards, Bernhard
Bug#1018061: pads: segfault at 3a ip
Hello Tim, thanks, that is good helpful information, but as long the core file might be in the system, could you execute following commands: export DEBUGINFOD_URLS="https://debuginfod.debian.net; coredumpctl gdb 1546 (gdb) bt full This will enable gdb to download needed debug symbol files, and the `bt` command to gdb can then show a backtrace with source line information (hopefully). The debug symbols get downloaded to "/root/.cache/debuginfod_client". Kind regards, Bernhard Am 07.02.23 um 20:25 schrieb Tim McConnell: New Backtrace: Stack trace of thread 1546: #0 0x5641638af954 print_arp_asset_screen (pads + 0x9954) #1 0x5641638af6f0 print_arp_asset (pads + 0x96f0) #2 0x7fa6dbe004f6 n/a (libpcap.so.0.8 + 0x84f6) #3 0x7fa6dbe008ec n/a (libpcap.so.0.8 + 0x88ec) #4 0x7fa6dbe07d1d pcap_loop (libpcap.so.0.8 + 0xfd1d) #5 0x5641638a8e5b main_pads (pads + 0x2e5b) #6 0x5641638a847b main (pads + 0x247b)
Bug#1029499: php-guzzlehttp-psr7: Build killed with signal TERM after 150 minutes of inactivity
Out of curiosity I investigated a little more. With the below steps I could reproduce it in a minimal Bookworm/testing amd64 qemu VM. There the build stopped at this line: dpkg-buildpackage: info: binary-only upload ... And killing from outside this php process made the build continue/finish. Previously I copied an sbuild example using unshare instead of schroot, but there the hang was not observable. Kind regards, Bernhard # as root: apt install mc rr gdb htop sbuild sbuild-debian-developer-setup mmdebstrap apt build-dep php-guzzlehttp-psr7 sbuild-adduser benutzer cat << "EOF" > /etc/schroot/chroot.d/unstable-amd64-sbuild [unstable-amd64-sbuild] description=Debian unstable/amd64 autobuilder groups=root,sbuild root-groups=root,sbuild profile=sbuild type=directory directory=/srv/chroot/sbuild-createchroot union-type=overlay EOF mkdir /srv/chroot mmdebstrap --variant=buildd unstable /srv/chroot/sbuild-createchroot # as user: cat << "EOF" > ~/.sbuildrc $chroot_mode = 'schroot'; $distribution = 'unstable'; #$run_autopkgtest = 1; $autopkgtest_root_args = ''; $autopkgtest_opts = [ '--apt-upgrade', '--', 'schroot', '--release', '%r', '--arch', '%a' ]; EOF mkdir /home/benutzer/source/php-guzzlehttp-psr7/orig cd/home/benutzer/source/php-guzzlehttp-psr7/orig apt source php-guzzlehttp-psr7 cd /home/benutzer/source/php-guzzlehttp-psr7 cp orig try1 -a cd try1/php-guzzlehttp-psr7-2.4.3 sbuild --no-run-lintian
Bug#1029499: php-guzzlehttp-psr7: Build killed with signal TERM after 150 minutes of inactivity
Dear Maintainer, might this be caused by a process left running? USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND benutzer 743 0.0 0.4 217032 30284 pts/0S14:55 0:00 php -S 127.0.0.1:10002 tests/Integration/server.php If that is really the case, would it be possible to print all the processes this build currently runs before the message "Build killed with signal TERM..."? Kind regards, Bernhard
Bug#1029536: wine64-stable ENOENT
Dear Maintainer, if one creates this wine64-stable just as a link to wine64, then `wine64-stable wineboot` would start to work. # ln -s wine64 /usr/lib/wine/wine64-stable Kind regards, Bernhard (rr) 692 execv( argv[1], argv + 1 ); (rr) print argv[1] $2 = 0x7e848400 "/usr/lib/wine/wine64-stable" (rr) shell ls -lisah /usr/lib/wine/wine64-stable ls: cannot access '/usr/lib/wine/wine64-stable': No such file or directory (rr) bt #0 preloader_exec (argv=argv@entry=0x7e8483d0) at dlls/ntdll/unix/loader.c:692 #1 0x7f5e1d159a6b in loader_exec (machine=34404, argv=0x7e8483d0) at dlls/ntdll/unix/loader.c:716 #2 __wine_main (argc=, argv=0x7ffd65438648, envp=0x7ffd65438660) at dlls/ntdll/unix/loader.c:2416 #3 0x7d001254 in main () (rr) $ ls -lisah /usr/bin/wine64-stable /usr/bin/wine64 /usr/lib/wine/wine64-stable /usr/lib/wine/wine64 ls: cannot access '/usr/lib/wine/wine64-stable': No such file or directory 674145 0 lrwxrwxrwx 1 root root 24 Jan 27 02:36 /usr/bin/wine64 -> /etc/alternatives/wine64 673301 0 lrwxrwxrwx 1 root root 18 Jan 27 02:36 /usr/bin/wine64-stable -> ../lib/wine/wine64 673289 16K -rwxr-xr-x 1 root root 15K Jan 27 02:36 /usr/lib/wine/wine64
Bug#1028493: geeqie: Does not print
Am 04.02.23 um 16:26 schrieb Andreas Rönnquist: Thanks - it does indeed sound reasonable to recommend on evince - If you have evince installed, does printing work as you expect it then? -- Andreas Rönnquist gus...@debian.org Sorry, I am not using geeqie regularly, I was just looking through some reports and tested inside a non-persistent VM, and I did not test if a print to the cups-pdf printer would have really worked. Just have forwarded my findings.
Bug#1028311: vflbanner: free(): invalid pointer
$ vflbanner -f /usr/share/fonts/truetype/liberation/LiberationSans-Regular.ttf free(): invalid pointer Aborted Hello, this seems to be call to hbf_release done twice [1]. If I see it right, if hbf_load_hbf_file is left via the "Unexpected_Error" label, the hbf_release is still called in function HBF_Open in the "Error" label. So I tried to remove that hbf_release in hbf_load_hbf_file, and the process can finish without crash [2]. In [3] there is another uninitialized access to variable "uncomp_prog" pointed out by valgrind. Kind regards, Bernhard [1] ==24083== Invalid free() / delete / delete[] / realloc() ==24083==at 0x484317B: free (vg_replace_malloc.c:872) ==24083==by 0x48767B3: hbf_release.part.0 (hbf.c:481) ==24083==by 0x4878236: hbf_release (hbf.c:480) ==24083==by 0x4878236: HBF_Open (hbf.c:119) ==24083==by 0x4878691: hbf_create (drv_hbf.c:295) ==24083==by 0x485DFFF: do_open_font.constprop.0 (VFlib.c:659) ==24083==by 0x485E818: open_font (VFlib.c:559) ==24083==by 0x485EF91: vf_openfont1 (VFlib.c:348) ==24083==by 0x10941C: vflbanner (vflbanner.c:109) ==24083==by 0x1091F9: main (vflbanner.c:70) ==24083== Address 0x50141c0 is 0 bytes inside a block of size 64 free'd ==24083==at 0x484317B: free (vg_replace_malloc.c:872) ==24083==by 0x48767B3: hbf_release.part.0 (hbf.c:481) ==24083==by 0x48776A9: hbf_release (hbf.c:480) ==24083==by 0x48776A9: hbf_load_hbf_file (hbf.c:470) ==24083==by 0x48781E0: HBF_Open (hbf.c:100) ==24083==by 0x4878691: hbf_create (drv_hbf.c:295) ==24083==by 0x485DFFF: do_open_font.constprop.0 (VFlib.c:659) ==24083==by 0x485E818: open_font (VFlib.c:559) ==24083==by 0x485EF91: vf_openfont1 (VFlib.c:348) ==24083==by 0x10941C: vflbanner (vflbanner.c:109) ==24083==by 0x1091F9: main (vflbanner.c:70) ==24083== Block was alloc'd at ==24083==at 0x48407B4: malloc (vg_replace_malloc.c:381) ==24083==by 0x486EB3E: vf_strdup (str.c:45) ==24083==by 0x48781A0: HBF_Open (hbf.c:86) ==24083==by 0x4878691: hbf_create (drv_hbf.c:295) ==24083==by 0x485DFFF: do_open_font.constprop.0 (VFlib.c:659) ==24083==by 0x485E818: open_font (VFlib.c:559) ==24083==by 0x485EF91: vf_openfont1 (VFlib.c:348) ==24083==by 0x10941C: vflbanner (vflbanner.c:109) ==24083==by 0x1091F9: main (vflbanner.c:70) [2] --- vflib3-3.7.2+dfsg.orig/src/hbf.c +++ vflib3-3.7.2+dfsg/src/hbf.c @@ -467,7 +467,6 @@ hbf_load_hbf_file(HBF hbf, SEXP fontdirs Unexpected_Error: if (uncomp_prog != NULL) vf_close_uncompress_stream(fp); - hbf_release(hbf); return -1; } [3] ==31327== Conditional jump or move depends on uninitialised value(s) ==31327==at 0x4877698: hbf_load_hbf_file (hbf.c:468) ==31327==by 0x48781B0: HBF_Open (hbf.c:100) ==31327==by 0x4878661: hbf_create (drv_hbf.c:295) ==31327==by 0x485DFFF: do_open_font.constprop.0 (VFlib.c:659) ==31327==by 0x485E818: open_font (VFlib.c:559) ==31327==by 0x485EF91: vf_openfont1 (VFlib.c:348) ==31327==by 0x10941C: vflbanner (vflbanner.c:109) ==31327==by 0x1091F9: main (vflbanner.c:70) --- vflib3-3.7.2+dfsg.orig/src/hbf.c +++ vflib3-3.7.2+dfsg/src/hbf.c @@ -126,7 +126,7 @@ hbf_load_hbf_file(HBF hbf, SEXP fontdirs FILE *fp; char linebuf[160], prop_string[160], *name, *file_path, *p; char charset_name[80], charset_name2[80], charset_enc2[5], charset[90]; - char *uncomp_prog; + char *uncomp_prog = NULL; intindex, r, i, n; hbf->byte2_range_start = NULL;
Bug#1030513: vflib3: dpkg-sym packages contain no useful information
Source: vflib3 Version: 3.7.2+dfsg-0.1 Severity: wishlist X-Debbugs-Cc: t...@test.de Dear Maintainer, I was looking at the crash in #1028311 when I found the dbgsym packages did just help to get function names. But getting also source line numbers would be desirable. As far as I see these are missing because the CFLAGS given to configure in debian/rules are lost. Following change would conserve them in make-sub and therefore gcc would be called with the -g flag in the build. Kind regards, Bernhard --- vflib3-3.7.2+dfsg.orig/make-sub.in +++ vflib3-3.7.2+dfsg/make-sub.in @@ -1,6 +1,7 @@ # Common definitions CC=@CC@ +CFLAGS=@CFLAGS@ VFCFLAGS=${CFLAGS} @XX_CFLAGS@ -DVFLIB_VERSION=\"@vflib_version@\" LDFLAGS=@LDFLAGS@ EXT_LIBRARY= @freetype_libdir@ @freetype_lib@ \ -- System Information: Debian Release: bookworm/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-2-amd64 (SMP w/16 CPU threads; PREEMPT) 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 Thank you for using reportbug
Bug#1028493: geeqie: Does not print
On Wed, 11 Jan 2023 22:48:42 +0100 waxhead wrote: Tried to print a jpg picture Restarted the machine, restarted printer, tried updating, looked at print queue (nothing), tried preview print (nothing) Tried to print from GIMP (success) Hello, I tried to reach the print preview window and it looks like geeqie does not print by itself, instead it seems to start evince: /usr/lib/x86_64-linux-gnu/glib-2.0/gio-launch-desktop evince --unlink-tempfile --preview --print-settings /tmp/settingsDVNAZ1.ini /tmp/previewXTSFZ1.pdf /usr/lib/x86_64-linux-gnu/glib-2.0/gio-launch-desktop evince-previewer --print-settings /tmp/settingsDVNAZ1.ini --unlink-tempfile /tmp/previewXTSFZ1.pdf Therefore does installing the package evince get you to the print preview? So either geeqie should report a missing evince, or maybe adding a recommends would be desirable? Kind regards, Bernhard
Bug#1029129: gnome-control-center: gnome control center segfault on boot (dmesg)
On Wed, 18 Jan 2023 11:26:42 +0100 xevilstar wrote: I am getting the following message in dmesg at boot [Wed Jan 18 07:40:37 2023] gnome-control-c[14186]: segfault at 55a65c093a45 ip 7f206782b8f3 sp 7ffe36eef7d0 error 4 in libgobject-2.0.so.0.7500.0[7f2067801000+32000] likely on CPU 9 (core 4, socket 0) [Wed Jan 18 07:40:37 2023] Code: 1f 84 00 00 00 00 00 41 56 41 55 41 54 55 48 89 fd 53 48 85 ff 0f 84 cf 00 00 00 48 8b 07 48 89 f3 48 85 c0 0f 84 cd 00 00 00 <4c> 8b 20 49 81 fc fc 03 00 00 0f 86 0d 01 00 00 4c 89 e7 48 83 e7 I'd love for it to disappear and I'd like the problem to be solved even tho the control center seems to work afterwards Hello, if you still experience this issue, would it be possible to install the package systemd-coredump? Then a automatic backtrace would be written to the journal, or be retrieved by coredumpctl. That could give the maintainer a better starting point. Kind regards, Bernhard coredumpctl list coredumpctl gdb
Bug#1028363: usbguard-notifier: crashes with "terminate called after throwing an instance of 'std::runtime_error'
On Tue, 31 Jan 2023 12:17:14 -0500 =?UTF-8?Q?Louis-Philippe_V=c3=a9ronneau?= wrote: On 2023-01-31 05 h 02, Bernhard Übelacker wrote: > could that be a dependency to "notification-daemon"? No, this package is also installed on my system: So I assume this daemon is not running in your environment? Having a recommends to it might not harm, but would not start it in your environment? Maybe the 'std::runtime_error' is too aggressive, and the message could be improved. Kind regards, Bernhard
Bug#1029150: toilet -E troff: Segmentation fault
#5 export_troff (bytes=0xd438, cv=0x56564ae0) at codec/export.c:1056 Dear Maintainer, this crash happens because the array ansi2troff has just 16 values, but gets accessed at value 32. This value 32 originates from the constant CACA_TRANSPARENT. With the below patch the crash could be avoided. Kind regards, Bernhard https://sources.debian.org/src/libcaca/0.99.beta20-3/caca/codec/export.c/#L1056 1056 cur += sprintf(cur, "\\M[%s]", ansi2troff[bg]); --- libcaca-0.99.beta20.orig/caca/codec/export.c +++ libcaca-0.99.beta20/caca/codec/export.c @@ -1052,7 +1052,7 @@ static void *export_troff(caca_canvas_t if(fg != prevfg || !started) cur += sprintf(cur, "\\m[%s]", ansi2troff[fg]); -if(bg != prevbg || !started) +if((bg != prevbg || !started) && bg != CACA_TRANSPARENT) cur += sprintf(cur, "\\M[%s]", ansi2troff[bg]); if(lineattr[x] & CACA_BOLD) cur += sprintf(cur, "\\fB"); benutzer@debian:~$ toilet -E troff foo .nf \m[black] m"" mm#mm mmmmmm ##" "# #" "# ## # # # #"#m#" "#m#" benutzer@debian:~$
Bug#1028363: usbguard-notifier: crashes with "terminate called after throwing an instance of 'std::runtime_error'
On Wed, 11 Jan 2023 15:20:22 -0500 =?UTF-8?Q?Louis-Philippe_V=c3=a9ronneau?= wrote: On 2023-01-11 01 h 26, Birger Schacht wrote: > The crash message ("Failed to show notification") sounds to me as if > there is maybe no notification daemon running? Here are the packages reportbug lists. I don't run GNOME or KDE, but a custom openbox DE, so maybe something is indeed missing and should be added in the packages' dependencies? Hello, could that be a dependency to "notification-daemon"? Following link shows a list of other packages that are providing "notification-daemon" too. https://packages.debian.org/sid/notification-daemon Kind regards, Bernhard
Bug#1028649: Segmentation fault invoking bus.get_unique_name()
Dear Maintainer, this can be reproduced in current Bookworm/testing too. The backtrace below shows PyBytes_FromString received for parameter str a NULL, which documentation states must not be NULL [1]. Unfortunately could not find an issue or update in upstream page [2]. Kind regards, Bernhard [1] https://docs.python.org/3/c-api/bytes.html [2] https://github.com/facebookincubator/pystemd $ cat test.py from pystemd.dbuslib import DBus bus=DBus(user_mode=True) bus.get_unique_name() $ $ python3 test.py pystemd.dbusexc.DBusBaseError: [err -22]: Failed to get unique name This is DBusBaseError, a base error for DBus (i bet you did not see that coming) if you need a special error, enhance pystemd.sysdexc module!. Exception ignored in: 'pystemd.dbuslib.DBus.get_unique_name' Traceback (most recent call last): File "/home/benutzer/test.py", line 3, in bus.get_unique_name() pystemd.dbusexc.DBusBaseError: [err -22]: Failed to get unique name This is DBusBaseError, a base error for DBus (i bet you did not see that coming) if you need a special error, enhance pystemd.sysdexc module!. Speicherzugriffsfehler (Speicherabzug geschrieben) $ # coredumpctl gdb 1246 (gdb) bt #0 __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:76 #1 0x0059f40c in PyBytes_FromString (str=0x0) at ../Objects/bytesobject.c:153 #2 0x7f360fb7b6a6 in __pyx_pf_7pystemd_7dbuslib_4DBus_20get_unique_name (__pyx_v_self=) at pystemd/dbuslib.c:10541 #3 __pyx_pw_7pystemd_7dbuslib_4DBus_21get_unique_name (__pyx_v_self=, unused=) at pystemd/dbuslib.c:10525 #4 0x0055a850 in method_vectorcall_NOARGS (func=, args=0x7f3610512070, nargsf=, kwnames=0x0) at ../Objects/descrobject.c:453 #5 0x0053983c in _PyObject_VectorcallTstate (kwnames=, nargsf=, args=, callable=, tstate=0xa85258 <_PyRuntime+166328>) at ../Include/internal/pycore_call.h:92 #6 PyObject_Vectorcall (callable=, args=, nargsf=, kwnames=) at ../Objects/call.c:299 ... (gdb) py-bt Traceback (most recent call first): File "/home/benutzer/test.py", line 3, in bus.get_unique_name() (gdb) $ cat -n pystemd/dbuslib.c | grep 10541 -C10 10531 10532 static PyObject *__pyx_pf_7pystemd_7dbuslib_4DBus_20get_unique_name(struct __pyx_obj_7pystemd_7dbuslib_DBus *__pyx_v_self) { 10533PyObject *__pyx_r = NULL; 10534__Pyx_RefNannyDeclarations 10535PyObject *__pyx_t_1 = NULL; 10536int __pyx_lineno = 0; 10537const char *__pyx_filename = NULL; 10538int __pyx_clineno = 0; 10539__Pyx_RefNannySetupContext("get_unique_name", 0); 10540__Pyx_XDECREF(__pyx_r); 10541__pyx_t_1 = __Pyx_PyBytes_FromString(__pyx_f_7pystemd_7dbuslib_4DBus_get_unique_name(__pyx_v_self, 1)); if (unlikely(!__pyx_t_1)) __PYX_ERR(0, 526, __pyx_L1_error) 10542__Pyx_GOTREF(__pyx_t_1); 10543__pyx_r = __pyx_t_1; 10544__pyx_t_1 = 0; 10545goto __pyx_L0; 10546 10547/* function exit code */ ... $ $ cat -n pystemd/dbuslib.pyx | grep 536 -C10 526 cpdef const char* get_unique_name(self): 527 cdef: 528 int r 529 const char *unique_name 530 531 r = dbusc.sd_bus_get_unique_name(self.bus, _name) 532 533 if r < 0: 534 raise DBusError(r, None, "Failed to get unique name") 535 536 return unique_name 537 538 cpdef int get_fd(self): ... $
Bug#877106: pinta: Pinta 1.6-2 crashes on image scaling and other image manipulation.
at <0x> at (wrapper managed-to-native) GLib.SList.g_free (intptr) <0x0005f> at GLib.ListBase.Empty () <0x0013c> at GLib.ListBase.Dispose (bool) <0xf> at GLib.ListBase.Finalize () <0x0001d> at (wrapper runtime-invoke) object.runtime_invoke_virtual_void__this__(object,intptr,intptr,intptr) <0x00068> Dear Maintainer, I took a look at the bug report [1] and guess this crash in Pinta could be caused by the same error. Therefore it might be interesting if this crash in Pinta could also be fixed by rebuilding the gtk-sharp2 package with the upstream patch [2] applied? [1] https://bugs.debian.org/1028220 [2] https://github.com/mono/gtk-sharp/commit/72637de6f2e519592f946a5acdf29a334c7bff75
Bug#1028220: cowbell: Cowbell crashes when opening a file
Control: reassign 1028220 libglib2.0-cil 2.12.40-3.1 Control: affects 1028220 cowbell = Managed Stacktrace: = at <0x> at GLib.SList:g_free <0x000a2> at GLib.ListBase:Empty <0x001a4> at GLib.ListBase:Dispose <0x0002b> at GLib.ListBase:Dispose <0x00034> at GLib.Marshaller:ListPtrToArray <0x0016f> at Gtk.FileChooserDialog:get_Uris <0x00057> at Cowbell.Gui.MainWindow:OnFileOpenActivate <0x0008b> Dear Maintainer, I tried to have a look and found this seems to be caused by an upstream commit in gtk-sharp2 [1], released in 2.12.39. This got fixed in upstream commit [2], released in 2.12.41. Unfortunately Debian packages just gtk-sharp version 2.12.40, therefore does not contain this fix. With a package built with patch [2] the crash is no longer visible with an unmodified cowbell package. This crash seems also to affect the package pinta in Debian [3]. Kind regards, Bernhard [1] https://github.com/mono/gtk-sharp/commit/80c7e733a9f93576cb3a98d957da1c8f428fdd5f [2] https://github.com/mono/gtk-sharp/commit/72637de6f2e519592f946a5acdf29a334c7bff75 [3] https://bugs.debian.org/877106
Bug#1028197: plasmashell: Program terminated with signal SIGSEGV
Am 24.01.23 um 00:30 schrieb piorunz: On 23/01/2023 22:46, Bernhard Übelacker wrote: https://bugs.debian.org/1028197 On Mon, 23 Jan 2023 21:48:23 + piorunz wrote: On 23/01/2023 13:35, Bernhard Übelacker wrote: journalctl --user --since="2023-01-08 12:10" --until="2023-01-08 12:12" -- No entries -- Then please try something like this: journalctl --user --since="2023-01-08 11:08" --until="2023-01-08 11:12" That worked! Attached. Jan 08 11:11:06 ryzen systemd-coredump[1987371]: Process 1341349 (kded5) of user 1000 dumped core. ... #3 0x7faafb991f90 n/a (libc.so.6 + 0x3bf90) #4 0x7faa7b2e8ba4 _ZNK10PackageKit11Transaction4roleEv (libpackagekitqt5.so.1 + 0x1aba4) #5 0x7faa7b3a4aae n/a (kded_apperd.so + 0xeaae) #6 0x7faa7b3a4b99 n/a (kded_apperd.so + 0xeb99) #7 0x7faafb6e8fcf n/a (libQt5Core.so.5 + 0x2e8fcf) #8 0x7faa7b2dc095 _ZN10PackageKit6Daemon22transactionListChangedERK11QStringList (libpackagekitqt5.so.1 + 0xe095) Jan 08 11:11:07 ryzen kscreen_backend_launcher[5795]: kscreen.xrandr: XRandR::setConfig Jan 08 11:11:07 ryzen kscreen_backend_launcher[5795]: kscreen.xrandr: Requested screen size is QSize(7680, 2160) Jan 08 11:11:07 ryzen kscreen_backend_launcher[5795]: kscreen.xrandr: Needed CRTCs: 2 Jan 08 11:11:07 ryzen kscreen_backend_launcher[5795]: kscreen.xrandr: Actions to perform: Jan 08 11:11:07 ryzen kscreen_backend_launcher[5795]: Primary Output: false Jan 08 11:11:07 ryzen kscreen_backend_launcher[5795]: kscreen.xrandr: Change Screen Size: false Jan 08 11:11:07 ryzen kscreen_backend_launcher[5795]: kscreen.xrandr: Disable outputs: false Jan 08 11:11:07 ryzen kscreen_backend_launcher[5795]: kscreen.xrandr: Change outputs: false Jan 08 11:11:07 ryzen kscreen_backend_launcher[5795]: kscreen.xrandr: Enable outputs: false Jan 08 11:11:07 ryzen kscreen_backend_launcher[5795]: kscreen.xrandr: XRandR::setConfig done! Jan 08 11:11:07 ryzen plasmashell[5575]: QFont::setPointSizeF: Point size <= 0 (0.00), must be greater than 0 Jan 08 11:11:07 ryzen plasmashell[5575]: 25 -- exe=/usr/bin/plasmashell Jan 08 11:11:07 ryzen plasmashell[5575]: KCrash: crashing... crashRecursionCounter = 2 Here was also just before such a kded5 crash right before. Either this or the startup of the new kded5 might trigger this, as it looks like setting up some screen parameters (xrandr). And while doing this plasmashell wrote this "QFont::setPointSizeF" message. Those two upstream bugs appear, but both got closed, because upstream could not reproduce them: https://bugs.kde.org/show_bug.cgi?id=453712 https://bugs.kde.org/show_bug.cgi?id=462098 I don't know which package management you use, but until there is a fix for Debian #1026062, you could experiment with another package manager like synaptic and uninstall apper for now, as a workaround. Kind regards, Bernhard
Bug#1028197: plasmashell: Program terminated with signal SIGSEGV
https://bugs.debian.org/1028197 On Mon, 23 Jan 2023 21:48:23 + piorunz wrote: On 23/01/2023 13:35, Bernhard Übelacker wrote: journalctl --user --since="2023-01-08 12:10" --until="2023-01-08 12:12" -- No entries -- Then please try something like this: journalctl --user --since="2023-01-08 11:08" --until="2023-01-08 11:12"
Bug#1028208: plasma-discover: Program terminated with signal SIGSEGV
Am 23.01.23 um 23:07 schrieb piorunz: On 23/01/2023 21:59, Bernhard Übelacker wrote: Hello Piotr, if it is not clear it would be possible to take the bug number from the email addresses and open the bug page e.g. https://bugs.debian.org/1028208. This was just about the plasma-discover crash part. However, you can also iterate through past logs by showing the different boots like this: $ journalctl --user --list-boots IDX BOOT ID FIRST ENTRY LAST ENTRY ... -14 Thu 2022-12-29 16:49:33 CET Mon 2023-01-09 12:05:55 CET ... And then show the logging for your user at that boot and scroll to the wanted time frame: $ journalctl --user -b -14 Kind regards, Bernhard Thank you Bernhard, I've extracted logs from that time, please see attached. Hello Piotr, ok, then I got distracted by this from coredumpctl, showing "GMT", while it might be really localtime ... at least it is the same as in journalctl ... Timestamp: Sun 2023-01-08 13:36:08 GMT (1h 29min ago) Your log shows four times a crashing kded5 before, then the plasma-discover: Jan 08 13:35:03 ryzen systemd-coredump[2835427]: Process 1997855 (kded5) of user 1000 dumped core. Jan 08 13:35:04 ryzen systemd-coredump[2835810]: Process 2835418 (kded5) of user 1000 dumped core. Jan 08 13:35:06 ryzen systemd-coredump[2836051]: Process 2835806 (kded5) of user 1000 dumped core. Jan 08 13:35:08 ryzen systemd-coredump[2836163]: Process 2836048 (kded5) of user 1000 dumped core. Jan 08 13:36:09 ryzen systemd-coredump[2842084]: Process 2832872 (plasma-discover) of user 1000 dumped core. And before the plasma-discover PID 2832872 shows: Jan 08 13:35:00 ryzen plasmashell[2832872]: adding empty sources model QStandardItemModel(0x55cb965ccf70) Jan 08 13:35:00 ryzen plasmashell[2832872]: file:///usr/lib/x86_64-linux-gnu/qt5/qml/QtQuick/Controls.2/org.kde.desktop/private/TextFieldContextMenu.qml:159:5: QML MenuItem: Binding loop detected for property "implicitWidth" Jan 08 13:35:00 ryzen plasmashell[2832872]: file:///usr/lib/x86_64-linux-gnu/qt5/qml/org/kde/kirigami.2/private/PrivateActionToolButton.qml:76:5: QML Binding: Binding loop detected for property "value" Jan 08 13:35:00 ryzen plasmashell[2832872]: packagekitqt.transaction: Unknown Transaction property: "Sender" QVariant(QString, ":1.577") Jan 08 13:35:01 ryzen plasmashell[2832872]: packagekitqt.transaction: Unknown Transaction property: "Sender" QVariant(QString, ":1.577") Jan 08 13:35:01 ryzen plasmashell[2832872]: packagekitqt.transaction: Unknown Transaction property: "Sender" QVariant(QString, ":1.577") Jan 08 13:35:03 ryzen plasmashell[2832872]: took really long to fetch PackageKitBackend(0x55cb964b2e50) Jan 08 13:35:03 ryzen plasmashell[2832872]: 29 -- exe=/usr/bin/plasma-discover Jan 08 13:35:03 ryzen plasmashell[2832872]: KCrash: crashing... crashRecursionCounter = 2 So I assume this plasma-discover crash is a result of the crash of kded5 with PID 1997855 in the same second before: #2 _ZN6KCrash19defaultCrashHandlerEi (libKF5Crash.so.5 + 0x586d) #3 n/a (libc.so.6 + 0x3bf90) #4 _ZNK10PackageKit11Transaction4roleEv (libpackagekitqt5.so.1 + 0x1aba4) #5 n/a (kded_apperd.so + 0xeaae) #6 n/a (kded_apperd.so + 0xeb99) #7 n/a (libQt5Core.so.5 + 0x2e8fcf) #8 _ZN10PackageKit6Daemon22transactionListChangedERK11QStringList (libpackagekitqt5.so.1 + 0xe095) Which looks like that from Debian bug #1026062. The 60 seconds between the crashes might be the timeout of KCrash to give the user the chance to click the icon in the systray, after that time it "forwards" the crash to get collected by systemd-coredump. So in the end it looks like plasma-discover is not prepared for kded5 crashing, not ideal, but if kded5 gets fixed this plasma-discover crash might disappear too. Kind regards, Bernhard
Bug#1028208: plasma-discover: Program terminated with signal SIGSEGV
Am 23.01.23 um 22:48 schrieb piorunz: On 23/01/2023 13:35, Bernhard Übelacker wrote: (gdb) bt #0 0x7fbffc2a9ccc in ?? () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x7fbffc25aef2 in raise () from /lib/x86_64-linux-gnu/libc.so.6 #2 0x7fbffe79dbe1 in KCrash::defaultCrashHandler(int) () from /lib/x86_64-linux-gnu/libKF5Crash.so.5 #3 #4 0x7fbffc2a9ccc in ?? () from /lib/x86_64-linux-gnu/libc.so.6 #5 0x7fbffc25aef2 in raise () from /lib/x86_64-linux-gnu/libc.so.6 #6 #7 0x7fbffc2a9ccc in ?? () from /lib/x86_64-linux-gnu/libc.so.6 #8 0x7fbffc25aef2 in raise () from /lib/x86_64-linux-gnu/libc.so.6 #9 0x7fbffad3c3b0 in g_closure_invoke () from /lib/x86_64-linux-gnu/libgobject-2.0.so.0 #10 0x7fbffad4f1a5 in ?? () from /lib/x86_64-linux-gnu/libgobject-2.0.so.0 Hello Piotr, this raise might indicate that libgobject wanted to stop the process for some reason. This reason it might have written to stdout/stderr. Therefore probably you can still retrieve this logging. From the "Sun 2023-01-08 13:36:08 GMT" I assume it happend at 14:36 your local time? Then following might possibly show related output. If there is some could you provide the related parts? journalctl --user --since="2023-01-08 14:34" --until="2023-01-08 14:38" Unfortunately there might also be some programs writing to ~/.xsession-errors, there the lines are not prefixed with the date and time ... So it might be difficult to find them there. Was this just a "one-time" crash, or do you get that regularly? Kind regards, Bernhard Hello Bernhard, Thanks for your reply. I am not sure what bug you want me to reply to so I reply to both. Plasma, or kwin, or entire desktop crashes all the time. There most likely are multiple bugs. This is one of them. Sometimes desktop crashes and there is no SIGSEV. Usually I launch Konsole from shortcut, restart kwin and plasmashell with --replace option, but this not always helps. I have modern Radeon GPU, it probably adds fuel to the fire. Can't wait for more updates regarding kwin/plasmashell/multi monitor handling/sleeping and waking up the monitor. There is a lot of bugs in these areas, when Radeon GPU is involved at least. I will be happy to debug as much as I can, you can tell me what else to do. $ journalctl --user --since="2023-01-08 14:34" --until="2023-01-08 14:38" -- No entries -- journalctl --user --since="2023-01-08 12:10" --until="2023-01-08 12:12" -- No entries -- .xsession-errors: Xsession: X session started for pioruns at Sat 7 Jan 08:04:38 GMT 2023 dbus-update-activation-environment: setting DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus dbus-update-activation-environment: setting DISPLAY=:0 dbus-update-activation-environment: setting XAUTHORITY=/home/pioruns/.Xauthority localuser:pioruns being added to access control list dbus-update-activation-environment: setting GTK_MODULES=gail:atk-bridge dbus-update-activation-environment: setting QT_ACCESSIBILITY=1 file:///home/pioruns/.local/share/plasma/look-and-feel/com.github.vinceliuice.Qogir-light/contents/splash/Splash.qml:89: ReferenceError: bottomRect is not defined file:///home/pioruns/.local/share/plasma/look-and-feel/com.github.vinceliuice.Qogir-light/contents/splash/Splash.qml:88: ReferenceError: bottomRect is not defined file:///home/pioruns/.local/share/plasma/look-and-feel/com.github.vinceliuice.Qogir-light/contents/splash/Splash.qml:89: ReferenceError: bottomRect is not defined file:///home/pioruns/.local/share/plasma/look-and-feel/com.github.vinceliuice.Qogir-light/contents/splash/Splash.qml:89: ReferenceError: bottomRect is not defined file:///home/pioruns/.local/share/plasma/look-and-feel/com.github.vinceliuice.Qogir-light/contents/splash/Splash.qml:88: ReferenceError: bottomRect is not defined file:///home/pioruns/.local/share/plasma/look-and-feel/com.github.vinceliuice.Qogir-light/contents/splash/Splash.qml:89: ReferenceError: bottomRect is not defined Xsession: X session started for pioruns at Mon 9 Jan 10:52:01 GMT 2023 This seems to be a session between 7th and 9th January. Hello Piotr, if it is not clear it would be possible to take the bug number from the email addresses and open the bug page e.g. https://bugs.debian.org/1028208. This was just about the plasma-discover crash part. However, you can also iterate through past logs by showing the different boots like this: $ journalctl --user --list-boots IDX BOOT ID FIRST ENTRY LAST ENTRY ... -14 Thu 2022-12-29 16:49:33 CET Mon 2023-01-09 12:05:55 CET ... And then show the logging for your user at that boot and scroll to the wanted time frame: $ journalctl --user -b -14 Kind regards, Bernhard
Bug#1028309: linux-image-6.0.0-6-amd64: Regression in Kernel 6.0: System partially freezes with "nvme controller is down"
On Thu, 12 Jan 2023 18:31:37 + =?UTF-8?Q?Julian_Gro=c3=9f?= wrote: My computer just froze on Kernel version 5.19.11-1. Though nothing got logged. Now I don't know if this is the same issue and newer kernels just behave better in terms of logging, or if this is a different issue.. I guess I will add a second screen to my computer, open journalctl on there, and point a camera at it to capture the issue. Hello Julian, Capturing with a camera might be possible. But if you have a serial port at the target machine, another capturing system available, and a cable connecting them, it might be more convenient to capture the output from the serial port, to have it in text form. Below links show the kernel parameters at the target machine: https://wiki.archlinux.org/title/working_with_the_serial_console#Kernel And at the capturing machine you could start "script", that would record all that happens to a file "typescript" in the current directory, and inside start "screen" to the other machine like here: https://wiki.archlinux.org/title/working_with_the_serial_console#Screen If the machine is still kind of responsive then it might also be possible to capture through a network connection via "netconsole", more details in following link: https://wiki.ubuntu.com/Kernel/Netconsole Kind regards, Bernhard
Bug#1029515: gdb: An attempt to debug a mono application gives: Assertion `jiter->jiter_data != nullptr' failed.
Package: gdb Version: 12.1-4+b1 Severity: normal X-Debbugs-Cc: bernha...@mailbox.org Dear Maintainer, I tried to debug a mono application in another Debian bug. There I received the assertion below, with just trying to run the application inside gdb. I found this gdb upstream bug report: https://sourceware.org/bugzilla/show_bug.cgi?id=29277 And a gdb package built with the proposed patch from comment 1 does no longer hit this assertion. Might be just an issue with debug information separated to external files (mono-runtime-dbg package). Kind regards, Bernhard # with this packages installed: cowbell cowbell-dbgsym mono-dbg mono-runtime-dbg benutzer@debian:~$ gdb -q --args /usr/bin/mono /usr/lib/cowbell/cowbell.exe Reading symbols from /usr/bin/mono... Reading symbols from /usr/lib/debug//usr/bin/mono-sgen... Mono support loaded. Mono support loaded. (gdb) run Starting program: /usr/bin/mono /usr/lib/cowbell/cowbell.exe [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". /build/gdb-JNEVqL/gdb-12.1/gdb/jit.c:1252: internal-error: jit_event_handler: Assertion `jiter->jiter_data != nullptr' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. - Backtrace - 0x55c034f2b21e gdb_internal_backtrace_1 /build/gdb-JNEVqL/gdb-12.1/gdb/bt-utils.c:122 0x55c034f2b21e _Z22gdb_internal_backtracev /build/gdb-JNEVqL/gdb-12.1/gdb/bt-utils.c:168 0x55c035259d54 internal_vproblem /build/gdb-JNEVqL/gdb-12.1/gdb/utils.c:394 0x55c035259f7a _Z15internal_verrorPKciS0_P13__va_list_tag /build/gdb-JNEVqL/gdb-12.1/gdb/utils.c:471 0x55c035398e81 _Z14internal_errorPKciS0_z /build/gdb-JNEVqL/gdb-12.1/gdbsupport/errors.cc:55 0x55c03509585c _Z17jit_event_handlerP7gdbarchP7objfile /build/gdb-JNEVqL/gdb-12.1/gdb/jit.c:1252 0x55c034f0d0b8 handle_jit_event /build/gdb-JNEVqL/gdb-12.1/gdb/breakpoint.c:5552 0x55c034f0d0b8 _Z20bpstat_run_callbacksP6bpstat /build/gdb-JNEVqL/gdb-12.1/gdb/breakpoint.c:5753 0x55c035088266 process_event_stop_test /build/gdb-JNEVqL/gdb-12.1/gdb/infrun.c:6452 0x55c03508c888 handle_stop_requested /build/gdb-JNEVqL/gdb-12.1/gdb/infrun.c:4465 0x55c03508c888 handle_stop_requested /build/gdb-JNEVqL/gdb-12.1/gdb/infrun.c:4460 0x55c03508c888 handle_inferior_event /build/gdb-JNEVqL/gdb-12.1/gdb/infrun.c:5695 0x55c03508e479 _Z20fetch_inferior_eventv /build/gdb-JNEVqL/gdb-12.1/gdb/infrun.c:4085 0x55c035399405 gdb_wait_for_event /build/gdb-JNEVqL/gdb-12.1/gdbsupport/event-loop.cc:725 0x55c0353999f6 _Z16gdb_do_one_eventv /build/gdb-JNEVqL/gdb-12.1/gdbsupport/event-loop.cc:212 0x55c0350cedec start_event_loop /build/gdb-JNEVqL/gdb-12.1/gdb/main.c:421 0x55c0350cedec captured_command_loop /build/gdb-JNEVqL/gdb-12.1/gdb/main.c:481 0x55c0350d0a64 captured_main /build/gdb-JNEVqL/gdb-12.1/gdb/main.c:1351 0x55c0350d0a64 _Z8gdb_mainP18captured_main_args /build/gdb-JNEVqL/gdb-12.1/gdb/main.c:1366 0x55c034e96219 main /build/gdb-JNEVqL/gdb-12.1/gdb/gdb.c:32 - 1: *jit_bp_sym.objfile = {original_name = "/usr/lib/debug//usr/bin/mono-sgen" ... 2: *jit_bp_sym.objfile->separate_debug_objfile_backlink = {original_name = "/usr/bin/mono" ... -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-2-amd64 (SMP w/16 CPU threads; PREEMPT) 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.11-1+b1 ii libc6 2.36-8 ii libdebuginfod1 0.188-2.1 ii libexpat1 2.5.0-1 ii libgcc-s1 12.2.0-14 ii libgmp102:6.2.1+dfsg1-1.1 ii libipt2 2.0.5-1 ii liblzma55.4.1-0.0 ii libmpfr64.2.0-1 ii libncursesw66.4-1 ii libpython3.11 3.11.1-2 ii libreadline88.2-1.3 ii libsource-highlight4v5 3.1.9-4.2+b2 ii libstdc++6 12.2.0-14 ii libtinfo6 6.4-1 ii libxxhash0 0.8.1-1 ii zlib1g 1:1.2.13.dfsg-1 Versions of packages gdb recommends: ii libc6-dbg [libc-dbg] 2.36-8 Versions of packages gdb suggests: pn gdb-doc pn gdbserver -- no debconf information Thank you for using reportbug
Bug#1028197: plasmashell: Program terminated with signal SIGSEGV
(gdb) bt ... #4 #5 0x7f54b82563fb in QQuickItem::~QQuickItem() () from /lib/x86_64-linux-gnu/libQt5Quick.so.5 #6 0x7f54b83d0045 in ?? () from /lib/x86_64-linux-gnu/libQt5Quick.so.5 #7 0x7f54b66dd53f in QObject::event(QEvent*) () from /lib/x86_64-linux-gnu/libQt5Core.so.5 #8 0x7f54b7362f5e in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /lib/x86_64-linux-gnu/libQt5Widgets.so.5 #9 0x7f54b66b17c8 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /lib/x86_64-linux-gnu/libQt5Core.so.5 #10 0x7f54b66b4761 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () from /lib/x86_64-linux-gnu/libQt5Core.so.5 #11 0x7f54b670a1d3 in ?? () from /lib/x86_64-linux-gnu/libQt5Core.so.5 #12 0x7f54b46657a9 in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #13 0x7f54b4665a38 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #14 0x7f54b4665acc in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #15 0x7f54b67098b6 in QEventDispatcherGlib::processEvents(QFlags) () from /lib/x86_64-linux-gnu/libQt5Core.so.5 #16 0x7f54b66b024b in QEventLoop::exec(QFlags) () from /lib/x86_64-linux-gnu/libQt5Core.so.5 #17 0x7f54b66b83b6 in QCoreApplication::exec() () from /lib/x86_64-linux-gnu/libQt5Core.so.5 #18 0x55937ecd0c6c in ?? () #19 0x7f54b624618a in ?? () from /lib/x86_64-linux-gnu/libc.so.6 #20 0x7f54b6246245 in __libc_start_main () from /lib/x86_64-linux-gnu/libc.so.6 Hello Piotr, I fear that backtrace is not that distinctive. Upstream I found [1] a few bugs, but they also do not give helpful pointers. So here it might also be helpful to see what might be contained in journalctl or in .xsession-errors: journalctl --user --since="2023-01-08 12:10" --until="2023-01-08 12:12" Can you please give a rough estimate how often it does crash? Kind regards, Bernhard [1] https://bugs.kde.org/show_bug.cgi?id=461464 https://bugs.kde.org/show_bug.cgi?id=460477
Bug#1028208: plasma-discover: Program terminated with signal SIGSEGV
(gdb) bt #0 0x7fbffc2a9ccc in ?? () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x7fbffc25aef2 in raise () from /lib/x86_64-linux-gnu/libc.so.6 #2 0x7fbffe79dbe1 in KCrash::defaultCrashHandler(int) () from /lib/x86_64-linux-gnu/libKF5Crash.so.5 #3 #4 0x7fbffc2a9ccc in ?? () from /lib/x86_64-linux-gnu/libc.so.6 #5 0x7fbffc25aef2 in raise () from /lib/x86_64-linux-gnu/libc.so.6 #6 #7 0x7fbffc2a9ccc in ?? () from /lib/x86_64-linux-gnu/libc.so.6 #8 0x7fbffc25aef2 in raise () from /lib/x86_64-linux-gnu/libc.so.6 #9 0x7fbffad3c3b0 in g_closure_invoke () from /lib/x86_64-linux-gnu/libgobject-2.0.so.0 #10 0x7fbffad4f1a5 in ?? () from /lib/x86_64-linux-gnu/libgobject-2.0.so.0 Hello Piotr, this raise might indicate that libgobject wanted to stop the process for some reason. This reason it might have written to stdout/stderr. Therefore probably you can still retrieve this logging. From the "Sun 2023-01-08 13:36:08 GMT" I assume it happend at 14:36 your local time? Then following might possibly show related output. If there is some could you provide the related parts? journalctl --user --since="2023-01-08 14:34" --until="2023-01-08 14:38" Unfortunately there might also be some programs writing to ~/.xsession-errors, there the lines are not prefixed with the date and time ... So it might be difficult to find them there. Was this just a "one-time" crash, or do you get that regularly? Kind regards, Bernhard
Bug#967941: Bug appeared again
On Sat, 14 Jan 2023 18:07:08 + Stephan =?ISO-8859-1?Q?Verb=FCcheln?= wrote: This bug appears back some time ago. For some months, video thumbnails failed to generate on multiple of my machines. Since then, I was trying to figure out the cause. It only seemed to affect h264, but not all videos were affected. I even had multiple videos saved from Youtube, some were generating thumbnails, others were not. I could not find any difference in the codec parameters. Adding the -l option in /usr/share/thumbnailers/totem.thumbnailer worked to prevent this bug. Does this option have any downsides? Regards Hello, it looks like this option makes it not setting the process limits [1] [2]. Simon wrote it that way before: totem-video-thumbnailer sets a resource limit ... to avoid a runaway thumbnailing process consuming disproportionate system resources. Kind regards, Bernhard [1] https://sources.debian.org/src/totem/43.0-2/src/totem-video-thumbnailer.c/#L587 587 { "no-limit", 'l', G_OPTION_FLAG_REVERSE, G_OPTION_ARG_NONE, _limit, "Don't limit the thumbnailing time to 30 seconds", NULL }, [2] https://sources.debian.org/src/totem/43.0-2/src/totem-resources.c/?hl=111#L111
Bug#1028083: plasma-discover: Discover tray app crashes kded5, causing other system tray icons to vanish
Am 22.01.23 um 14:19 schrieb Gregor Riepl: FYI: My kded core dumps also contained something about a closed DBus connection in a different thread's stack trace. Perhaps this is related? I am not able to exclude it to be related, maybe it is the start of the row of events. When debugging through it I got the impression that this Transaction object with RoleUnknown gets "marked for deletion" kind of unconditionally. But I am not much experienced with this source code. Kind regards, Bernhard
Bug#1028068: ccd2iso: Outputs zero bytes ISO
On Fri, 06 Jan 2023 15:08:11 +0100 Lucio Crusca wrote: $ time ccd2iso e.i.vol.16.img e.i.vol.16.iso Unrecognized sector mode (0) at sector 0! real0m0,110s user0m0,003s sys 0m0,005s $ ls -lh *.iso Dear Maintainer, this seems to be an upstream issue. The ccd2iso author states in the README file [1], "only single session image supported", maybe this image was more complex than ccd2iso is prepared for. There is also an upstream bug report [2], but the project seems kind of inactive since a few years. Kind regards, Bernhard [1] https://sources.debian.org/src/ccd2iso/0.3-7/README/#L54 [2] https://sourceforge.net/p/ccd2iso/bugs/8/ (Maybe a workaround could be to mount the ccd with cdemu [3], not packaged in Debian, and take an iso image from the virtual drive.) [3] https://cdemu.sourceforge.io/
Bug#1028083: plasma-discover: Discover tray app crashes kded5, causing other system tray icons to vanish
On Fri, 06 Jan 2023 16:50:02 +0100 Gregor Riepl wrote: ... #14 0x7f9c8c26f6ed in QObject::connect<...> (...) at /usr/include/x86_64-linux-gnu/qt5/QtCore/qobject.h:268 #15 TransactionJob::TransactionJob (...) at ./apperd/TransactionJob.cpp:47 #16 0x7f9c8c271648 in TransactionWatcher::transactionChanged (...) at ./apperd/TransactionWatcher.cpp:211 #17 0x7f9c8c271ade in TransactionWatcher::watchTransaction (...) at ./apperd/TransactionWatcher.cpp:106 #18 0x7f9c8c271b99 in TransactionWatcher::transactionListChanged (...) at ./apperd/TransactionWatcher.cpp:85 ... Hello, this seems similar to the backtrace in bug #1026062. At least the "transactionListChanged" and the two lines above. Kind regards, Bernhard https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1026062
Bug#1027326: kde-plasma-desktop: Process 1465 (kded5) of user 1000 dumped core.
On Fri, 30 Dec 2022 09:46:49 -0300 craudio wrote: #8 0x7f2ba43e5b99 n/a (kded_apperd.so + 0xeb99) #9 0x7f2becae8fcf n/a (libQt5Core.so.5 + 0x2e8fcf) #10 0x7f2ba4323095 _ZN10PackageKit6Daemon22transactionListChangedERK11QStringList (libpackagekitqt5.so.1 + 0xe095) Hello, this seems similar to the backtrace in bug #1026062. At least the "transactionListChanged" and the two lines above. Kind regards, Bernhard https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1026062
Bug#1027952: pcre2 causes crashes in link-grammar
Dear Maintainer, I tried to reproduce this segfault. Unfortunately this did not work as expected. The segfault in multi-thread did not show up. But I received one in multi-dict (in e.g. 3 of 6 runs). This was done in a up-to-date unstable amd64 VM, running at a AMD cpu, 16 threads given to the VM. The segfault did manifest in each case in libhunspell. This seems to be caused by the static variable "utf_tbl" possibly being shared between threads, and being freed and initialized while maybe used in another thread. Kind regards, Bernhard (gdb) bt #0 0x7f56b5b3159b in unicodetolower(unsigned short, int) () from /lib/x86_64-linux-gnu/libhunspell-1.7.so.0 #1 0x7f56b5b317ae in get_captype_utf8(std::vector > const&, int) () from /lib/x86_64-linux-gnu/libhunspell-1.7.so.0 #2 0x7f56b5b385bc in ?? () from /lib/x86_64-linux-gnu/libhunspell-1.7.so.0 ... (gdb) bt #0 0x7f56b5b3159b in unicodetolower (c=c@entry=116, langnum=langnum@entry=0) at ./src/hunspell/csutil.cxx:2482 #1 0x7f56b5b317ae in get_captype_utf8 (word=std::vector of length 6, capacity 64 = {...}, langnum=0) at ./src/hunspell/csutil.cxx:2538 #2 0x7f56b5b385bc in HashMgr::get_clen_and_captype (workbuf=std::vector of length 6, capacity 64 = {...}, captype=, word="tenant", this=0x7f568eb64d90) at ./src/hunspell/hashmgr.cxx:468 #3 HashMgr::get_clen_and_captype (workbuf=..., captype=, word=..., this=0x7f568eb64d90) at ./src/hunspell/hashmgr.cxx:464 #4 HashMgr::load_tables (this=0x7f568eb64d90, tpath=, key=) at ./src/hunspell/hashmgr.cxx:690 #5 0x7f56b5b38dfc in HashMgr::HashMgr (this=this@entry=0x7f568eb64d90, tpath=tpath@entry=0x7f56adffa800 "/usr/share/hunspell/en_US.dic", apath=apath@entry=0x7f56adffa400 "/usr/share/hunspell/en_US.aff", key=key@entry=0x0) at ./src/hunspell/hashmgr.cxx:101 #6 0x7f56b5b43616 in HunspellImpl::HunspellImpl (this=0x7f568fb8c850, affpath=0x7f56adffa400 "/usr/share/hunspell/en_US.aff", dpath=0x7f56adffa800 "/usr/share/hunspell/en_US.dic", key=0x0) at ./src/hunspell/hunspell.cxx:179 #7 0x7f56b5b43a27 in Hunspell_create (affpath=affpath@entry=0x7f56adffa400 "/usr/share/hunspell/en_US.aff", dpath=dpath@entry=0x7f56adffa800 "/usr/share/hunspell/en_US.dic") at ./src/hunspell/hunspell.cxx:2164 #8 0x7f56b60decc1 in spellcheck_create (lang=0x7f568d0e22c0 "en") at tokenize/spellcheck-hun.c:101 #9 0x7f56b60af6e5 in dictionary_six_str (lang=lang@entry=0x560b8f8ac37a "en", input=input@entry=0x7f568f9bc460 "\n %", '*' , "%\n %", ' ' , "%\n % Copyright (C) 1991-1998 Daniel "..., dict_name=dict_name@entry=0x7f568fa3e630 "en/4.0.dict", pp_name=pp_name@entry=0x7f568fa3e6f0 "en/4.0.knowledge", cons_name=cons_name@entry=0x7f568fa3e8e0 "en/4.0.constituent-knowledge", affix_name=affix_name@entry=0x7f568fa3e930 "en/4.0.affix", regex_name=0x7f568fa3e070 "en/4.0.regex") at dict-file/dictionary.c:159 #10 0x7f56b60afc28 in dictionary_six (regex_name=0x7f568fa3e070 "en/4.0.regex", affix_name=0x7f568fa3e930 "en/4.0.affix", cons_name=0x7f568fa3e8e0 "en/4.0.constituent-knowledge", pp_name=0x7f568fa3e6f0 "en/4.0.knowledge", dict_name=0x7f568fa3e630 "en/4.0.dict", lang=0x560b8f8ac37a "en") at dict-file/dictionary.c:281 #11 dictionary_create_from_file (lang=0x560b8f8ac37a "en") at dict-file/dictionary.c:307 #12 0x560b8f8ab598 in parse_one_sent (sent_str=0x560b8f8ac248 "The line extends 10 miles offshore.") at ./tests/multi-dict.cc:28 #13 parse_sents (thread_id=, niter=30) at ./tests/multi-dict.cc:82 #14 0x7f56b5ed44a3 in std::execute_native_thread_routine (__p=0x560b90a39a70) at ../../../../../src/libstdc++-v3/src/c++11/thread.cc:82 #15 0x7f56b5ca7fd4 in start_thread (arg=) at ./nptl/pthread_create.c:442 #16 0x7f56b5d2866c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81 2482 return (utf_tbl) ? utf_tbl[c].clower : c; => 0x7f56b5b3159b <_Z14unicodetolowerti+27>:movzwl 0x4(%rdx,%rax,2),%eax (gdb) print/x $rdx $49 = 0x7f56ac614010 (gdb) print/x $rax $50 = 0x15c (gdb) x/1xg ($rdx + $rax * 2) + 0x4 0x7f56ac6142cc: Cannot access memory at address 0x7f56ac6142cc (gdb) print utf_tbl $51 = (unicode_info2 *) 0x0 # Unstable amd64 qemu VM 2023-01-20 apt update apt dist-upgrade apt install systemd-coredump mc gdb valgrind rr autopkgtest dpkg-dev libhunspell-1.7-0-dbgsym libstdc++6-dbgsym apt build-dep link-grammar autopkgtest --shell-fail link-grammar -- null PASS: mem-leak PASS: multi-java PASS: dict-reopen ../test-driver: Zeile 112: 12435 Speicherzugriffsfehler (Speicherabzug geschrieben) "$@" >> "$log_file" 2>&1 FAIL: multi-dict PASS: multi-thread === link-grammar 5.12.0: tests/test-suite.log === # TOTAL: 5 # PASS: 4 # SKIP: 0 # XFAIL: 0 # FAIL: 1 # XPASS: 0 # ERROR: 0 .. contents:: :depth: 2 FAIL: multi-dict [ 348.182545] multi-dict[12511]: segfault at 7f56ac6142cc ip 7f56b5b3159b sp 7f56adffa188 error 4 in
Bug#1026069: scrcpy: Bug#1026069: Cannot find symbols during build
On Wed, 14 Dec 2022 10:07:27 +0100 martin f krafft wrote: Package: scrcpy Version: 1.24-1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) Running `apt build-dep scrcpy` and `fakeroot debian/rules binary` results in plenty of unresolvable symbols. Hello Martin, I could not reproduce an issue inside a minimal unstable VM. The package builds with "fakeroot debian/rules binary" and "dpkg-buildpackage" without showing an error. Can you still reproduce it? Kind regards, Bernhard
Bug#1025498: scrcpy: Bug#1025498: Links to old libavdevice58
On Mon, 5 Dec 2022 21:33:03 +0100 martin f krafft wrote: Package: scrcpy Version: 1.24-1 Severity: grave The package depends on libavdevice59, but it's apparently built against libavdevice58: lotus:~% ldd =scrcpy | grep libavdevice libavdevice.so.58 => not found Hello Martin, can you still reproduce this issue? I have installed scrcpy inside a minimal unstable VM, and receive the output below [1]. Also the build log [2] seems to show that libavdevice59 was installed during package build. Your ldd shows "=scrcpy" instead of an absolute path, does it really point to the binary from the package? Kind regards, Bernhard [1] benutzer@debian:~$ ldd /usr/bin/scrcpy | grep libavdevice libavdevice.so.59 => /lib/x86_64-linux-gnu/libavdevice.so.59 (0x7fa06f9cd000) benutzer@debian:~$ dpkg -l | grep scrcpy ii scrcpy1.24-1 amd64 Display and control your Android device ii scrcpy-server 1.24-1 all Display and control your Android device - server binary [2] https://buildd.debian.org/status/fetch.php?pkg=scrcpy=amd64=1.24-1=1658088686=0 Unpacking libavdevice59:amd64 (7:5.0.1-3+b1) ... Unpacking libavdevice-dev:amd64 (7:5.0.1-3+b1) ...
Bug#1027026: libllvm15: Packages depending on libllvm15:i386 fail to install because of version mistmatch
On Tue, 27 Dec 2022 00:11:12 +0100 Tobias Frost wrote: On Mon, 26 Dec 2022 16:53:27 +0200 Kostadin Shishmanov wrote: > I think it happens because libllvm15:i386 is at version 15.0.6-3+b1, while libllvm15:amd64 is at version 15.0.6-3 This is due to #1025530: on i386, the binNMU built and on all other archs (incl. amd64) it didn't… Once that FTBFS is fixed, it will become coninstallable again. Is this still an issue, because libllvm15 is now available in version 1:15.0.6-4+b1 in testing? Kind regards, Bernhard
Bug#1004154: Fwd: Bug#1004154: xserver-xorg-video-qxl: XOrg frequently crashes when using qxl driver: qxl(0): error doing QXL_ALLOC
Forwarding, as the email from TJ possibly did not reach Felix. On Fri, 21 Oct 2022 11:43:07 +0100 TJ wrote: On Sat, 12 Feb 2022 08:21:55 + Felix Leimbach wrote: > I noticed that vgamem_mb was still low (32 MB). > So I changed to this (slightly wasteful) command-line and am now running the latest kernel (5.15.0-3-amd64): > > -vga none -device qxl-vga,ram_size_mb=256,vgamem_mb=256,vram_size_mb=256,vram64_size_mb=256,max_outputs=1 > > Will report back if that helps. Did the vgamem_mb change fix the issue? This bug is currently keeping the package out of bookworm and, if it was a user-specific issue, ought to be closed and the package reintroduced to bookworm. I'm currently doing a full-upgrade bullseye to bookworm and this removal is a blocker for VMs.
Bug#1026389: xfce4: split screen doesn't work anymore
After enabling "With a dragged window" in xfwm4-settings which switches off the tile_on_move setting, the user can re-enable this setting by "Automatically tile windows when moving towards the screen edge" in xfwm4-tweaks-settings. (If both settings applications are opened side by side, one can watch how enabling the first disables the second.) Thanks a lot! This worked (and yes, unintuitive as hell). Unfortunately not the most intuitive process. Dear Maintainer, in an unmodified default xfwm4 config both "tile_on_move" and "wrap_windows" are true, and seems not to cause issues. But therefore when activating "With a dragged window" the deactivation of "tile_on_move" in cb_wrap_windows_toggled seems superfluous? Removing cb_wrap_windows_toggled would probably be more intuitive, as both options are in different configuration applications. Kind regards, Bernhard .config/xfce4/xfconf/xfce-perchannel-xml/xfwm4.xml
Bug#1026389: xfce4: split screen doesn't work anymore
The patch at the bottom would set tile_on_move to true, if the "With a dragged window" gets switched off. Now after some sleep I found that this might really be the way upstream wants this to handle, so the patch is wrong. After enabling "With a dragged window" in xfwm4-settings which switches off the tile_on_move setting, the user can re-enable this setting by "Automatically tile windows when moving towards the screen edge" in xfwm4-tweaks-settings. (If both settings applications are opened side by side, one can watch how enabling the first disables the second.) Unfortunately not the most intuitive process. Kind regards, Bernhard
Bug#1026389: xfce4: split screen doesn't work anymore
"With a dragged window" - default as far as I see is on. I confirm that either with those 4 defaults, or with "with a dragged window" off (as you suggested that would fix it), I still have it bugged. If you still don't get a dragged window filling half of the screen, then I can't reproduce your issue and don't have a solution. Is there any other setting that might be affecting? Hello Alex, I tried to find out where the magic happens, and wanted to write it to you. But I found some strange wiring about the "With a dragged window" configuration option. Somehow it is responsible in the configuration file for "/general/snap_to_windows" and "/general/tile_on_move". Unfortunately the latter setting can just be changed once, and that is switching off. The patch at the bottom would set tile_on_move to true, if the "With a dragged window" gets switched off. Kind regards, Bernhard (gdb) bt #0 clientTile (c=0x14d6800, cx=1, cy=224, tile=TILE_LEFT, send_configure=1, restore_position=0) at ./src/client.c:3701 #1 0x004c61c8 in clientMoveTile (event=, c=0x14d6800) at ./src/moveresize.c:862 #2 clientMoveEventFilter (event=0x1323410, data=0xbfab8914) at ./src/moveresize.c:1063 #3 0x004b4ace in eventXfwmFilter (gdk_xevent=0xbfab871c, gevent=0x149a400, data=0x1468d30) at ./src/event_filter.c:175 #4 0xb73693b1 in () at /lib/i386-linux-gnu/libgdk-3.so.0 ... $ grep -E "To screen.*borders|To other.*windows|With the mouse.*pointer|With a.*dragged window" . -Rn -B1 --exclude *.po ... ./settings-dialogs/xfwm4-dialog.glade-1315- ./settings-dialogs/xfwm4-dialog.glade:1316:With a _dragged window $ grep -E "snap_to_border_check|snap_to_window_check|wrap_workspaces_check|wrap_windows_check" . -Rn -B1 ... ./settings-dialogs/xfwm4-settings.c-611- xfconf_g_property_bind (settings->priv->wm_channel, "/general/wrap_windows", G_TYPE_BOOLEAN, ./settings-dialogs/xfwm4-settings.c:612: wrap_windows_check, "active"); ... ./settings-dialogs/xfwm4-settings.c:617: g_signal_connect (G_OBJECT (wrap_windows_check), "toggled", ./settings-dialogs/xfwm4-settings.c-618-G_CALLBACK (cb_wrap_windows_toggled), ... ./settings-dialogs/xfwm4-settings.c:1612 cb_wrap_windows_toggled (GtkToggleButton *toggle, XfconfChannel *channel) ./settings-dialogs/xfwm4-settings.c:1613 { ./settings-dialogs/xfwm4-settings.c:1614if (gtk_toggle_button_get_active (toggle)) ./settings-dialogs/xfwm4-settings.c:1615 xfconf_channel_set_bool (channel, "/general/tile_on_move", FALSE); ./settings-dialogs/xfwm4-settings.c:1616 } $ grep -E "wrap_workspaces|wrap_windows|snap_to_border|snap_to_windows|tile_on_move" -Rn --include *.xml ... .config/xfce4/xfconf/xfce-perchannel-xml/xfwm4.xml:63: .config/xfce4/xfconf/xfce-perchannel-xml/xfwm4.xml:80: --- xfwm4-4.18.0.orig/settings-dialogs/xfwm4-settings.c +++ xfwm4-4.18.0/settings-dialogs/xfwm4-settings.c @@ -1613,6 +1613,8 @@ cb_wrap_windows_toggled (GtkToggleButton { if (gtk_toggle_button_get_active (toggle)) xfconf_channel_set_bool (channel, "/general/tile_on_move", FALSE); + else +xfconf_channel_set_bool (channel, "/general/tile_on_move", TRUE); }
Bug#1026389: xfce4: split screen doesn't work anymore
And indeed, when unchecking following in Window Manager settings it seems to "snap" again: Wrap workspaces when reaching the screen edge / With a dragged window I had that one disabled (but I didn't do that; I guess it was like that by default). My windows don't move to other workspaces when moving them, and yet don't "snap". I don't know exactly what is meant by snap, so I'll clarify: If I move a window adjacent to another window or the edge of the screen, it repositions itself so the the borders are touching (I can adjust the distance at which that occurs). That's "Settings manager->Personal->Window Manager->Advanced->Windows Snapping". However, windows don't resize automatically to use half screen or quarter screen. I can't manage to get that working, which previously worked by default. Sorry for not being enough precise. When I disabled "With a dragged window" and applied the setting a file manager window dragged to the left border of my VM did get resized to fill half of the screen. "To screen borders" - default as far as I see is on and was on in all my tests. "To other windows" - default as far as I remember is off and was off in all my tests. "With the mouse pointer" - default as far as I see is off and was off in all my tests. "With a dragged window" - default as far as I see is on. If you still don't get a dragged window filling half of the screen, then I can't reproduce your issue and don't have a solution. Kind regards, Bernhard
Bug#1026389: xfce4: split screen doesn't work anymore
When I upgraded my Sid system yesterday (I do it every week or so), windows cannot be moved to the edge of the screen to have them use half screen. It simply moves there without readjusting. Dear Maintainer, hello Alejandro, this looks like it appeared in unstable with the appearance of xfwm4 4.18.0-1 at 2022-12-15, replacing the previous version 4.16.1-1 in unstable. And looks like it was discussed upstream in this report: https://gitlab.xfce.org/xfce/xfwm4/-/issues/685 And indeed, when unchecking following in Window Manager settings it seems to "snap" again: Wrap workspaces when reaching the screen edge / With a dragged window So this looks like expected behaviour from upstream. Kind regards, Bernhard
Bug#1026062: kded5: kded crashes with signal 11
Short addition: I tried to bring this to the attention of packagekit-qt developers in this bug report: https://github.com/PackageKit/PackageKit-Qt/issues/42 Kind regards, Bernhard
Bug#1026062: kded5: kded crashes with signal 11
Dear Maintainer, I was able to reproduce this issue inside a minimal amd64 qemu VM running Bookworm/testing. By editing the kded service unit [1] I could get valgrind have a look at this issue and it produced a matching use-after-free [2]. By further editing the service unit I was also able to record such a crash with rr-debugger, that allows debugging in reverse execution direction. So I guess these are the relevant events: - A object of PackageKit::Transaction gets created [3] (0x562777928e00) - Inside its constructor also a QDeferredDeleteEvent gets created [4] (0x562777885690) - The PackageKit::Transaction object gets stored in the m_transactions container [5] - Qt reaches its event loop and processes the QDeferredDeleteEvent and deletes the PackageKit::Transaction [6] - In TransactionWatcher::watchTransaction the member m_transactions still holds a reference to the already deleted object and gets found because a matching "tid" gets processed. "Unfortunately" the memory of the PackageKit::Transaction was already modified therefore the segmentation fault follows. [7] For comparision the matching systemd-coredump report with mangled symbols in [8]. There are some reports in bugs.kde.org [9]. But in 462706 it is mentioned that this is an issue in packagekit-qt, unfortunately could not yet find a report there. Kind regards, Bernhard [1] /usr/lib/systemd/user/plasma-kded.service -ExecStart=/usr/bin/kded5 +ExecStart=/usr/bin/valgrind /usr/bin/kded5 or +ExecStart=/usr/bin/rr record /usr/bin/kded5 systemctl --user daemon-reload systemctl --user start plasma-kded Then trigger in Discover a package list update. [2] ==12351== Invalid read of size 8 ==12351==at 0x27458BA0: PackageKit::Transaction::role() const (transaction.cpp:297) ==12351==by 0x273B6AAD: TransactionWatcher::watchTransaction(QDBusObjectPath const&, bool) (TransactionWatcher.cpp:104) ==12351==by 0x273B6B98: TransactionWatcher::transactionListChanged(QStringList const&) (TransactionWatcher.cpp:85) ==12351==by 0x5B59FCE: ??? (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.15.7) ==12351==by 0x2744C094: PackageKit::Daemon::transactionListChanged(QStringList const&) (moc_daemon.cpp:419) ==12351==by 0x5B59FFB: ??? (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.15.7) ==12351==by 0x27464B37: TransactionListChanged (daemonproxy.moc:331) ==12351==by 0x27464B37: OrgFreedesktopPackageKitInterface::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) (daemonproxy.moc:178) ==12351==by 0x27465D72: OrgFreedesktopPackageKitInterface::qt_metacall(QMetaObject::Call, int, void**) (daemonproxy.moc:288) ==12351==by 0x580361A: ??? (in /usr/lib/x86_64-linux-gnu/libQt5DBus.so.5.15.7) ==12351==by 0x5B4E76F: QObject::event(QEvent*) (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.15.7) ==12351==by 0x49CAF5D: QApplicationPrivate::notify_helper(QObject*, QEvent*) (in /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5.15.7) ==12351==by 0x5B227C7: QCoreApplication::notifyInternal2(QObject*, QEvent*) (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.15.7) ==12351== Address 0x1a6a2a10 is 16 bytes inside a block of size 24 free'd ==12351==at 0x484371B: operator delete(void*) (vg_replace_malloc.c:923) ==12351==by 0x5B4E53E: QObject::event(QEvent*) (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.15.7) ==12351==by 0x49CAF5D: QApplicationPrivate::notify_helper(QObject*, QEvent*) (in /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5.15.7) ==12351==by 0x5B227C7: QCoreApplication::notifyInternal2(QObject*, QEvent*) (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.15.7) ==12351==by 0x5B25760: QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.15.7) ==12351==by 0x5B7B1D2: ??? (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.15.7) ==12351==by 0x6E1B7A8: g_main_context_dispatch (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7400.4) ==12351==by 0x6E1BA37: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7400.4) ==12351==by 0x6E1BACB: g_main_context_iteration (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7400.4) ==12351==by 0x5B7A8B5: QEventDispatcherGlib::processEvents(QFlags) (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.15.7) ==12351==by 0x5B2124A: QEventLoop::exec(QFlags) (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.15.7) ==12351==by 0x5B293B5: QCoreApplication::exec() (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.15.7) ==12351== Block was alloc'd at ==12351==at 0x4840F2F: operator new(unsigned long) (vg_replace_malloc.c:422) ==12351==by 0x273B693B: TransactionWatcher::watchTransaction(QDBusObjectPath const&, bool) (TransactionWatcher.cpp:95) ==12351==by 0x273B6B98: TransactionWatcher::transactionListChanged(QStringList const&) (TransactionWatcher.cpp:85) ==12351==by 0x5B59FCE: ??? (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.15.7) ==12351==by
Bug#1026426: plasma-workspace: No default wallpaper with black desktop, and ksplashqml hides desktop until hard time limit of 30 seconds is reached
Dear Maintainer, I retested this inside a minimal Bookworm/testing VM now because the last plasma package updates seem to have settled a bit. Unfortunately the black background and the 30 seconds splash are still visible. At least in this bug report at least the black default wallpaper gets described: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1026070#17 After an affected new user configures a wallpaper the previously reported message from main.qml is gone, but the 30 second splash is also still there. To make the 30 second splash issue better visible I created this upstream merge request: https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/2450/diffs This one applied to the Debian package showed that the last step "desktop" is missing. See this for all needed steps: https://invent.kde.org/plasma/plasma-workspace/-/blob/master/ksplash/ksplashqml/splashapp.cpp#L36 Kind regards, Bernhard
Bug#1026061: bart: FTBFS randomly in bullseye (failing test)
Am 01.01.23 um 16:55 schrieb Uecker, Martin: This is likely a numerical error caused by reordering a floating point sum by parallelization. It is not worth spending time on it. I can apply the patch, but I do not have much time now. Is there some urgency? Not from my side, I just tried to help debugging the issue. Kind regards, Bernhard
Bug#1026061: bart: FTBFS randomly in bullseye (failing test)
Hello, thanks for your immediate responses. Am 01.01.23 um 15:55 schrieb Uecker, Martin: One could just relax (or simply remove) the test from bullseye or packport the version bookworm. I guess that would be applying 0003-relax-failing-unit-test.patch to the Bullseye version. The wine code is broken (it violates the effective types rules of ISO C). Ok, just wanted to offer an option. Am 01.01.23 um 16:02 schrieb Santiago Vila: Hi. Such failure rate differs a lot from what I get, which is about 50% in some systems (which is why I believe we should fix this in bullseye). Maybe this is an issue of tests optimized for Intel and failing a lot on AMD or viceversa (there was another package for which that happened). If it might be of any help - my system is a "AMD Ryzen 7 1700", the qemu VM runs with "-enable-kvm -cpu host -smp 16". By locking the process to just a single cpu I do not get any failures: taskset -c 0 bash -c "while true; do ./test_nufft ; done" If I allow two cpus the failure rate is at 77%: taskset -c 0,1 bash -c "while true; do ./test_nufft ; done" This still does not affect a Bookworm VM, no failures even with the relax patch removed. Kind regards, Bernhard
Bug#1026061: bart: FTBFS randomly in bullseye (failing test)
Dear Maintainer, I could reproduce this failure in a bullseye VM. There the "test_nufft_adjoint" fails in about 1.2 % of the runs. Attached diff helps to make it more visible. It looks like the float comparison fails because the limit of "1.E-6f" is slightly not enough. If interpret following floating point comparison document right, then the failing cases are just 8 representable floats "ULPs" away from the expected value, below 8 it does not fail. https://randomascii.wordpress.com/2012/02/25/comparing-floating-point-numbers-2012-edition/ Maybe upstream could consider changing that float comparison to something like this: https://source.winehq.org/git/wine.git/blob/HEAD:/dlls/ddraw/tests/ddraw7.c#l61 In the newer Bookworm package I have found following patch, which does relax exactly this test: https://salsa.debian.org/med-team/bart/-/blob/master/debian/patches/0003-relax-failing-unit-test.patch But for some reason it does still not fail if I remove that patch in the Bookworm version. Kind regards, Bernhard make utest while true; do ./test_nufft ; done Bullseye/stable/bart-0.6.00: - -1.067273+3.247031i - -1.067273+3.247030i - sc1=6.3619987432198080e+01 sc2=6.3619926397041880e+01 diff=9.6109602054639254e-07 diff_ulp=7 adjoint diff: 0.01 9.6109602054639254e-07, limit: 9.999747524271e-07 ./test_nufft: 1/ 1 passed. - -1.067273+3.247030i - -1.067273+3.247030i - sc1=6.3619926397041830e+01 sc2=6.3619926397041880e+01 diff=8.3446502685546875e-07 diff_ulp=7 adjoint diff: 0.01 8.3446502685546875e-07, limit: 9.999747524271e-07 ./test_nufft: 1/ 1 passed. - -1.067273+3.247031i - -1.067273+3.247030i - sc1=6.3619987432198087e+01 sc2=6.3619926397041880e+01 diff=8.5963040419301251e-07 diff_ulp=6 adjoint diff: 0.01 8.5963040419301251e-07, limit: 9.999747524271e-07 ./test_nufft: 1/ 1 passed. - -1.067272+3.247031i - -1.067273+3.247030i - sc1=6.3619987432198073e+01 sc2=6.3619926397041880e+01 diff=1.0662403155947686e-06 diff_ulp=8 adjoint diff: 0.01 1.0662403155947686e-06, limit: 9.999747524271e-07 ERROR: ./test_nufft: 0/ 1 passed. - -1.067273+3.247031i - -1.067273+3.247030i - sc1=6.3619987432198087e+01 sc2=6.3619926397041880e+01 diff=8.5963040419301251e-07 diff_ulp=6 adjoint diff: 0.01 8.5963040419301251e-07, limit: 9.999747524271e-07 ./test_nufft: 1/ 1 passed. - -1.067273+3.247031i - -1.067273+3.247030i - sc1=6.3619987432198080e+01 sc2=6.3619926397041880e+01 diff=9.6109602054639254e-07 diff_ulp=7 adjoint diff: 0.01 9.6109602054639254e-07, limit: 9.999747524271e-07 ./test_nufft: 1/ 1 passed. Bookworm/testing/bart-0.8.00: - -1.067272+3.247031i - -1.067273+3.247030i - sc1=6.3619987432198073e+01 sc2=6.3619926397041880e+01 diff=1.0662403155947686e-06 diff_ulp=8 adjoint diff: 0.00 3.1195452265819767e-07, limit: 9.999747524271e-07 ./test_nufft: 1/ 1 passed.diff --git a/src/linops/lintest.c b/src/linops/lintest.c index c1d1ebc..b0e3bc1 100644 --- a/src/linops/lintest.c +++ b/src/linops/lintest.c @@ -59,7 +59,7 @@ static float linop_test_adjoint_generic(const struct linop_s* op, bool rvc) md_free(tmp3); md_free(tmp4); - debug_printf(DP_DEBUG4, "- %f%+fi - %f%+fi -\n", crealf(sc1), cimagf(sc1), crealf(sc2), cimagf(sc2)); + debug_printf(DP_INFO, "- %f%+fi - %f%+fi - sc1=%.16e sc2=%.16e diff=%.16e diff_ulp=%d\n", crealf(sc1), cimagf(sc1), crealf(sc2), cimagf(sc2), sc1, sc2, cabsf(sc1 - sc2), abs(*(int*) - *(int*))); return cabsf(sc1 - sc2); } diff --git a/utests/test_nufft.c b/utests/test_nufft.c index ec02762..54163dc 100644 --- a/utests/test_nufft.c +++ b/utests/test_nufft.c @@ -112,7 +112,7 @@ static bool test_nufft_adjoint(void) float diff = linop_test_adjoint(op); - debug_printf(DP_DEBUG1, "adjoint diff: %f\n", diff); + debug_printf(DP_INFO, "adjoint diff: %f %.16e, limit: %.16e\n", diff, diff, 1.E-6f); bool ret = (diff < 1.E-6f); @@ -231,13 +231,6 @@ static bool test_nufft_basis_toeplitz(void) -UT_REGISTER_TEST(test_nufft_forward); UT_REGISTER_TEST(test_nufft_adjoint); -UT_REGISTER_TEST(test_nufft_normal); -UT_REGISTER_TEST(test_nufft_toeplitz_weights); -UT_REGISTER_TEST(test_nufft_toeplitz_noweights); -UT_REGISTER_TEST(test_nufft_basis_adjoint); -UT_REGISTER_TEST(test_nufft_basis_normal); -UT_REGISTER_TEST(test_nufft_basis_toeplitz);
Bug#1025691: atril: Segfault when opening a copy of a PDF document with annotations
Dear Maintainer, I could reproduce this issue by these steps: - installed a minimal test VM with `apt install systemd-coredump mc xdm xserver-xorg jwm xterm atril latexmk texlive-latex-extra gdb libatrilview3-dbgsym libgtk-3-0-dbgsym libglib2.0-0-dbgsym atril-dbgsym` - created the PDF by `latexmk -pdf test.latex` - open atril - open PDF - switch the sidebar from "Thumbnail" to "Annotations" - create a annotation - save the PDF - closed atril - opened atril - opened the saved PDF - then "Open a Copy" crashed it This crashed here: https://sources.debian.org/src/atril/1.26.0-2/libview/ev-view.c/#L2694 2691child = ev_view_get_window_child (view, window); 2692gdk_window_get_origin (gtk_widget_get_window (GTK_WIDGET (view)), 2693 _x, _y); 2694if (root_x != child->parent_x || root_y != child->parent_y) { 2695gint dest_x, dest_y; (gdb) bt full 4 #0 ev_view_window_child_move_with_parent (view=0x5637f6058560, window=0x5637f61ac330) at ./libview/ev-view.c:2694 child = 0x0 root_x = 613 root_y = 107 #1 0x7f5e6bdfbd9b in show_annotation_windows (page=0, view=0x5637f6058560) at ./libview/ev-view.c:2920 ... (rr) print view->window_children $2 = 0x0 The variable child still contains a null here, looks like because view->window_children is also a null. Unfortunately found no matching upstream entry in [1]. Kind regards, Bernhard [1] https://github.com/mate-desktop/atril/issues (gdb) bt #0 ev_view_window_child_move_with_parent (view=0x5637f6058560, window=0x5637f61ac330) at ./libview/ev-view.c:2694 #1 0x7f5e6bdfbd9b in show_annotation_windows (page=0, view=0x5637f6058560) at ./libview/ev-view.c:2920 #2 ev_view_draw (widget=0x5637f6058560, cr=0x5637f6066c00) at ./libview/ev-view.c:4078 #3 0x7f5e6b56efdc in gtk_widget_draw_internal (widget=widget@entry=0x5637f6058560, cr=cr@entry=0x5637f6066c00, clip_to_size=clip_to_size@entry=1) at ../../../gtk/gtkwidget.c:7084 #4 0x7f5e6b32119a in gtk_container_propagate_draw (container=, child=0x5637f6058560, cr=0x5637f6066c00) at ../../../gtk/gtkcontainer.c:3854 #5 0x7f5e6b3212fd in gtk_container_draw (widget=, cr=0x5637f6066c00) at ../../../gtk/gtkcontainer.c:3674 #6 0x7f5e6b497c5a in gtk_scrolled_window_render (gadget=, cr=0x5637f6066c00, x=, y=, width=, height=, data=0x0) at ../../../gtk/gtkscrolledwindow.c:2119 #7 0x7f5e6b326c8f in gtk_css_custom_gadget_draw (gadget=0x5637f6309600, cr=0x5637f6066c00, x=1, y=1, width=598, height=519) at ../../../gtk/gtkcsscustomgadget.c:159 #8 0x7f5e6b32c627 in gtk_css_gadget_draw (gadget=0x5637f6309600, cr=cr@entry=0x5637f6066c00) at ../../../gtk/gtkcssgadget.c:885 #9 0x7f5e6b49a60c in gtk_scrolled_window_draw (widget=0x5637f62bb460, cr=0x5637f6066c00) at ../../../gtk/gtkscrolledwindow.c:3050 #10 0x7f5e6b56efdc in gtk_widget_draw_internal (widget=widget@entry=0x5637f62bb460, cr=cr@entry=0x5637f6066c00, clip_to_size=clip_to_size@entry=1) at ../../../gtk/gtkwidget.c:7084 #11 0x7f5e6b32119a in gtk_container_propagate_draw (container=, child=0x5637f62bb460, cr=0x5637f6066c00) at ../../../gtk/gtkcontainer.c:3854 #12 0x7f5e6b3212fd in gtk_container_draw (widget=, cr=0x5637f6066c00) at ../../../gtk/gtkcontainer.c:3674 #13 0x7f5e6b56efdc in gtk_widget_draw_internal (widget=widget@entry=0x5637f63072a0, cr=cr@entry=0x5637f6066c00, clip_to_size=clip_to_size@entry=1) at ../../../gtk/gtkwidget.c:7084 #14 0x7f5e6b32119a in gtk_container_propagate_draw (container=, child=0x5637f63072a0, cr=0x5637f6066c00) at ../../../gtk/gtkcontainer.c:3854 #15 0x7f5e6b3212fd in gtk_container_draw (widget=, cr=cr@entry=0x5637f6066c00) at ../../../gtk/gtkcontainer.c:3674 #16 0x7f5e6b2cae96 in gtk_box_draw_contents (gadget=0x5637f6309400, cr=0x5637f6066c00, x=, y=, width=, height=, unused=0x0) at ../../../gtk/gtkbox.c:453 #17 0x7f5e6b326c8f in gtk_css_custom_gadget_draw (gadget=0x5637f6309400, cr=0x5637f6066c00, x=0, y=0, width=600, height=521) at ../../../gtk/gtkcsscustomgadget.c:159 #18 0x7f5e6b32c627 in gtk_css_gadget_draw (gadget=0x5637f6309400, cr=cr@entry=0x5637f6066c00) at ../../../gtk/gtkcssgadget.c:885 #19 0x7f5e6b2cdb5c in gtk_box_draw (widget=0x5637f629fe30, cr=0x5637f6066c00) at ../../../gtk/gtkbox.c:462 #20 0x7f5e6b56efdc in gtk_widget_draw_internal (widget=widget@entry=0x5637f629fe30, cr=cr@entry=0x5637f6066c00, clip_to_size=clip_to_size@entry=1) at ../../../gtk/gtkwidget.c:7084 #21 0x7f5e6b32119a in gtk_container_propagate_draw (container=, child=0x5637f629fe30, cr=0x5637f6066c00) at ../../../gtk/gtkcontainer.c:3854 #22 0x7f5e6b442ae1 in gtk_paned_render (gadget=, cr=0x5637f6066c00, x=, y=, width=, height=, data=0x0) at ../../../gtk/gtkpaned.c:1832 #23 0x7f5e6b326c8f in gtk_css_custom_gadget_draw (gadget=0x5637f62a4190, cr=0x5637f6066c00, x=0, y=0, width=600, height=521) at ../../../gtk/gtkcsscustomgadget.c:159 #24 0x7f5e6b32c627 in
Bug#1025702: gimp: Failed dum text editing
Dear Maintainer, this backtrace looks similar to the ones shown in these upstream bugs: https://gitlab.gnome.org/GNOME/gimp/-/issues/1891 (open) https://gitlab.gnome.org/GNOME/gimp/-/issues/3103 (closed) https://gitlab.gnome.org/GNOME/gimp/-/issues/6457 (closed) With the instructions in the last one I could quite fast reproduce this crash, showing the same backtrace. (See "Thread 1" below.) Seems in the end the function `g_str_hash` gets called with an unexpected null pointer. Kind regards, Bernhard LANG=C gimp - File - New - OK - Select Text tool in toolbox at the left - Click at the font selection button in the Text tools options at the middle left (opens the drop down list of fonts) - Click at one entry and drag it to the right (needs sometimes a few tries) ``` GNU Image Manipulation Program version 2.10.32 git-describe: GIMP_2_10_32 Build: unknown rev 0 for linux # C compiler # Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/12/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 12.2.0-7' --with-bugurl=file:///usr/share/doc/gcc-12/README.Bugs --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-12 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib --enable-libphobos-checking=release --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-werror --enable-cet --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none=/build/gcc-12-zpDQmA/gcc-12-12.2.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-12-zpDQmA/gcc-12-12.2.0/debian/tmp-gcn/usr --enable-offload-defaulted --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 12.2.0 (Debian 12.2.0-7) # Libraries # using babl version 0.1.98 (compiled against version 0.1.96) using GEGL version 0.4.38 (compiled against version 0.4.38) using GLib version 2.74.2 (compiled against version 2.74.1) using GdkPixbuf version 2.42.10 (compiled against version 2.42.9) using GTK+ version 2.24.33 (compiled against version 2.24.33) using Pango version 1.50.10 (compiled against version 1.50.10) using Fontconfig version 2.13.1 (compiled against version 2.13.1) using Cairo version 1.16.0 (compiled against version 1.16.0) ``` fatal error: Segmentation fault Stack trace: ``` # Stack traces obtained from PID 282910 - Thread 282910 # [New LWP 282911] [New LWP 282912] [New LWP 282913] [New LWP 282914] [New LWP 282915] [New LWP 282916] [New LWP 282917] [New LWP 282918] [New LWP 282919] [New LWP 282920] [New LWP 282921] [New LWP 282922] [New LWP 282923] [New LWP 282924] [New LWP 282925] [New LWP 282941] [New LWP 282942] [New LWP 282961] [New LWP 282962] [New LWP 283017] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". __GI___libc_read (nbytes=256, buf=0x7ffcd58a1e70, fd=15) at ../sysdeps/unix/sysv/linux/read.c:26 Id Target IdFrame * 1Thread 0x7f509bcedec0 (LWP 282910) "gimp"__GI___libc_read (nbytes=256, buf=0x7ffcd58a1e70, fd=15) at ../sysdeps/unix/sysv/linux/read.c:26 2Thread 0x7f509b1416c0 (LWP 282911) "worker" syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 3Thread 0x7f509a9406c0 (LWP 282912) "worker" syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 4Thread 0x7f509213f6c0 (LWP 282913) "worker" syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 5Thread 0x7f509a13f6c0 (LWP 282914) "worker" syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 6Thread 0x7f509993e6c0 (LWP 282915) "worker" syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 7Thread 0x7f509913d6c0 (LWP 282916) "worker" syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 8Thread 0x7f509893c6c0 (LWP 282917) "worker" syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 9Thread 0x7f5093fff6c0 (LWP 282918) "worker" syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 10 Thread 0x7f50937fe6c0 (LWP 282919) "worker" syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 11 Thread
Bug#1025698: fails to add windows boot loader entry to menu
I upgraded from 2.04-20 to 2.06-7, and after rebooting I discovered that I could no longer boot my Windows partition. Downgrading back to 2.04-20 solved this, so only the grub packages are causing this. The whole os-prober section is omitted with 2.06-7. This is what should be there (diff between working and new version): Hello Paul, is this issue what the NEWS [1] file notifies about, to check the need of GRUB_DISABLE_OS_PROBER? [1] https://sources.debian.org/src/grub2/2.06-7/debian/NEWS/ Kind regards, Bernhard