<div dir="ltr"><div>Hi,</div><div><br></div><div>I see a problem with some crashes we have seen under load (and tunnels going up and down). I am using strongswan 5.1.3, running on a 64bit ubuntu server. The crash is not consistently reproduced and the stack shows different places of crash.</div><div>But I see a pattern for all crashes. It seems that certain pointers point to objects that have shifted by 8 bytes. I have listed two such examples here. One thing we also noticed is that the frequency of the</div><div>crash went down when we reduced logging to 0. Has anyone seen a similar problem? Could a copy or clone function be misbehaving by copying one word after?</div><div><br></div><div>EXAMPLE 1:</div><div>the job_t pointer was as follows (from the crash)</div><div>(gdb) p *(job_t *) 0x7feca438a760</div><div>$13 = {status = 3064964496, execute = 0, cancel = 0x7fecb6afa680 <get_priority>, get_priority = 0x7fecb6afa710 <destroy>, destroy = 0x7feca435cb30}</div><div><br></div><div>When i shifted the pointer by 8, I get</div><div>(gdb) p *(job_t *) (0x7feca438a760 - 8)</div><div>$14 = {status = JOB_STATUS_QUEUED, execute = 0x7fecb6afa590 <execute>, cancel = 0, get_priority = 0x7fecb6afa680 <get_priority>, destroy = 0x7fecb6afa710 <destroy>}</div><div><br></div><div>So, when the function queue_job was trying to get the priority of a job by calling get_priority on the job_t pointer, it ended up calling destroy and crashing.</div><div>The stack trace is </div><div>(gdb) bt</div><div>#0  0x00007fecb60dd845 in *__GI_raise (sig=<value optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64</div><div>#1  0x00007fecb60e1390 in *__GI_abort () at abort.c:92</div><div>#2  0x00000000004014f3 in segv_handler (signal=11) at charon.c:196</div><div>#3  <signal handler called></div><div>#4  0x00007fecb6afa71b in destroy (this=0x7feca438a760) at processing/jobs/rekey_ike_sa_job.c:45</div><div>#5  0x00007fecb6f7f4df in queue_job (this=0xf174b0, job=0x7feca438a760) at processing/processor.c:395</div><div>#6  0x00007fecb6f803cf in schedule (this=0xf17a60) at processing/scheduler.c:197</div><div>#7  0x00007fecb6f7f26e in execute (this=0x1) at processing/jobs/callback_job.c:77</div><div>#8  0x00007fecb6f7fca9 in process_job (worker=0xf4eec0) at processing/processor.c:235</div><div>#9  process_jobs (worker=0xf4eec0) at processing/processor.c:321</div><div>#10 0x00007fecb6f83007 in thread_main (this=<value optimized out>) at threading/thread.c:309</div><div>#11 0x00007fecb663d9ca in start_thread (arg=<value optimized out>) at pthread_create.c:300</div><div>#12 0x00007fecb619545d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112</div><div>#13 0x0000000000000000 in ?? ()</div><div><br></div><div><br></div><div>EXAMPLE 2:</div><div>SIMILARLY, another core had this problem with private_traffic_selector_t. When it tried to destroy the traffic selector, it ended up calling invalid memory.</div><div>(gdb) p *(private_traffic_selector_t *)0x7fdb44c43eb0</div><div>$3 = {public = {get_subset = 0x7fdb598965e0 <clone_>, clone = 0x7fdb59896370 <get_from_address>, get_from_address = 0x7fdb598963b0 <get_to_address>,</div><div>    get_to_address = 0x7fdb598963f0 <get_from_port>, get_from_port = 0x7fdb59896400 <get_to_port>, get_to_port = 0x7fdb59896410 <get_type>,</div><div>    get_type = 0x7fdb59896420 <get_protocol>, get_protocol = 0x7fdb59896900 <is_host>, is_host = 0x7fdb59896430 <is_dynamic>, is_dynamic = 0x7fdb59896e30 <set_address>,</div><div>    set_address = 0x7fdb59896850 <equals>, equals = 0x7fdb59896c20 <is_contained_in>, is_contained_in = 0x7fdb59896790 <includes>, includes = 0x7fdb59896ce0 <to_subnet>,</div><div>    to_subnet = 0x7fdb598965d0 <destroy>, destroy = 0x20000000000007}, type = 1040435210, protocol = 0 '\000', dynamic = false, netbits = 0 '\000', {</div><div>    from = 0x7fdb44c43eb0 "\340e\211Y\333\177", from4 = {0}, from6 = {0, 0, 1040435210, 0}}, {to = 0x7fdb44c43eb0 "\340e\211Y\333\177", to4 = {0}, to6 = {0, 0, 4294901760,</div><div>      0}}, from_port = 192, to_port = 0}</div><div><br></div><div>(gdb) p *(private_traffic_selector_t *)(0x7fdb44c43eb0-8)</div><div>$4 = {public = {get_subset = 0x7fdb598969f0 <get_subset>, clone = 0x7fdb598965e0 <clone_>, get_from_address = 0x7fdb59896370 <get_from_address>,</div><div>    get_to_address = 0x7fdb598963b0 <get_to_address>, get_from_port = 0x7fdb598963f0 <get_from_port>, get_to_port = 0x7fdb59896400 <get_to_port>,</div><div>    get_type = 0x7fdb59896410 <get_type>, get_protocol = 0x7fdb59896420 <get_protocol>, is_host = 0x7fdb59896900 <is_host>, is_dynamic = 0x7fdb59896430 <is_dynamic>,</div><div>    set_address = 0x7fdb59896e30 <set_address>, equals = 0x7fdb59896850 <equals>, is_contained_in = 0x7fdb59896c20 <is_contained_in>, includes = 0x7fdb59896790 <includes>,</div><div>    to_subnet = 0x7fdb59896ce0 <to_subnet>, destroy = 0x7fdb598965d0 <destroy>}, type = TS_IPV4_ADDR_RANGE, protocol = 0 '\000', dynamic = false, netbits = 32 ' ', {</div><div>    from = 0x7fdb44c43ea8 "\360i\211Y\333\177", from4 = {1040435210}, from6 = {1040435210, 0, 0, 0}}, {to = 0x7fdb44c43ea8 "\360i\211Y\333\177", to4 = {1040435210}, to6 = {</div><div>      1040435210, 0, 0, 0}}, from_port = 0, to_port = 65535}</div><div><br></div><div>Stack trace for this core:</div><div>#0  0x00007fdb589f2845 in *__GI_raise (sig=<value optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64</div><div>#1  0x00007fdb589f6390 in *__GI_abort () at abort.c:92</div><div>#2  0x00000000004014f3 in segv_handler (signal=11) at charon.c:196</div><div>#3  <signal handler called></div><div>#4  array_invoke_offset (array=0x7fdb345d21c0, offset=120) at collections/array.c:531</div><div>#5  0x00007fdb5987ddc9 in array_destroy_offset (array=0x7fdb44c43eb0, offset=120) at collections/array.c:553</div><div>#6  0x00007fdb59411d88 in destroy (this=0x7fdb34b71f70) at sa/child_sa.c:1108</div><div>#7  0x00007fdb59414b83 in destroy_child_sa (this=0x7fdb2cbadcc0, protocol=<value optimized out>, spi=621215179) at sa/ike_sa.c:1441</div><div>#8  0x00007fdb59442d15 in delete_child (this=0x7fdb3cd20a20, protocol=<value optimized out>, spi=621215179, remote_close=<value optimized out>)</div><div>    at sa/ikev1/tasks/quick_delete.c:145</div><div>#9  0x00007fdb59443000 in delete_child (this=0x7fdb4ea5bb10, protocol=<value optimized out>, spi=1319484188, remote_close=<value optimized out>)</div><div>    at sa/ikev1/tasks/quick_delete.c:105</div><div>#10 0x000000007f19ff1b in ?? ()</div><div>#11 0x0000000000603190 in stderr@@GLIBC_2.2.5 ()</div><div>#12 0x0000000000000000 in ?? ()</div><div><br></div><div>anyone seen this before?</div><div><br></div><div>regards,</div><div>sk</div></div>