[CRIU] ARM: SIGSEGV in parasite code

[Chanho Park]

> Thank you for this dump. I suspect a kernel stack corruption.
> Please verify my findings.
> 
> (gdb) i r
> r0             0xffffffff    4294967295
> r1             0xb6fa749c    3069867164
> r2             0x0    0
> r3             0x10    16
> r4             0x0    0
> r5             0x0    0
> r6             0x0    0
> r7             0x0    0
> r8             0x0    0
> r9             0x0    0
> r10            0x0    0
> r11            0x0    0
> r12            0xb6fa9060    3069874272
> sp             0xb6fa9088    0xb6fa9088
> lr             0xb6fa46bc    -1225111876
> pc             0x0    0
> cpsr           0x60000010    1610612752
> 
> 
> The suspicious thing is that the PC register is zero. Let's analyze the
> code pointed by the LR register:
> 
> (gdb) x /3i $lr - 8
>     0xb6fa46b4:    mov    r2, #0
>     0xb6fa46b8:    bl    0xb6fa4b20
>     0xb6fa46bc:    cmp    r0, #0
> 
> Analyzing the code at 0xb6fa4b20:
> 
> (gdb) x /10i 0xb6fa4b20
>     0xb6fa4b20:    push    {r7}
>     0xb6fa4b24:    movw    r7, #297    ; 0x129
>     0xb6fa4b28:    svc    0x00000000
>     0xb6fa4b2c:    pop    {r7}
>     0xb6fa4b30:    bx    lr
> 
> This is the parasite wrapper for the syscall recvmsg().
> It seems the kernel restored the register PC incorrectly.
> 
> By the way I'm unable to explain the following mysteries:
> 
> * the value of the register R1 is surely a struct msghdr*
>     but other registers are clobbered. The most suspicious
>     register is R0 that contain 0xffffffff that is probably
>     the result of our mismanipulation with ARM_ORIG_r0.
> 
> * The following line in the second log:
> 
>     pie: __sent ack msg: -1225390624 -1225390624 0
> 
>     is totally incomprehensible.
> 
> Could you please apply the attached patch and report whether it helps to
> cope with the spurious SEGFAULT's?

Unfortunately, I got similar problem even though applied your patch.
I think it crashed after sys_sendto(). Please look into attached coredump.

(gdb) bt
#0  0xb6f53084 in ?? ()
Cannot access memory at address 0x0
#1  0xb6f531c8 in ?? ()
Cannot access memory at address 0x0
#2  0xb6f531c8 in ?? ()
Cannot access memory at address 0x0
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) i r
r0             0x4	4
r1             0xb6f57424	3069539364
r2             0xc	12
r3             0x0	0
r4             0x0	0
r5             0x0	0
r6             0xbea98b80	3198782336
r7             0xbea98b60	3198782304
r8             0x0	0
r9             0x0	0
r10            0x0	0
r11            0x0	0
r12            0x3	3
sp             0xb6f57418	0xb6f57418
lr             0xb6f531c8	-1225444920
pc             0xb6f53084	0xb6f53084
cpsr           0x20000010	536870928
(gdb) x /10i $pc - 32
   0xb6f53064:	str	r4, [sp, #4]
   0xb6f53068:	bl	0xb6f54a60
   0xb6f5306c:	cmp	r0, #12
   0xb6f53070:	mov	r12, r0
   0xb6f53074:	bne	0xb6f530a0
   0xb6f53078:	add	r2, sp, #12
   0xb6f5307c:	ldr	r1, [pc, #80]	; 0xb6f530d4
   0xb6f53080:	mov	r0, #4
=> 0xb6f53084:	ldm	r2, {r2, r3, r12}
   0xb6f53088:	add	r1, pc, r1

-> from parasite.built-in.o
34:	e58d4004 	str	r4, [sp, #4]
      38:	ebfffffe 	bl	1a30 <sys_sendto>
      3c:	e350000c 	cmp	r0, #12
      40:	e1a0c000 	mov	ip, r0
      44:	1a000009 	bne	70
<__parasite_daemon_reply_ack+0x70>
      48:	e28d200c 	add	r2, sp, #12
      4c:	e59f1050 	ldr	r1, [pc, #80]	; a4
<__parasite_daemon_reply_ack+0xa4>
      50:	e3a00004 	mov	r0, #4
      54:	e892100c 	ldm	r2, {r2, r3, ip}


Anyway, I also tried the same test using my pandaboard(omap4).
Unfortunately, the result was same.
Please show your environment.
Thanks.

Best Regards,
Chanho Park
-------------- next part --------------
A non-text attachment was scrubbed...
Name: core
Type: application/octet-stream
Size: 704512 bytes
Desc: not available
URL: <http://lists.openvz.org/pipermail/criu/attachments/20130613/25a55d9a/attachment-0003.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dump.log
Type: application/octet-stream
Size: 4450 bytes
Desc: not available
URL: <http://lists.openvz.org/pipermail/criu/attachments/20130613/25a55d9a/attachment-0004.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test_test
Type: application/octet-stream
Size: 451713 bytes
Desc: not available
URL: <http://lists.openvz.org/pipermail/criu/attachments/20130613/25a55d9a/attachment-0005.obj>