WebKit (master) crashes when clicking HaikuLauncher

[vidrep]

hrev55438 x86_64

HaikuWebKit (master) crashes when double clicking HaikuLauncher

Debug report attached

[nephele]

Please include which commits you test with, master changes frequently.

[vidrep]

​https://github.com/haiku/haikuwebkit/commit/ee0847d6c27e862532a0f0fb04291b2bf3f10c51

[cocobean]

Tested Haikuwebkit 1.8.2 x86 (Webkit 613.1.3) build:: ee0847d6c27e862532a0f0fb04291b2bf3f10c51

HaikuLauncher loads fine. Still the known issue with some font scrambling in IRC.

[nephele]

Replying to cocobean:

Tested Haikuwebkit 1.8.2 x86 (Webkit 613.1.3) build:: ee0847d6c27e862532a0f0fb04291b2bf3f10c51

HaikuLauncher loads fine. Still the known issue with some font scrambling in IRC.

What has this issue got to do with font scrambling...? I can reproduce the crash aswell

[madmax]

Tested Haikuwebkit 1.8.2 x86 ... HaikuLauncher loads fine

The affected code is x86_64 only. A workaround may be unsetting ENABLE_SIGNAL_BASED_VM_TRAPS in wtf/Platform enable, but I still have to finish a build to be sure.

What has this issue got to do with font scrambling...?

Apparently nothing. That seems to be due to a change in the handling of control characters, but again, I'm waiting to be able to prove it.

[nephele]

Replying to madmax:

The affected code is x86_64 only. A workaround may be unsetting ENABLE_SIGNAL_BASED_VM_TRAPS in wtf/Platform enable, but I still have to finish a build to be sure.

This workaround does not work for me, it still crashes. It seems that flag was introduced in 2018, but i can't find where it is used

[madmax]

Replying to nephele:

Replying to madmax:

The affected code is x86_64 only. A workaround may be unsetting ENABLE_SIGNAL_BASED_VM_TRAPS in wtf/Platform enable, but I still have to finish a build to be sure.

This workaround does not work for me, it still crashes.

Neither does for me :-( Sorry for the noise.

It seems that flag was introduced in 2018, but i can't find where it is used

It's macros all the way down. Search for SIGNAL_BASED_VM_TRAPS. It guards (among other things) the code in the first report and I had not read the second, so it may be that I'm also wrong in the problem being x86_64 only, though we now have 3 x86_64 crashing and 1 x86 not crashing.

[nephele]

I get an assertion with the debug build:

~/proj/haikuwebkit-new/WebKitBuild/Debug ./HaikuLauncher                                                                             
Please note that you don't have secure memory on this system
ASSERTION FAILED: (*bitwise_cast<WTF::Config*>(&WebConfig::g_config[WTF::startSlotOfWTFConfig])).isThreadSuspendResumeSignalConfigured
../../Source/WTF/wtf/posix/ThreadingPOSIX.cpp(235) : static void WTF::Thread::initializeCurrentThreadEvenIfNonWTFCreated()
Abort

for completeness this is what i changed to get debug to compile:

diff --git a/Source/WebCore/testing/Internals.cpp b/Source/WebCore/testing/Internals.cpp
index ec2b92a8f5..f8091a2e16 100644
--- a/Source/WebCore/testing/Internals.cpp
+++ b/Source/WebCore/testing/Internals.cpp
@@ -6447,7 +6447,7 @@ constexpr TreeType convertType(Internals::TreeType type)
     case Internals::ComposedTree:
         return ComposedTree;
     }
-    ASSERT_NOT_REACHED();
+    //ASSERT_NOT_REACHED();
     return Tree;
 }
 
diff --git a/Source/WebKitLegacy/haiku/API/WebPage.cpp b/Source/WebKitLegacy/haiku/API/WebPage.cpp
index 3c37295f9b..954a183921 100644
--- a/Source/WebKitLegacy/haiku/API/WebPage.cpp
+++ b/Source/WebKitLegacy/haiku/API/WebPage.cpp
@@ -171,7 +171,7 @@ BMessenger BWebPage::sDownloadListener;
        // NOTE: This needs to be called when the BApplication is ready.
        // It won't work as static initialization.
 #if !LOG_DISABLED
-    WebCore::initializeLogChannelsIfNecessary();
+    //WebCore::initializeLogChannelsIfNecessary();
 #endif
     PlatformStrategiesHaiku::initialize();
 
diff --git a/Source/WebKitLegacy/haiku/WebCoreSupport/IconDatabase.cpp b/Source/WebKitLegacy/haiku/WebCoreSupport/IconDatabase.cpp
index 14eef5f5c6..196758c96e 100644
--- a/Source/WebKitLegacy/haiku/WebCoreSupport/IconDatabase.cpp
+++ b/Source/WebKitLegacy/haiku/WebCoreSupport/IconDatabase.cpp
@@ -1693,7 +1693,7 @@ inline void readySQLiteStatement(std::unique_ptr<SQLiteStatement>& statement, SQ
     if (!statement) {
         auto temp = db.prepareHeapStatement(str);
         if (!statement)
-            LOG_ERROR("Preparing statement %s failed", str.ascii().data());
+            LOG_ERROR("Preparing statement %s failed", str.characters());
         else
             statement = temp.value().moveToUniquePtr();
     }

[madmax]

Replying to nephele:

I get an assertion with the debug build:

ASSERTION FAILED: (*bitwise_cast<WTF::Config*>(&WebConfig::g_config[WTF::startSlotOfWTFConfig])).isThreadSuspendResumeSignalConfigured
../../Source/WTF/wtf/posix/ThreadingPOSIX.cpp(235) : static void WTF::Thread::initializeCurrentThreadEvenIfNonWTFCreated()

The ones I get (in a release build) are from ​addSignalHandler. The signal value passed to sigdelset is wild and different each time, when it should be SIGUSR1. In both yours and mine there's something fishy with g_wtfConfig.

There's some memory magic there. You seem to have fast compilations, can you force ENABLE_UNIFIED_AND_FREEZABLE_CONFIG_RECORD to 0 in ​PlatformEnable and see if that changes anything?

[nephele]

Replying to madmax:

There's some memory magic there. You seem to have fast compilations, can you force ENABLE_UNIFIED_AND_FREEZABLE_CONFIG_RECORD to 0 in ​PlatformEnable and see if that changes anything?

This made the build fail pretty quickly for me, in a quite ... interesting file :)

[152/1059] Building CXX object Source/JavaScriptC...tsExtractor.dir/llint/LLIntOffsetsExtractor.cpp.
FAILED: Source/JavaScriptCore/CMakeFiles/LLIntOffsetsExtractor.dir/llint/LLIntOffsetsExtractor.cpp.o 
/bin/ccache /bin/clang++ -DBUILDING_HAIKU__=1 -DBUILDING_LLIntOffsetsExtractor -DBUILDING_WITH_CMAKE=1 -DDATA_DIR=\"/boot/system/data/WebKit\" -DHAIKU_WEBKIT_VERSION=\"1.8.2\" -DHAVE_CONFIG_H=1 -DSTATICALLY_LINKED_WITH_WTF -DUSE_3D_GRAPHICS=0 -D_GLIBCXX_USE_C99_MATH -IJavaScriptCore/Headers -I. -I../../Source/JavaScriptCore -I../../Source/JavaScriptCore/API -I../../Source/JavaScriptCore/assembler -I../../Source/JavaScriptCore/b3 -I../../Source/JavaScriptCore/b3/air -I../../Source/JavaScriptCore/bindings -I../../Source/JavaScriptCore/builtins -I../../Source/JavaScriptCore/bytecode -I../../Source/JavaScriptCore/bytecompiler -I../../Source/JavaScriptCore/dfg -I../../Source/JavaScriptCore/disassembler -I../../Source/JavaScriptCore/disassembler/ARM64 -I../../Source/JavaScriptCore/disassembler/udis86 -I../../Source/JavaScriptCore/domjit -I../../Source/JavaScriptCore/ftl -I../../Source/JavaScriptCore/heap -I../../Source/JavaScriptCore/debugger -I../../Source/JavaScriptCore/inspector -I../../Source/JavaScriptCore/inspector/agents -I../../Source/JavaScriptCore/inspector/augmentable -I../../Source/JavaScriptCore/inspector/remote -I../../Source/JavaScriptCore/interpreter -I../../Source/JavaScriptCore/jit -I../../Source/JavaScriptCore/llint -I../../Source/JavaScriptCore/parser -I../../Source/JavaScriptCore/profiler -I../../Source/JavaScriptCore/runtime -I../../Source/JavaScriptCore/tools -I../../Source/JavaScriptCore/wasm -I../../Source/JavaScriptCore/wasm/js -I../../Source/JavaScriptCore/yarr -IJavaScriptCore/DerivedSources -IJavaScriptCore/DerivedSources/inspector -IJavaScriptCore/DerivedSources/runtime -IJavaScriptCore/DerivedSources/yarr -I../../Source/WTF -IWTF/Headers -I/system/develop/headers/private/system/arch/x86_64 -I/system/develop/headers/private/system -fdiagnostics-color=always -fcolor-diagnostics -Wextra -Wall -Wno-noexcept-type -Wno-psabi -Wno-misleading-indentation -Wno-parentheses-equality -Qunused-arguments -Wwrite-strings -Wundef -Wpointer-arith -Wmissing-format-attribute -Wformat-security -Wcast-align -Wno-tautological-compare -fpic -fno-strict-aliasing -fno-exceptions -fno-rtti -O3 -DNDEBUG -frtti -std=c++17 -MD -MT Source/JavaScriptCore/CMakeFiles/LLIntOffsetsExtractor.dir/llint/LLIntOffsetsExtractor.cpp.o -MF Source/JavaScriptCore/CMakeFiles/LLIntOffsetsExtractor.dir/llint/LLIntOffsetsExtractor.cpp.o.d -o Source/JavaScriptCore/CMakeFiles/LLIntOffsetsExtractor.dir/llint/LLIntOffsetsExtractor.cpp.o -c ../../Source/JavaScriptCore/llint/LLIntOffsetsExtractor.cpp
In file included from ../../Source/JavaScriptCore/llint/LLIntOffsetsExtractor.cpp:104:
JavaScriptCore/DerivedSources/LLIntDesiredOffsets.h:481:61: error: no member named 'offsetOfWTFConfigExtension' in namespace 'WTF'
constexpr int64_t constValue475 = static_cast<int64_t>(WTF::offsetOfWTFConfigExtension);
                                                       ~~~~~^
1 error generated.
ninja: build stopped: subcommand failed.

edit: seems to be a build caching issue.. that one is guarded, i'll retry with a clean one

[nephele]

I've attached the debug report for webkit build with ENABLE_UNIFIED_AND_FREEZABLE_CONFIG_RECORD = 0

[cocobean]

Tested Haikuwebkit 1.8.2 x64 (Webkit 613.1.1) build: b341c477b3d5b48840ed06cdc452f78808516b42

HaikuLauncher loads fine.

[pulkomandy]

in WebKitLegacy/haiku/API/WebPage.cpp, in initializeOnce, try moving ScriptController::initializeMainThread() after WTF::initializeMainThread().

This will make sure WTF::initialize() is called, which will set isThreadSuspendResumeSignalConfigured and will also initialize the signal value to SIGUSR1. Then the code in ScriptController that tries to set signals should run fine.

[pulkomandy]

I just pushed the change to the haikuwebkit repository. Let me know if it works.

[vidrep]

Debug report attached for HaikuLauncher crash on latest commit

[cocobean]

@Vidrep - can you test this update using WebPositive: ​https://www.dropbox.com/s/zjytwujngpmw7sy/haikuwebkit-1.8.2-3-x86_64.hpkg?dl=0

Give it a good testing to see if it fixes the majority of your issues.

[nephele]

Still crashes for me with 889085c4ff8e7954ca830cb3b54b33113e707718

@cocobean: I'm confused, this ticket is about haikuwebkits upstream... what's the point of this random package? There is no point if we can't even figure out what you did.

[nephele]

Commit 889085c4ff8e7954ca830cb3b54b33113e707718 crash report

[nephele]

I have done a bit more tracing and the assertion suceeds at the start of VM::computeCanUseJIT() and fails at the end of it, so something between those things seems to break it. need to narrow this down a bit further

​https://github.com/haiku/haikuwebkit/blob/haiku/Source/JavaScriptCore/runtime/VM.cpp line 258

[nephele]

Proposed fix: ​https://github.com/haiku/haikuwebkit/pull/7

[nephele]

fix merged