#crash in valgrind --tool=massif

1 messages · Page 1 of 1 (latest)

elfin compass
#

I have a program I wanted to run through massif but it crashes (only when run through massif). Using a debug build I get a panic trace that points to the .INVAL => unreachable switch branch in std.os.mmap, during one of the start-up calls to mmap that I make. I am doing something potentially odd with mmap: at the start of the program I make 16 calls to mmap like this:

const fd = try std.os.memfd_create("name", 0);
const size = 64 * 1024 * 1024 * 1024;
try std.os.ftruncate(fd, size);
const ptr = try std.os.mmap(null, size, std.os.PROT.READ | std.os.PROT.WRITE, std.of.MAP.SHARED, fd, 0);

This means I try to map 1TiB of when the program starts. Does something about valgrind/massif mean that I just can't try to grab virtual memory like this, or is there something specific I have to do when using massif?

indigo rose
#

That seems like a very odd thing to do

#

Is there a particular reason you need a mapping attached to a memfd?

elfin compass
#

So I can remap the pages later to have different virtual address pointing to the same physical addresses

indigo rose
#

As for why massif breaks it, it's likely changing the way mmap is called for tracking purposes. You could try to see exactly what it changes using strace

indigo rose
elfin compass
#

No, I'm trying to write an allocator that does compaction by meshing pages together - Andrew posted a link to a talk about it on reddit recently.

#

I have what seems like a working proof of concept, but wanted to run some stuff through massif to see what it said

indigo rose
#

Ah yeah I've seen that before

#

Well, ig just see what massif changes about the syscalls

elfin compass
#

I ran it with strace, but I'm a bit confused by the output (don't have much experience using strace). I can find the memfd and ftruncate calls, but I don't see the mmap call. The section of the output is:

memfd_create("pool16", 0)               = 3
gettid()                                = 8275
write(1029, "C", 1)                     = 1
rt_sigprocmask(SIG_SETMASK, [], ~[ILL TRAP BUS FPE KILL SEGV STOP SYS], 8) = 0
ftruncate(3, 68719476736)               = 0
rt_sigprocmask(SIG_SETMASK, ~[ILL TRAP BUS FPE KILL SEGV STOP SYS], NULL, 8) = 0
gettid()                                = 8275
read(1028, "C", 1)                      = 1
gettid()                                = 8275
gettid()                                = 8275
write(1029, "D", 1)                     = 1
rt_sigprocmask(SIG_SETMASK, [], ~[ILL TRAP BUS FPE KILL SEGV STOP SYS], 8) = 0
write(2, "thread ", 7)                  = 7

where that last write call is the start of the writing the panic message to stdout.
I don't know whether this strace output gives any hints about what is going on.

#

This is the very first mmap of the 16 memfd_create/ftruncate/mmap calls

indigo rose
#

Seems like massif may be intercepting the mmap call and not passing it through to the kernel

elfin compass
#

I also tried running with a more reasonable number of pages requested (single digits) and got the same crash

#

wait, I must not have - just tried again with 4pages per mmap and it got passed that point and crashed elsewhere...

#

but that other crash is an OutOfMemory which makes sense with the restricted pool size

indigo rose
#

hm interesting, I guess massif just doesn't like really huge mmaps

elfin compass
#

So I guess massif doesn't play nice with this technique

#

yea

indigo rose
#

Can you do what you're trying to do with smaller mmaps instead?

elfin compass
#

I could - the reason I made such big ones was just to not have to worry about it