On Sun, Jan 29, 2017 at 12:41:20PM +0100, Sebastien Marie wrote:
> Hi,
>
> 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
>
And here's a rewrite of the coredump bits that does the sparse amap
handling on all amaps that aren't shared at the time of the coredump, so
it'll get consistent data and not panic the kernel. Doing this without
locking the shared amaps while doing the walks or writing to disk requires
On Tue, 31 Jan 2017, Sebastien Marie wrote:
> On Tue, Jan 31, 2017 at 12:07:48AM -0800, Philip Guenther wrote:
> > Sun, 29 Jan 2017, Philip Guenther wrote:
> > ...
> >
> > semarie@, you can consistently trigger that kernel log message, perhaps
> > you can try reproducing it with this patch and
On Tue, Jan 31, 2017 at 12:07:48AM -0800, Philip Guenther wrote:
> Sun, 29 Jan 2017, Philip Guenther wrote:
> ...
>
> semarie@, you can consistently trigger that kernel log message, perhaps
> you can try reproducing it with this patch and see if it goes away?
it is a bit better now: I have only
Sun, 29 Jan 2017, Philip Guenther wrote:
...
> 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.Actually, that code looks broken, as
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
4704] ###!!! ABORT: Aborting on channel error.: file
/usr/obj/ports/firefox-51.0/firefox-51.0/ipc/glue/MessageChannel.cpp, line 2056
Trace/BPT trap
When it occurs, I have these errors messages in dmesg buffer:
coredump of firefox(76129), write failed: errno 14
coredump of firefox(4704), write
