Bug 233584 – [GTK] Crash in WebKit::WebsiteDataStore::fetchDataAndApply

• Status: NEW
• Component: WebKitGTK

[LJoris]

Created attachment 445320 [details]
reproducible eolie crash after loading consent URL

coredumpctl mentions python39

notable is this coredump does not show as much detail as the previous one

change here was the site https://nu.nl could now load with all media, images,video enabled
eolie crashed again after redirect to https://myprivacy.dpgmedia.be/

I'll try and reproduce by restarting eolie with settings changing

sidenote, the browser start by loading https://att.com

[LJoris]

this can definitely be reproduced by loading a page where animated gif are playing, since there is a freeze there is no coredump available

if it is possible to capture something let me know

[LJoris]

Created attachment 445344 [details]
eolie crash, additional backtrace 17461

this backtrace was erroneously placed in issue 233578

[Michael Catanzaro]

Note: you have to select the WebKitGTK component, or we won't see it.

There are two backtraces here:

 * The first backtrace is bug #233578
 * The second backtrace, in comment #2, is the a11y crash that I mentioned in https://bugs.webkit.org/show_bug.cgi?id=233578#c14

Neither of these crashes involve WebKitWebsiteDataStore. You surely meant to report the crash from https://bugs.webkit.org/show_bug.cgi?id=233578#c6 instead.

[Michael Catanzaro]

(In reply to LJoris from comment #1)
> this can definitely be reproduced by loading a page where animated gif are
> playing, since there is a freeze there is no coredump available

Well you posted a backtrace for the crash, so you must have gotten it from a core dump.

I wonder if you're able to reproduce the actual WebKitWebsiteDataManager crash somehow. The backtrace at https://bugs.webkit.org/show_bug.cgi?id=233578#c6 is sufficiently weird that I actually wonder whether you might have a hardware failure here (this is *very* common and, yes, very scary). It's *probably* a WebKit bug, maybe memory corruption somewhere, but it's worth running a RAM test (e.g. memtest86) just in case. Normally RAM tests fail to detect bad RAM, but if it does catch a problem, that would explain a lot.

(gdb) bt full
#0  std::__atomic_base<unsigned int>::operator++() () at /usr/include/c++/10/bits/atomic_base.h:326
#1  WTF::ThreadSafeRefCountedBase::ref() const () at WTF/Headers/wtf/ThreadSafeRefCounted.h:60
#2  WTF::Ref<WebKit::WebsiteDataStore, WTF::RawPtrTraits<WebKit::WebsiteDataStore> >::Ref(WebKit::WebsiteDataStore&) () at WTF/Headers/wtf/Ref.h:67
#3  CallbackAggregator () at ../Source/WebKit/UIProcess/WebsiteData/WebsiteDataStore.cpp:438
#4  create () at ../Source/WebKit/UIProcess/WebsiteData/WebsiteDataStore.cpp:327
#5  WebKit::WebsiteDataStore::fetchDataAndApply(WTF::OptionSet<WebKit::WebsiteDataType>, WTF::OptionSet<WebKit::WebsiteDataFetchOption>, WTF::Ref<WTF::WorkQueue, WTF::RawPtrTraits<WTF::WorkQueue> >&&, WTF::Function<void (WTF::Vector<WebKit::WebsiteDataRecord, 0ul, WTF::CrashOnOverflow, 16ul, WTF::FastMalloc>)>&&) () at ../Source/WebKit/UIProcess/WebsiteData/WebsiteDataStore.cpp:451
#6  0x00007fbd6939c26c in WebKit::WebsiteDataStore::fetchData(WTF::OptionSet<WebKit::WebsiteDataType>, WTF::OptionSet<WebKit::WebsiteDataFetchOption>, WTF::Function<void (WTF::Vector<WebKit::WebsiteDataRecord, 0ul, WTF::CrashOnOverflow, 16ul, WTF::FastMalloc>)>&&) () at ../Source/WebKit/UIProcess/WebsiteData/WebsiteDataStore.cpp:318
#7  0x00007fbd693223fc in webkit_website_data_manager_fetch() () at ../Source/WebKit/UIProcess/API/glib/WebKitWebsiteDataManager.cpp:1031

I wonder why we can't see the values of any variables on the stack, but we do see line numbers, indicating that you have successfully installed all available debuginfo. I would only expect this if running on i386 (not enough RAM there for full debuginfo). Could you post the output of 'uname -a' please?

Since the backtrace is strange, I think most likely we'll only be able to fix this one if you can really reproduce it. And since you've attached only unrelated backtraces to this issue so far, I suspect you only hit this once by luck and can't actually reproduce.

[LJoris]

wrt the suggestion to run memtest, i've not had bad RAM in the 30 years i use computers, I've experienced it professionally just once. It is not something i tend to agree with but who am i to say.

What i do notice is the bugs for any issue i reported tend to happen in a specific address range which i attribute to specific loading points if i can name them as such. 

Sadly and obviously i'm not apt at distinguishing what type of address is on topic.

Running checksec (https://github.com/slimm609/checksec.sh) I noticed all process which have repeat coredump are not 'entirely strong', for eolie this means no PIE, no seccomp. I assume seccomp is not as relevant to memory randomization but PIE is afaik.


ps -ef | grep eoli
myuser     118370    4732  0 15:00 ?        00:00:00 python3 /usr/libexec/eolie-sp
myuser     594045    4951  1 15:46 ?        00:00:12 python3 /usr/bin/eolie



For example

checksec --proc-libs=118370
* System-wide ASLR (kernel.randomize_va_space): Full (Setting: 2)

  Description - Make the addresses of mmap base, heap, stack and VDSO page randomized.
  This, among other things, implies that shared libraries will be loaded to random 
  addresses. Also for PIE-linked binaries, the location of code start is randomized.

  See the kernel file 'Documentation/sysctl/kernel.txt' for more details.

* Does the CPU support NX: Yes

* Process information:

         COMMAND    PID RELRO           STACK CANARY            SECCOMP        NX/PaX        PIE                     Fortify Source
         python3 118370 Partial RELRO   Canary found            No Seccomp       NX enabled    No PIE                  Yes


    RELRO           STACK CANARY   NX/PaX        PIE            RPath       RunPath   Fortify Fortified   Fortifiable

* Loaded libraries (file information, # of mapped files: 1):

  /usr/bin/python3.9:
    Partial RELRO   Canary found      NX enabled    No PIE          No RPATH   No RUNPATH   No Symbols	  Yes	14		39

[Michael Catanzaro]

(In reply to LJoris from comment #5)
> wrt the suggestion to run memtest, i've not had bad RAM in the 30 years i use computers

Sadly I'm up to three times myself, in the past 10 years. :( I don't trust anything besides ECC nowadays. Anyway, like I said, this could also be a software bug corrupting memory, somewhere far removed from where the backtrace points to. Or maybe I just misread the backtrace and there's something obvious that I'm missing, that's certainly possible. If you manage to reproduce this one somehow, it would help a lot.

> Running checksec (https://github.com/slimm609/checksec.sh) I noticed all
> process which have repeat coredump are not 'entirely strong', for eolie this
> means no PIE, no seccomp. I assume seccomp is not as relevant to memory
> randomization but PIE is afaik.

We don't control the hardening flags that your distro chooses to use when building packages. It's not relevant to this issue anyway.

[LJoris]

The reason i shared the checksec output was to show what is the context for this and the other issue reported should that matter with interpreting backtrace information.


In the meantime I've ran an exhaustive memory integrity check. No test failed, no warnings of any kind were reported.