Segfault when calling (Cancelable)Lock.unlock?

[Sebastian Sumpf]

Hi Menno,

On 08/30/2016 03:43 PM, Menno Valkema wrote:
> Hi Everyone,
> 
> I'm currently using a Nic_connection to exchange data data between
> components on linux_x86.
> 
> Before sending data from the Nic server I first check whether any data
> can be freed. Even before the first packet is send out, using the code
> below:
> 
> while ( _rx.source()->ack_avail() )
> {
>   _rx.source()->release_packet( _rx.source()->get_acked_packet() );
> }
> 
> 
> Whenever I'm sending data out from an extern "C" method (callback passed
> to a c library), the application crashes. Looking with GDB, the
> issues seems to be with the destructor of the lock guard from the code
> from packet_stream.h (full GDB output at the bottom of this email).
> 
> bool ready_for_rx()
> {
> 	Genode::Lock::Guard lock_guard(_rx_queue_lock);
> 	return !_rx_queue->empty();
> }
> 
> The destructor of the Guard simply calls the unlock method for the lock.
> However this crashes. Could it be that the unlock method throws an
> exception in the destructor, or that there might be uninitialized
> variables within the lock itself?
> 
> I'm sort of lost here, because I've used the Nic_connection in similar
> settings in the past (also called from an extern "C" context as a c code
> callback). However this time it consistently breaks, whenever I try to
> sent out the first packet from an extern "c" context (it does work when
> sending the packet out from normal c++ code.
> 
> Any suggestions what might causes the crash in my application?
> 
> Cheers, Menno
> 
> 
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x0000000001143c22 in ~Lock_guard (this=<optimized out>,
> __in_chrg=<optimized out>)
>     at <project-path...>/repos/base/include/base/lock_guard.h:42
> 42			~Lock_guard() { _lock.unlock(); }
> (gdb) bt
> #0  0x0000000001143c22 in ~Lock_guard (this=<optimized out>,
> __in_chrg=<optimized out>)
>     at <project-path...>/repos/base/include/base/lock_guard.h:42
> #1  ready_for_rx (this=<optimized out>) at
> <project-path...>/repos/os/include/os/packet_stream.h:400
> #2  ack_avail (this=<optimized out>) at
> <project-path...>/repos/os/include/os/packet_stream.h:686
> 

You could check the address of _lock in the constructor of Lock_guard
and also in the destructor. It might be stack corruption. In case the
address remains the same, is it the same as the segmentation fault address?

Cheers,

Sebastian