[CRIU] Restoring failed on ARMv7

[Christopher Covington]

On 11/02/2015 10:59 AM, Pavel Emelyanov wrote:
> On 10/30/2015 05:48 PM, Artem Kuzmitskiy wrote:
>>
>>
>> 2015-10-30 16:33 GMT+03:00 Pavel Emelyanov <xemul at parallels.com <mailto:xemul at parallels.com>>:
>>
>>     On 10/30/2015 04:17 PM, Artem Kuzmitskiy wrote:
>>     >
>>     >
>>     > 2015-10-30 12:52 GMT+03:00 Pavel Emelyanov <xemul at parallels.com <mailto:xemul at parallels.com> <mailto:xemul at parallels.com <mailto:xemul at parallels.com>>>:
>>     >
>>     >     On 10/30/2015 12:38 PM, Artem Kuzmitskiy wrote:
>>     >     > Hi all,
>>     >     >
>>     >     > I checked criu on armv7 with 3.16 kernel and got next error when restoring:
>>     >     > ....
>>     >     > (00.087176)   6034: task_args: 0xd6000
>>     >     > task_args->pid: 6034
>>     >     > task_args->nr_threads: 1
>>     >     > task_args->clone_restore_fn: 0xd1c90
>>     >     > task_args->thread_args: 0xd62c0
>>     >     > pie: Switched to the restorer 6034
>>     >     > pie: Error (pie/restorer.c:772): Unable to unmap (-): 1992687616
>>     >
>>     >     Ouch, the pie logging is ... not complete :) Can you strace the restoring
>>     >     to see what's going on with this syscall?
>>     >
>>     >
>>     > Strace log (command -strace criu restore -d -D images -o restore.log -v4 --shell-job -t 11758)
>>
>>     Plz, add -f option to strace, the subtasks syscalls are of the main interest.
> 
> I see no failed munmap-s in the strace below. And this part
> 
>> clone(Process 4820 attached
>> child_stack=0x7e894b00, flags=SIGCHLD) = 4820
>> [pid  5387] gettimeofday({1446215777, 101923}, NULL) = 0
>> [pid  5387] write(1023, "(00.031539) PID: real 4820 virt "..., 37) = 37
>> [pid  5387] flock(3, LOCK_UN)           = 0
>> [pid  5387] close(3)                    = 0
>> [pid  5387] gettimeofday({1446215777, 103520}, NULL) = 0
>> [pid  5387] write(1023, "(00.033136) Wait until namespace"..., 46) = 46
>> [pid  5387] futex(0x76f7a010, FUTEX_WAIT, 1, NULL

>> syscall: unknown syscall trap 0x0f000000

I overlooked this before. Is that a syscall number? What syscall is that
supposed to be? Could there be a criu vs kernel or libc vs kernel feature
mismatch?

Christopher Covington

-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project