coredumps #1067
Comments
|
Crashes for me too, but not if I start luakit like Using |
|
Is this the full backtrace you're seeing? There's no luakit and no webkit in there... Can you try to hit the issue with EDIT: Nevermind - I'm able to reproduce the bug. It just took many times opening the website. |
|
Can you retest with the latest commit? I cannot reproduce the issue with it anymore. |
|
It occurs too unpredictable to be certain but I haven't had any problems since. If you close this, the issue can always be reopened if problems recur. |
|
I just didn't want to be rude without being certain. But there's a high chance that it's fixed now. I'll close the issue. Please reopen it when it happens again. Thanks! |
|
Still crashes for me, albeit less often. If the site loads fine, reloading it a couple times results in a crash |
|
Alright, we keep the issue then. Can you run a luakit debug build in gdb until it crashes and then post a stack trace? I reloaded archlinux.org 50 times this morning - also in multiple tabs at the same time. No crash here. |
|
I don't use gdb, how would I debug luakit using it? Here's the debug log though: |
|
On the first glance, nothing is catching my eye in the log. The easiest way is to start it with |
|
|
I guarded more of the IPC and lua stack operations. I ran the test suite in a loop for an hour and did 100 refreshes on archlinux.org and got no crash. Please try again with the latest version. |
|
Yup, still crashes for me: stacktrace: Version info: |
|
So, I did some more testing, and it seems like the problem occurs if I'll continue to do some testing, but this might be the culprit (atleast for me, I don't know if @henkmet uses hardened_malloc too) EDIT: Nevermind, still crashes. Different stacktrace though: |
|
Just crashed but all the bt I get is this; not sure why so short: |
|
Webkit spawns many threads, these threads communicate with the luakit main thread using GIO channels. What is happening here is that a webkit thread tries to write to a non existant channel. This is why the backtrace is short and doesn't show anything from luakit. I'm not sure how to methodically debug this. So I'm trying to find situation where a channel could get closed and try to make sure that nothing is sent/recieved on these channels. Meanwhile, I think that this crash and the fact that hints are also not visible on archlinux.org are related. There's an early EOF, which also closes the channel. The reaction is intended, but that the EOF is sent is not OK, because this means the thread stays around and cuts off the communication with luakit. The effect is, that no further signals are getting to this thread and neither scrolling, nor hints work. I think this situation also leads to this segfault when the thread finds a way to send a signal to the close ipc channel. I'm going to read a bit more about GIO to back up my assumptions. |
The original post was on a recent build of luakit but the one I quote here was on a machine where I forgot to rebuild. Apologies for that. |
|
I have this issue with #1079 on a stable release. If i build with git, this problem is gone. |
|
I'm currently working on this. It happens in various circumstances and it depends on the website. You're likely seeing this error on the terminal in the latest git version: "Trying to send an ipc message, but the endpoint went away." I added a check, which prevents luakit from crashing (mostly). BUT it does not prevent the webview from not initializing properly. This means all functions/keybinds that emit signals on the webview won't work (follow mode / scroll via keyboard). If you open another page on the same webview(tab), the issue carries over. If you close the tab and open a new one, it works again. EDIT:
Not in all cases, because I started to check the lua objects before reaching this point. |
|
I just got a longer bt from a crash, again going back and forth in history on an archlinux website. Indeed one of the most recent calls is ipc_send_lua(). Since I already have the bt, I'll attach it: |
|
Just an update - no solution yet. When tracing the called functions, this is what is happening: Up to here, everything looks normal. Usually the webview starts up here and the navigation request is handled (with page id 16 in this case). However, in the archlinux.org case, a lua_ipc message is sent which leads to the re-initialization of the webextension... The reinitialization is triggered by an EOF, which is recieved on the GIO channel. All we know at this point is that we can't communicate with this channel anymore and so we close it down. I assume this leads to the reinitialization of the webextension. The questions now are:
I still have trouble to put the finger on why these things are happening. |
|
I have tried a few times to figure this out and have failed. Any help is welcome here. |
|
I've been bit by this issue endless times now and I'd like to help if I can. So far I noticed the same issue happens in Vimb (so I'm guessing Luakit is at least not at fault). It's always reproducible when visiting the site switchedtolinux.com. Sometimes by a segfault, sometimes just by the EOF. @c0dev0id I'm not exactly new to debugging but Webkit is quite daunting to me. Still, if you could point me to the right direction to debugging this I'd love to see if I can find something. Luakit is incredibly comfy when it works, and I'd hate to see it die. |
|
@intr-cx If its reliable crashing for you, can you try to roll back the libsoup3 update and see if that fixes it? I tried to debug the issue but I didn't manage to get ahead of the signal flow that's happening (and where it's wrong). |
|
@c0dev0id I've compiled luakit with the provided patch, but the segfaults still happen. Either it segfaults or scrolling/hinting breaks, every time. It seems every coredump looks the same. |
Current Behavior:
After updating webkit to 2-42-4 on archlinux (and rebuilding luakit) I'm experiencing instabilities. Two times a SIGSEGV and once a SIGABRT
Desired Behavior:
don't crash
How can we reproduce it (step by step):
As before, it seems archlinux.org triggers something. I'd need to do some more testing for step-by-step reproduction.
Environment:
Linux Distribution & Version:
archlinux, linux 6.6.7.arch1-1
Output of
luakit --version:luakit 2.3.3-15-gb143b383
built with: webkit 2.42.4 (installed version: 2.42.4)
GTK 3.24.38
GLIB 2.78.3
SOUP 3.4.4
Note about webkit issues:
If you're reporting a rendering issue, please test it with the gnome
browser ephiphany as well. If the issue occurs there too, we're very
likely not able to help. These issues should be reported to webkit:
https://bugs.webkit.org
I don't know how useful backtraces are but there seems to be an issue with malloc? (This is from the SIGABRT coredump)
(gdb) bt
#0 __pthread_kill_implementation (threadid=, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
#1 0x00007fa4dfefe8a3 in __pthread_kill_internal (signo=6, threadid=) at pthread_kill.c:78
#2 0x00007fa4dfeae668 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#3 0x00007fa4dfe964b8 in __GI_abort () at abort.c:79
#4 0x00007fa4dfe97390 in __libc_message (fmt=fmt@entry=0x7fa4e000e55d "%s\n") at ../sysdeps/posix/libc_fatal.c:150
#5 0x00007fa4dff087b7 in malloc_printerr (str=str@entry=0x7fa4e00117d8 "malloc(): mismatching next->prev_size (unsorted)") at malloc.c:5765
#6 0x00007fa4dff0bd9c in _int_malloc (av=av@entry=0x7fa438000030, bytes=bytes@entry=88) at malloc.c:4076
#7 0x00007fa4dff0ccad in __GI___libc_malloc (bytes=bytes@entry=88) at malloc.c:3329
#8 0x00007fa4e00b4763 in g_malloc (n_bytes=88) at ../glib/glib/gmem.c:130
#9 0x000056105d128605 in ipc_endpoint_new ()
#10 0x000056105d125875 in ()
#11 0x00007fa4e00dda05 in g_thread_proxy (data=0x56105f21ddf0) at ../glib/glib/gthread.c:831
#12 0x00007fa4dfefc9eb in start_thread (arg=) at pthread_create.c:444
#13 0x00007fa4dff807cc in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78
The text was updated successfully, but these errors were encountered: