Created attachment 1038454 [details]
File: backtrace

Created attachment 1038455 [details]
File: cgroup

Created attachment 1038456 [details]
File: core_backtrace

Created attachment 1038457 [details]
File: dso_list

Created attachment 1038458 [details]
File: environ

Created attachment 1038459 [details]
File: limits

Created attachment 1038460 [details]
File: maps

Created attachment 1038461 [details]
File: mountinfo

Created attachment 1038462 [details]
File: namespaces

Created attachment 1038463 [details]
File: open_fds

Created attachment 1038464 [details]
File: proc_pid_status

I think this is a very rare case of a crash that is actually not a bug. You ran out of memory, which is catastrophic, so crashing is the only reasonable thing to do. This is common behavior for all GLib applications, not just WebKit.

Specifically, you hit this assert:

inline void* vmAllocate(size_t vmAlignment, size_t vmSize)
{
    void* result = tryVMAllocate(vmAlignment, vmSize);
    RELEASE_BASSERT(result);
    return result;
}

Caused by this mmap failure:

inline void* tryVMAllocate(size_t vmSize)
{
    vmValidate(vmSize);
    void* result = mmap(0, vmSize, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANON, BMALLOC_VM_TAG, 0);
    if (result == MAP_FAILED)
        return nullptr;
    return result;
}

Another user experienced a similar problem:

I'm not sure how to reproduce this, it happened after I logged into bugzilla to add myself into CC list of another bug. I hope the backtrace is useful, if not "we" can always close the report.

reporter:       libreport-2.6.2
backtrace_rating: 4
cmdline:        /usr/libexec/webkit2gtk-4.0/WebKitWebProcess 63
crash_function: vmAllocate
executable:     /usr/libexec/webkit2gtk-4.0/WebKitWebProcess
global_pid:     3826
kernel:         4.1.3-201.fc22.x86_64
package:        webkitgtk4-2.8.5-1.fc22
reason:         WebKitWebProcess killed by SIGSEGV
runlevel:       N 5
type:           CCpp
uid:            1000

I wanted to report this using abrt, and in the end it found duplicate (it took a lot to download all debug info)
About comment #12 I have ~4GB of RAM + ~4GB of swap, "at the time of crash" there was still about half of RAM free, and all swap free, running out of memory was only possible if some fast memory leak happened so it filled RAM+SWAP and then crashed. Computer almost locked up and it was unresponsive for about a minute, but it could also be because of abrt, the crash generated ~2.8GB of data (mostly coredump), I know this looks like result of running out of memory + using SWAP ..., so not sure if it is caused by abrt and already crashed application or epiphany+webkit+... before crash?

Created attachment 1063211 [details]
my_backtrace

(In reply to Branko Grubić (bitlord) from comment #13)
> Another user experienced a similar problem:
> 
> I'm not sure how to reproduce this, it happened after I logged into bugzilla
> to add myself into CC list of another bug. I hope the backtrace is useful,
> if not "we" can always close the report.

You hit the issue described in the first comment of https://bugs.webkit.org/show_bug.cgi?id=146793

(The workaround for that issue causes memory allocation to fail here.)

Reopening bugs that are probably caused by the address space limit....

webkitgtk4-2.8.5-2.fc22 has been submitted as an update to Fedora 22. https://bodhi.fedoraproject.org/updates/FEDORA-2015-14258

webkitgtk4-2.8.5-2.fc22 has been pushed to the Fedora 22 testing repository. If problems still persist, please make note of it in this bug report.\nIf you want to test the update, you can install it with \n su -c 'yum --enablerepo=updates-testing update webkitgtk4'. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-14258

webkitgtk4-2.8.5-2.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.