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