> This is not good. Signal number 4 corresponds to SIGILL (at least on my > system). Is it possible for you to debug which instruction causes this e.g.
This is not _easily_ reproducible. I have the core file. For me too, it is SIGILL and syscall refers to compat_sys_futex (@using MIPS). > with ipsec start --attach-gdb, provided that it is actually reproducible? I generally attach charon to gdb after launching gdb. 0x2acc0de0 <__lll_lock_wait+120>: 0x7c03e83b 0x2acc0de4 <__lll_lock_wait+124>: lw a1,-29800(v1) 0x2acc0de8 <__lll_lock_wait+128>: li a2,2 0x2acc0dec <__lll_lock_wait+132>: and a1,s2,a1 0x2acc0df0 <__lll_lock_wait+136>: move a3,zero 0x2acc0df4 <__lll_lock_wait+140>: li v0,4238 0x2acc0df8 <__lll_lock_wait+144>: syscall 0x2acc0dfc <__lll_lock_wait+148>: move v0,zero 0x2acc0e00 <__lll_lock_wait+152>: ll a0,0(s1) 0x2acc0e04 <__lll_lock_wait+156>: bne a0,v0,0x2acc0e20 <__lll_lock_wait+184> Can we rely the following. In gdb the crashed thread is different from printed value? DBG1(DBG_DMN, "thread %u received %d", thread_current_id(), signal); ~Bharat _______________________________________________ Dev mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/dev
