Web+ crashes on opening a URL from KeePassXC

[humdinger]

This is hrec55610, 64bit
HaikuWebKit 1.8.3

ALT+SHIFT+U opens a URL in KeePassXC. That used to work, but for some weeks(?) now, tis crashes Web+. Or rasther, the crash alert pops up, but the launched URL does load and Web+ is still usable.

This is the crash (full report attached):

thread 12079: BUrlProtocol.File 
state: Call (abort() called)

Frame		IP			Function Name
-----------------------------------------------
00000000	0x83e6be47cf	_kern_debugger + 0x7 
	Disassembly:
		_kern_debugger:
		0x00000083e6be47c8:   48c7c0e4000000  mov $0xe4, %rax
		0x00000083e6be47cf:             0f05  syscall  <--

0x7f2e63031d20	0x83e6bdc241	abort + 0x4a 
0x7f2e63031de0	0x171108eaf10	WTF::LockAlgorithm<unsigned char, (unsigned char)1, (unsigned char)2, WTF::EmptyLockHooks<unsigned char> >::lockSlow(WTF::Atomic<unsigned char>&) + 0x110 
0x7f2e63031e30	0x171108a142b	WebCore::BUrlRequestWrapper::Write(void const*, unsigned long) + 0xeb 
0x7f2e63031e70	0x1cdea5e6806	BDataIO::WriteExactly(void const*, unsigned long, unsigned long*) + 0x46 
0x7f2e63033110	0x1711096e8d4	BPrivate::Network::BFileRequest::_ProtocolLoop() + 0x714 
0x7f2e63033130	0x17110969f69	BPrivate::Network::BUrlRequest::_ThreadEntry(void*) + 0x29 
0x7f2e63033150	0x83e6be3547	thread_entry + 0x17 
00000000	0x7fd92cb7d260	commpage_thread_exit + 0 

[nephele]

Or rasther, the crash alert pops up, but the launched URL does load and Web+ is still usable.

One Thread has called abort(), but untill the debugger does something about it the other threads just continue running as if nothing happened ;)

This is likely related: https://dev.haiku-os.org/ticket/17356

I tried this once with still on haikuwebkit 1.8.2 but did not crash, so this is probably a regression also in the services kit api changes.

[nephele]

It seems it can also be reproduced with opening uris from other qt applications, Sometimes the browser does not crash but becomes unresponsive instead (no sites load anymore and such)

[pulkomandy]

BDataIO::WriteExactly(void const*, unsigned long, unsigned long*) is called from HTTP request threads (this change is since leorize's GSoC work on the service kit).

WebKit code does not like ot be called from non-main threads. So the forwarding to the main thread should be done in WebKit. Here for some reason it is not the case.

[bronzie94]

I am seeing the same problems on hrev55625 (and other recent builds) opening links in WebPositive from Quaternion and a few other apps. Of course, when you select "oh No!" on the crash alert panel, it kills all Web Positive threads instantaneously. Grrr.

[bronzie94]

Web Positive 'crash' when opening link from Quaterion

[pulkomandy]

I can't reproduce this, but I'm on a 32bit system and I tested with "open ​http://example.org" (don't have any Qt app installed at the moment). Can it be reproduced with open for you?

[diver]

Qt port switched to using open to workaround this issue. ​https://github.com/threedeyes/qt6-haikuplugins/commit/21aedce4a5697bffccf42583ff3e5a27e775db66

[pulkomandy]

Ok, then I have no way to reproduce the problem anymore?

[diver]

Turned out this was done only for qt6 for now. Should be still reproducible with qt5 apps.

[nephele]

This issues does not reproduce with open, with qt apps it seems to be reproduceable somewhat easily, I think this also sometimes reproduces with uri's opened from Renga though (but that is way less reliable).

[pulkomandy]

I think Qt and open use slightly different ways to send the parameters, but it shouldn't make a difference.

Anyway, please try ​https://github.com/haiku/haikuwebkit/commit/a76b8f20242835bb72159a1fc70c59f3faa00c51 where the lock (that is crashing in the backtrace) was replaced with a BLocker, this may fix the problem.

[nephele]

Fixed in haikuwebkit 1.8.4