Bug 195456 – jsc core crash with webkitgtk-2.23.92

• Component: WebKitGTK
• Status: RESOLVED WONTFIX

Created attachment 364007 [details]
useless backtrace from the webprocess

the webprocess crashes on SIGTRAP when running javascript from
http://httpbin.org/

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

[Adrian Perez]

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
any crash.

Could you please check with version 2.24.0 and confirm whether
this issue is gone or whether the report is still relevant?

[Michael Catanzaro]

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
previous report.

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
particular javascript crashes and why it crashes in this way - without
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)
    at /var/tmp/portage/net-libs/webkit-gtk-2.24.0/work/webkit-gtk-2.24.0/Source/JavaScriptCore/jit/JITOperations.cpp:1245

[Konstantin Tokarev]

"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 ?

[Konstantin Tokarev]

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

[Konstantin Tokarev]

If you compile with -Os -O2 result should be the same as just -O2, because only last of -O options takes effect.

[Michael Catanzaro]

If -O2 were all that's required for breakage, we would be hearing a lot of complaints from distros.

[Konstantin Tokarev]

Yes, so there should be some other flag, affecting optimizer, e.g. specific -march, or compiler itself might be miscompiled