Segfault when calling (Cancelable)Lock.unlock?

Sebastian Sumpf Sebastian.Sumpf at ...1...
Tue Aug 30 16:05:35 CEST 2016


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





More information about the users mailing list