Created attachment 364007 [details]
useless backtrace from the webprocess
This behaviour has been observed in webkitgtk in 2.23.3, 2.23.90,
2.23.91, 2.23.92, in 64bit builds.
Attaching gdb to the webprocess and trying to get a backtrace has
proven to be futile: One such backtrace is attached.
I would appreciate any info on how to get more info from webkit on this failure
Hi, thanks for the bug report! I believe this to be fixed in
the 2.24.0 release — I have just tried poking around httpbin.org
for a while with a fresh x86_64 build and I am not able to get
Could you please check with version 2.24.0 and confirm whether
this issue is gone or whether the report is still relevant?
We're talking on IRC. You need to find some way to build with -g in order to get a backtrace. There's nothing actionable here otherwise.
Please bear with me as I'm a bit slow:
I was able to build webkit-2.24.0 with -ggdb (with some difficulty
with just 4GB RAM) but as I expected, I still get the same sort of
useless stacktrace on the SIGTRAP with no function names.
I have verified that the correct libraries (1.8G libwebkit2gtk-4.0.so)
are being used.
No additional information is reported by gdb on the webprocess over my
As I am only seeing this on native 64bit gentoo builds, I suspect this
problem may be peculiar to my setup, but I am unable to figure out
what the problem may be or how to go about figuring why this
providing any debuggable clues.
I am still looking for suggestions,
Created attachment 365505 [details]
backtrace with -ggdb
Actually There is additional information in the stacktrace
which I am attaching:
The relevant line is
#94 0x00007fe75cb078fd in JSC::operationCompareStrictEq (exec=0x7ffe4bf113b0, encodedOp1=140629277965936, encodedOp2=-281474976710656)
"WebKitWebProces" received signal SIGTRAP - this probably means that there is WTFCrash involved, probably ASSERT
Also, you are using portage to build WebKitGTK, it might be that backtrace is obscured by some custom CFLAGS which you've passed via make.conf. Could you build it stand-alone from release tarball, as described in https://trac.webkit.org/wiki/BuildingGtk ?
BTW, if you are low on ram, using lower number of parallel compiler jobs should help
Thank you, it tindeed urns out to be a case of compiler flags. The problem only occurs
whencompiling with gcc-8.2.0 with -Os -O2 (-ggdb is not relevant)
Apparently there is jsc code which gcc miscompiles
when it is supplied with -Os -O2 and the crash smashes the stack
so that there is no information in gdb. I was alerted to the problem by a similar unexpected
crash in other software in a specific case, and possibly the gcc bug can be tracked down.
I didn't bother to recompile without -Os on gcc-8.2.0 but am trying out clang instead
If you compile with -Os -O2 result should be the same as just -O2, because only last of -O options takes effect.
If -O2 were all that's required for breakage, we would be hearing a lot of complaints from distros.
Yes, so there should be some other flag, affecting optimizer, e.g. specific -march, or compiler itself might be miscompiled