[strongSwan] Charon reset

Mon Mar 9 15:12:53 CET 2015

Hi Martin,

I reran the test.  The initiator received signal 6 (SIGABRT) after eight hours of operation.  I have a ~182MB core file from the initiator.  How can I get it to you?

Below is a stack trace & thread info.

Ken

Core was generated by `/usr/libexec/strongswan/charon --use-syslog'.
Program terminated with signal 6, Aborted.
#0  0x00007f5e62e4c625 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
64   return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);
Missing separate debuginfos, use: debuginfo-install libidn-1.18-2.el6.x86_64
(gdb) bt
#0  0x00007f5e62e4c625 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0x00007f5e62e4de05 in abort () at abort.c:92
#2  0x0000000000401393 in segv_handler (signal=11) at charon.c:199
#3  <signal handler called>
#4  0x0000000000d30fe0 in ?? ()
#5  0x00007f5e63cf48ac in certs_filter (data=0x7f5e280033e0, in=0x7f5e50c6caf8, out=0x7f5e50c6cba8)
    at credentials/sets/mem_cred.c:93
#6  0x00007f5e63ce6a55 in enumerate_filter (this=0x7f5e28003000, o1=0x7f5e50c6cba8, o2=0x7f5e63ce6ce0, o3=0x40,
    o4=0x7f5e28000088, o5=0x1) at collections/enumerator.c:525
#7  0x00007f5e63ce6953 in enumerate_nested (this=0x7f5e280033a0, v1=0x7f5e50c6cba8, v2=0x7f5e63ce6ce0, v3=0x40,
    v4=0x7f5e28000088, v5=0x1) at collections/enumerator.c:448
#8  0x00007f5e63cf35c0 in get_cert (this=<value optimized out>, cert=<value optimized out>, key=<value optimized out>,
    id=<value optimized out>, trusted=<value optimized out>) at credentials/credential_manager.c:269
#9  0x00007f5e63890535 in process_certreq (this=0x7f5e34001040, message=<value optimized out>)
    at sa/ikev2/tasks/ike_cert_pre.c:85
#10 process_certreqs (this=0x7f5e34001040, message=<value optimized out>) at sa/ikev2/tasks/ike_cert_pre.c:142
#11 0x00007f5e63890acb in process_i (this=0x7f5e34001040, message=0x7f5e44000ff0) at sa/ikev2/tasks/ike_cert_pre.c:524
#12 0x00007f5e63886bce in process_response (this=0x7f5e34000b20, msg=0x7f5e44000ff0) at sa/ikev2/task_manager_v2.c:538
#13 process_message (this=0x7f5e34000b20, msg=0x7f5e44000ff0) at sa/ikev2/task_manager_v2.c:1217
#14 0x00007f5e6387a9e7 in process_message (this=0x7f5e340031a0, message=0x7f5e44000ff0) at sa/ike_sa.c:1268
#15 0x00007f5e63875d17 in execute (this=0x7f5e44000fb0) at processing/jobs/process_message_job.c:74
#16 0x00007f5e63cfe079 in process_job (worker=0xd2cde0) at processing/processor.c:235
#17 process_jobs (worker=0xd2cde0) at processing/processor.c:321
#18 0x00007f5e63d0e18e in thread_main (this=0xd2ce10) at threading/thread.c:312
#19 0x00007f5e633b99d1 in start_thread (arg=0x7f5e50c6d700) at pthread_create.c:301
#20 0x00007f5e62f029dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115
(gdb) info threads
  18 Thread 0x7f5e5166e700 (LWP 22573)  pthread_cond_wait@@GLIBC_2.3.2 ()
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:183
  17 Thread 0x7f5e5206f700 (LWP 22572)  pthread_cond_wait@@GLIBC_2.3.2 ()
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:183
  16 Thread 0x7f5e52a70700 (LWP 22571)  pthread_cond_wait@@GLIBC_2.3.2 ()
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:183
  15 Thread 0x7f5e53471700 (LWP 22570)  pthread_cond_wait@@GLIBC_2.3.2 ()
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:183
  14 Thread 0x7f5e53e72700 (LWP 22569)  pthread_cond_wait@@GLIBC_2.3.2 ()
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:183
  13 Thread 0x7f5e54873700 (LWP 22568)  pthread_cond_wait@@GLIBC_2.3.2 ()
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:183
  12 Thread 0x7f5e55274700 (LWP 22567)  0x00007f5e62efb453 in select () at ../sysdeps/unix/syscall-template.S:82
  11 Thread 0x7f5e55c75700 (LWP 22566)  0x00007f5e62efb453 in select () at ../sysdeps/unix/syscall-template.S:82
  10 Thread 0x7f5e56676700 (LWP 22565)  pthread_cond_timedwait@@GLIBC_2.3.2 ()
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:239
  9 Thread 0x7f5e57077700 (LWP 22564)  pthread_cond_wait@@GLIBC_2.3.2 ()
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:183
  8 Thread 0x7f5e57a78700 (LWP 22563)  pthread_cond_wait@@GLIBC_2.3.2 ()
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:183
  7 Thread 0x7f5e58479700 (LWP 22562)  pthread_cond_wait@@GLIBC_2.3.2 ()
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:183
  6 Thread 0x7f5e64138700 (LWP 22561)  do_sigwait (set=<value optimized out>, sig=0x7fffe6549518)
    at ../sysdeps/unix/sysv/linux/sigwait.c:65
  5 Thread 0x7f5e4e469700 (LWP 26434)  pthread_cond_timedwait@@GLIBC_2.3.2 ()
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:239
  4 Thread 0x7f5e4ee6a700 (LWP 22577)  pthread_cond_wait@@GLIBC_2.3.2 ()
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:183
  3 Thread 0x7f5e4f86b700 (LWP 22576)  pthread_cond_wait@@GLIBC_2.3.2 ()
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:183
  2 Thread 0x7f5e5026c700 (LWP 22575)  pthread_cond_wait@@GLIBC_2.3.2 ()
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:183
* 1 Thread 0x7f5e50c6d700 (LWP 22574)  0x00007f5e62e4c625 in raise (sig=6)
    at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
(gdb)

On Mar 6, 2015, at 6:39 AM, Martin Willi <martin at strongswan.org<mailto:martin at strongswan.org>> wrote:

Hi Ken,

09[DMN] thread 9 received 11
09[LIB]  dumping 2 stack frame addresses:
09[LIB]   /lib64/libpthread.so.0 @ 0x7fb8fd3ab000 [0x7fb8fd3ba710]
09[LIB]     -> sigaction.c:0
09[LIB]   /lib64/libc.so.6 @ 0x7fb8fce13000 [0x7fb8fd1a2ed8]
09[LIB]     -> interp.c:0
09[DMN] killing ourself, received critical signal

Hard to say what exactly causes this, the backtrace does not provide
much information. Unlikely that this is actually raised from interp.c.

Is there any other data I could retrieve?  If I rerun the test, is
there any other debugging to enable?

A sane backtrace from gdb could certainly help. Either make sure to
create a core file on crashes for later evaluation, or attach a debugger
to charon while it is running.

Regards
Martin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20150309/0a2d2505/attachment-0001.html>