Date: Wed, 13 Nov 2024 12:29:47 +0000 From: bugzilla-noreply@freebsd.org To: ports-bugs@FreeBSD.org Subject: [Bug 282727] science/pulseview: crash on startup Message-ID: <bug-282727-7788@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D282727 Bug ID: 282727 Summary: science/pulseview: crash on startup Product: Ports & Packages Version: Latest Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: Individual Port(s) Assignee: ports-bugs@FreeBSD.org Reporter: avg@FreeBSD.org Created attachment 255136 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D255136&action= =3Dedit science/pulseview/files/patch-pv_data_decodesignal.cpp pulseview crashes for me "SIGILL, Illegal instruction" which caused by ud2 machine code instruction which is apparently inserted as an assertion. The crash is in std::__1::mutex::unlock: #0 std::__1::mutex::unlock (this=3D<optimized out>) at /usr/home/avg/devel/freebsd-src-new/machines/trant/contrib/llvm-project/lib= cxx/src/mutex.cpp:39 #1 0x0000000000368741 in ??? () ... (gdb) disassemble=20 Dump of assembler code for function _ZNSt3__15mutex6unlockEv: 0x0000000829ea35a0 <+0>: push %rbp 0x0000000829ea35a1 <+1>: mov %rsp,%rbp 0x0000000829ea35a4 <+4>: call 0x829eb22b0 <pthread_mutex_unlock@pl= t> 0x0000000829ea35a9 <+9>: test %eax,%eax 0x0000000829ea35ab <+11>: jne 0x829ea35af <_ZNSt3__15mutex6unlockEv+15> 0x0000000829ea35ad <+13>: pop %rbp 0x0000000829ea35ae <+14>: ret =3D> 0x0000000829ea35af <+15>: ud2 0x0000000829ea35b1 <+17>: mov %rax,%rdi 0x0000000829ea35b4 <+20>: call 0x829e52930 <__clang_call_terminate> End of assembler dump. Looks like ud2 is executed when pthread_mutex_unlock fails. The rest of the stack is not really useful because the program is built wit= hout debug symbols. But with some manual disassembling I was able to determine that the crash happens in DecodeSignal::resume_decode() method. And, indeed, looking at the code we can see that the function unlocks decode_pause_mutex_ which is never locked. Probably, I see this problem because I have a custom build of FreeBSD stabl= e/14 with asserts enabled, otherwise pthread_mutex_unlock status would be ignore= d. The attached patch fixes the problem for me. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-282727-7788>