WebPositive - crash on quit (HaikuWebKit master)

[vidrep]

hrev56627 x86_64

HaikuWebKit 1.9.1 WebKit 615.1.10 (master)

Crash on quit. Not sure if it's related to earlier reports.

Debug report attached

[pulkomandy]

I have already seen this stacktrace where the destructor for ThreadGlobalData ends up trying to create a new ThreadGlobalData:

54	        0x7f5f03a35390  0x1cb9edf0ffb   abort + 0x4a
55	        0x7f5f03a35390  0x1b7ae07b79b   /boot/home/haikuwebkit/WebKitBuild/Release/lib/libWebKitLegacy.so.1.9.1 + 0x118979b
56	        0x7f5f03a353e0  0x1b7aeb98775   WebCore::ThreadTimers::setSharedTimer(WebCore::SharedTimer*) + 0x85
57	        0x7f5f03a35400  0x1b7aeb90e95   WebCore::ThreadGlobalData::ThreadGlobalData() + 0x35
58	        0x7f5f03a35430  0x1b7aeb90f42   WebCore::threadGlobalData() + 0x62
59	        0x7f5f03a35480  0x1b7aeb98cb9   WebCore::TimerBase::setNextFireTime(WTF::MonotonicTime) + 0x89
60	        0x7f5f03a354a0  0x1b7aeb98ebc   WebCore::TimerBase::~TimerBase() + 0x2c
61	        0x7f5f03a354e0  0x1b7aeb96c4e   WebCore::ThreadGlobalData::~ThreadGlobalData() + 0x2e
62	        0x7f5f03a35500  0x1b7aeb96ecd   WebCore::ThreadGlobalData::~ThreadGlobalData() + 0xd
63	        0x7f5f03a35530  0x1cb9ee09858   __pthread_key_call_destructors + 0x48
64	        0x7f5f03a35550  0x1cb9ee089cc   __pthread_destroy_thread + 0x2c
65	        0x7f5f03a35570  0x1cb9edf7dd9   _thread_do_exit_work + 0x49
66	        0x7f5f03a35590  0x1cb9ee728bd   exit + 0xd

Not sure what to do about it however, we don't have much Haiku-specific code involved in that area... and I had not reproduced this problem in a while after doing some other (unrelated) changes.

[tqh]

Might be interesting to look at in what order we call destructors if you think WebKit is not the problem.

[pulkomandy]

The involved code:

​https://github.com/webkit/webkit/blob/main/Source/WebCore/platform/Timer.cpp

timer destructor calls stop() stop() calls setNextFireTime setNextFireTime accesses threadGlobalData (which is being destroyed)

It looks like this would not happen if the timer is already stopped. So maybe it's must missing code to stop the timer before destruction of the global data? Now we have to find which timer it is...

[tqh]

I started to look at the code, and globaldata uses a default destructor, that should destroy timer before itself if I understand correctly, but somehow, it does the opposite? According to specs .dtors should be called in reverse order, so to me this looks like a potential bug there.

[tqh]

Perhaps as test just implement the globaldata destructor with correct order and see if it works?

[pulkomandy]

I don't reproduce this by just starting and exiting the browser. Any specific site you are visiting when this happens?

[diver]

Just had the same crash in Epiphany on quit in WebCore::ThreadTimers::setSharedTimer.

[waddlesplash]

I don't think this is urgent enough to delay the beta. If it happens in WebKitGTK also that points to a common cause, I suppose.

[pulkomandy]

Are there still problems with this one?

[vidrep]

I had a crash on quit a few days before PulkoMandy made his last comment. Should it happen again I’ll attach a debug report.

[vidrep]

I had a WebPositive crash on shutdown HaikuWebKit 1.9.4 WebKit 616.1.7. Excerpt of syslog attached

[vidrep]

Crashed again today. Sorry I was unable to give you a debug report last time. There's one this time (attached).

[pulkomandy]

This can be reproduced with DumpRenderTree when it times out (for example running LayoutTests/accessibility/activation-of-input-field-inside-other-element.html).

Unfortunately this prevents running the test suite very far, because if multiple instances of DumpRenderTree crash at the same time, Debugger will try to generate bug reports for each of them, and will deadlock.

[pulkomandy]

Should be fixed with ​https://github.com/haiku/haikuwebkit/commit/2ad576ac592fde9d4ecf613dfc534b377ed81244 (HaikuWebKit 1.9.7)