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
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
Created attachment 445344 [details]
eolie crash, additional backtrace 17461
this backtrace was erroneously placed in issue 233578
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.
(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.
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
* 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):
Partial RELRO Canary found NX enabled No PIE No RPATH No RUNPATH No Symbols Yes 14 39
(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.
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.