Project

General

Profile

Actions

Bug #3318

open

Segmenation fault when a process resumed with checkpt exits

Added by zabolekar 2 months ago. Updated 2 months ago.

Status:
In Progress
Priority:
Normal
Assignee:
Category:
-
Target version:
Start date:
06/12/2022
Due date:
% Done:

0%

Estimated time:

Description

DragonFly version: 6.2.1

Code example (error handling omitted for brevity):

#include <stdlib.h>
#include <fcntl.h>
#include <unistd.h>
#include <sys/checkpoint.h>

void save(const char* filename)
{
    int file = open(filename, O_RDWR|O_CREAT|O_TRUNC, 0666);
    sys_checkpoint(CKPT_FREEZE, file, -1, -1);
    close(file);
}

int main()
{
    puts("a");
    save("a.ckpt");
    puts("b");
}

Expected output:

% gcc test.c -o test -Wall -Wextra
% ./test
a
b
% checkpt -r a.ckpt
b

Actual output:

% gcc test.c -o test -Wall -Wextra
% ./test
a
b
% checkpt -r a.ckpt
b
pid 1143 (test), uid 1001: exited on signal 11 (core dumped)
Segmentation fault (core dumped)

Backtrace with gdb test test.core:

#0  0x000000080040400f in __tls_get_addr () from /libexec/ld-elf.so.2
#1  0x000000080075648a in _thread_finalize () from /lib/libc.so.8
#2  0x0000000800756449 in exit () from /lib/libc.so.8
#3  0x00000000004007b3 in _start ()

See also: https://lists.dragonflybsd.org/pipermail/users/2022-June/405002.html

Actions #1

Updated by tuxillo 2 months ago

  • Status changed from New to In Progress
  • Assignee set to tuxillo
  • Target version set to 6.4

Back in the day we added two memory mappable devices (/dev/upmap and /dev/kpmap) which provide certain data from the kernel without the need of a system call. See 0adbcbd6bc12ddb.
One is per-thread and the other isn't.

The thing is that we need to add handling for the one which isn't per-thread, since sys_checkpoint(2) and checkpt(1) does not support threaded programs, as stated in the manpage:

Threaded programs cannot currently be checkpointed. The program must be reduced to a single thread before it can be safely checkpointed.

See: https://man.dragonflybsd.org/?command=sys_checkpoint

We'll try t at least handle that case but we're also considering how useful process checkpointing really is. If anybody has any feedback about it now it would be the time to share it :-)

Actions #2

Updated by zabolekar 2 months ago

tuxillo wrote in #note-1:

We'll try t at least handle that case but we're also considering how useful process checkpointing really is. If anybody has any feedback about it now it would be the time to share it :-)

To clarify, I don't actually have a use for process checkpointing yet, this was my first time experimenting with it. It's just that sys_checkpoint/checkpt looks so nice and boilerplate-free compared to e.g. CRIU :)

Actions

Also available in: Atom PDF