[CRIU] ARM: SIGSEGV in parasite code

[Chanho Park]

> A new idea has come to me recently: we break stack alignment in an odd-
> argument syscall wrapper that may be fatal for some ARM platforms. Could
> you please do the following:
> 
> * reproduce the issue with the attached patch applied;
> * reproduce the issue with with optimization disabled (compile
>     crtools with the DEBUG=1 environment variable)?

I attached new coredump and parasite blobs built with DEBUG=1 option.
This core dump shows a different point to me.
It seems the fault didn't occur caused by any syscalls.

(gdb) bt
#0  0xb6f0c374 in ?? ()
#1  0xb6f0c83c in ?? ()
#2  0xb6f0c83c in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) x /10i $pc - 32
   0xb6f0c354:	ldr	r3, [r11, #-16]
   0xb6f0c358:	ldr	r3, [r3, #16]
   0xb6f0c35c:	b	0xb6f0c364
   0xb6f0c360:	mov	r3, #0
   0xb6f0c364:	str	r3, [r11, #-8]
   0xb6f0c368:	ldr	r3, [r11, #-16]
   0xb6f0c36c:	ldr	r2, [r3, #20]
   0xb6f0c370:	ldr	r3, [r11, #-8]
=> 0xb6f0c374:	str	r2, [r3]
   0xb6f0c378:	ldr	r3, [r11, #-8]
(gdb) i r
r0             0xb6f0d868	3069237352
r1             0x0	0
r2             0x0	0
r3             0x0	0
r4             0x0	0
r5             0x6c000	442368
r6             0xbea85b80	3198704512
r7             0xbea85b60	3198704480
r8             0x0	0
r9             0x0	0
r10            0x0	0
r11            0xb6f0d84c	3069237324
r12            0x0	0
sp             0xb6f0d830	0xb6f0d830
lr             0xb6f0c83c	-1225734084
pc             0xb6f0c374	0xb6f0c374
cpsr           0x60000010	1610612752

0000220c <scm_fdset_init_chunk>:
    220c:	e52db004 	push	{fp}		; (str fp, [sp,
#-4]!)
    2210:	e28db000 	add	fp, sp, #0
    2214:	e24dd014 	sub	sp, sp, #20
    2218:	e50b0010 	str	r0, [fp, #-16]
    221c:	e50b1014 	str	r1, [fp, #-20]
    2220:	e51b3014 	ldr	r3, [fp, #-20]
    2224:	e2833003 	add	r3, r3, #3
    2228:	e1a02103 	lsl	r2, r3, #2
    222c:	e51b3010 	ldr	r3, [fp, #-16]
    2230:	e5832014 	str	r2, [r3, #20]
    2234:	e51b3010 	ldr	r3, [fp, #-16]
    2238:	e5933014 	ldr	r3, [r3, #20]
    223c:	e353000b 	cmp	r3, #11
    2240:	9a000002 	bls	2250 <scm_fdset_init_chunk+0x44>
    2244:	e51b3010 	ldr	r3, [fp, #-16]
    2248:	e5933010 	ldr	r3, [r3, #16]
    224c:	ea000000 	b	2254 <scm_fdset_init_chunk+0x48>
    2250:	e3a03000 	mov	r3, #0
    2254:	e50b3008 	str	r3, [fp, #-8]
    2258:	e51b3010 	ldr	r3, [fp, #-16]
    225c:	e5932014 	ldr	r2, [r3, #20]
    2260:	e51b3008 	ldr	r3, [fp, #-8]
    2264:	e5832000 	str	r2, [r3]           <--------------
FAULT
    2268:	e28bd000 	add	sp, fp, #0
    226c:	e8bd0800 	pop	{fp}
    2270:	e12fff1e 	bx	lr

Best regards,
Chanho Park
-------------- next part --------------
A non-text attachment was scrubbed...
Name: core
Type: application/octet-stream
Size: 708608 bytes
Desc: not available
URL: <http://lists.openvz.org/pipermail/criu/attachments/20130613/13f8bf69/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: parasite.built-in.bin.o
Type: application/octet-stream
Size: 51575 bytes
Desc: not available
URL: <http://lists.openvz.org/pipermail/criu/attachments/20130613/13f8bf69/attachment-0001.o>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dump.log
Type: application/octet-stream
Size: 4424 bytes
Desc: not available
URL: <http://lists.openvz.org/pipermail/criu/attachments/20130613/13f8bf69/attachment-0003.obj>