[Webkit-unassigned] [Bug 233584] [GTK] Crash in WebKit::WebsiteDataStore::fetchDataAndApply
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Mon Dec 6 07:07:27 PST 2021
https://bugs.webkit.org/show_bug.cgi?id=233584
--- Comment #5 from LJoris <registered at commandline.be> ---
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
--
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20211206/5e9020d0/attachment-0001.htm>
More information about the webkit-unassigned
mailing list