Bug 195456 - jsc core crash with webkitgtk-2.23.92
Summary: jsc core crash with webkitgtk-2.23.92
Status: RESOLVED WONTFIX
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKitGTK (show other bugs)
Version: Other
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-03-08 04:53 PST by enometh
Modified: 2019-04-07 09:13 PDT (History)
7 users (show)

See Also:


Attachments
useless backtrace from the webprocess (17.33 KB, text/plain)
2019-03-08 04:53 PST, enometh
no flags Details
backtrace with -ggdb (8.51 KB, text/plain)
2019-03-20 23:54 PDT, enometh
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description enometh 2019-03-08 04:53:39 PST
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
Comment 1 Adrian Perez 2019-03-19 07:07:53 PDT
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?
Comment 2 Michael Catanzaro 2019-03-19 09:09:22 PDT
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.
Comment 3 enometh 2019-03-20 23:47:34 PDT
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,
Comment 4 enometh 2019-03-20 23:54:22 PDT
Created attachment 365505 [details]
backtrace with -ggdb
Comment 5 enometh 2019-03-20 23:56:28 PDT
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
Comment 6 Konstantin Tokarev 2019-03-22 06:43:35 PDT
"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 ?
Comment 7 Konstantin Tokarev 2019-03-22 06:44:35 PDT
BTW, if you are low on ram, using lower number of parallel compiler jobs should help
Comment 8 enometh 2019-04-06 18:51:12 PDT
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
Comment 9 Konstantin Tokarev 2019-04-07 05:03:30 PDT
If you compile with -Os -O2 result should be the same as just -O2, because only last of -O options takes effect.
Comment 10 Michael Catanzaro 2019-04-07 09:02:30 PDT
If -O2 were all that's required for breakage, we would be hearing a lot of complaints from distros.
Comment 11 Konstantin Tokarev 2019-04-07 09:13:18 PDT
Yes, so there should be some other flag, affecting optimizer, e.g. specific -march, or compiler itself might be miscompiled