On Sun, 29 Jan 2017, Sebastien Marie wrote:
> I report this error as it is the first time I saw it when a coredump is
> generated.
>
> It occurs reproductibly with my current profile (but not with a fresh
> profile) when firefox crashs (currently when I visit <...> with JS
> activated).
>
> Please note that my point isn't the firefox crash, but the kernel error
> message.
...
> When it occurs, I have these errors messages in dmesg buffer:
>
> coredump of firefox(76129), write failed: errno 14
> coredump of firefox(4704), write failed: errno 14
...
> The kernel error message comes from coredump_write() function inside
> sys/kern/kern_sig.c:1619.
>
> Errno 14 is the error code from vn_rdwr(9). It is EFAULT, and occurs
> when a bad address is encountered.
>
> As I don't expect the kernel trying to do something at bad address (even
> with a bad program), I prefer to report the error message.
My recall from when I last looked at this is that this generally means
that while trying to write out the memory from an anonymous mapping, the
kernel hits a range which isn't currently backed *and* the process is at
or over its memory limit, so it can't be filled in.
I would argue that uvm_coredump_walkmap() should detect unbacked pages in
anons and indicate this to the callback, possibly invoking the calling
multiple times to walk it across the backed-vs-unbacked ranges of a single
umv_map_entry. ELFNAMEEND(coredump_writeseghdrs)() would then generate
segments with p_filesz < p_memsz to reflect that, so the unbacked pages
wouldn't be part of the segment's memory size, but not its file size, and
thus wouldn't be written out.
(e.g., if pagesize == 0x1000 and the VA range 0x1234000 - 0x124ffff was an
anon mapping but only the pages 0x1235000, 0x1236000, and 0x1240000
through 0x124f000 had been faulted into actual existence, then I would
have uvm_coredump_walkmap() invoke the callback three times:
start realend end
0x1234000 0x1234000 0x1235000
0x1235000 0x1237000 0x1240000
0x1240000 0x1250000 0x1250000
Indeed, the exec_elf.c side of that is already there, though currently
it's only in play for the stack on hppa: check out the
MACHINE_STACK_GROWS_UP section of uvm_coredump_walkmap() in
uvm/uvm_unix.c. <pause> Actually, that code looks broken, as it's moving
down state.end to a value less than state.realend, but exec_elf.c expects
state.realend to always be >= state.end! Dang it, now I have to fire up
the hppa again...
Philip Guenther
