[Bug 282727] science/pulseview: crash on startup

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282727

            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=255136&action=edit
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=<optimized out>) at
/usr/home/avg/devel/freebsd-src-new/machines/trant/contrib/llvm-project/libcxx/src/mutex.cpp:39
#1  0x0000000000368741 in ??? ()
...

(gdb) disassemble 
Dump of assembler code for function _ZNSt3__15mutex6unlockEv:
   0x0000000829ea35a0 <+0>:     push   %rbp
   0x0000000829ea35a1 <+1>:     mov    %rsp,%rbp
   0x0000000829ea35a4 <+4>:     call   0x829eb22b0 <pthread_mutex_unlock@plt>
   0x0000000829ea35a9 <+9>:     test   %eax,%eax
   0x0000000829ea35ab <+11>:    jne    0x829ea35af
<_ZNSt3__15mutex6unlockEv+15>
   0x0000000829ea35ad <+13>:    pop    %rbp
   0x0000000829ea35ae <+14>:    ret
=> 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 without
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 stable/14
with asserts enabled, otherwise pthread_mutex_unlock status would be ignored.

The attached patch fixes the problem for me.

-- 
You are receiving this mail because:
You are the assignee for the bug.