Closed hexchain closed 5 months ago
That looks like a bug in webkitgtk or in glib, I'm not sure how anyone can help you here...
Is it possible to obtain the URL of the credit card verification page? That seems to be the only page that can make webkit2gtk crash.
You can try to enable web inspector in the experimental settings, but I'm not sure it will really help
This also sounds pretty like a duplicate of #25541
@john-preston just told me you can find it in the mtp debug log looking for the string like that
result: { payments_paymentVerificationNeeded
url: "https://integrations.telegram.org/stripetest/verify/330139cc6cee6abab88e2c1af372e0851ea22283d21eadeff5" [STRING],
},
You can enable debug logs with the debugmode
cheat code
I was able to find the URL and put it into a WebKitGTK-based browser (Midori), but it didn't crash.
Are you sure it uses webkit2gtk-4.1? There are multiple API library versions currently
I just noticed that there are two webkit2gtk packages in Arch: webkit2gtk and webkit2gtk-4.1. Midori uses the former, so that was not a valid test.
But in the meantime, I also tried GNOME Web (Epiphany), which uses webkit2gtk-4.1, and it didn't crash either.
Honestly I have no idea what's going on. WebKit is a black box to me.
btw, it looks like gslice is no more existing on main branch of glib, so building glib from main branch may help
Although, according to the glib documentation, the behavior of the main branch could be also achieved by setting G_SLICE=always-malloc
With G_SLICE=always-malloc
the webview process also crashes:
#0 0x00000000063da30f n/a (/home/user/Downloads/Telegram/Telegram + 0x5fda30f)
This single line is sadly useless
Unfortunately, that's all I get from the official binary. With community/telegram-desktop
in Arch I do get more lines in the stack trace:
#0 0x00007f834281ad70 in () at /usr/lib/libjemalloc.so.2
#1 0x00007f83434a1276 in g_error_free (error=0x7f8324f204f0) at ../glib/glib/gerror.c:855
#2 0x00007f8327fdaba5 in WTF::GPtrDeleter<_GError>::operator()(_GError*) const () at /usr/src/debug/webkit2gtk-4.1/build/WTF/Headers/wtf/glib/GUniquePtr.h:67
#3 std::unique_ptr<_GError, WTF::GPtrDeleter<_GError> >::~unique_ptr() () at /usr/include/c++/12.2.1/bits/unique_ptr.h:396
#4 webkitWebViewWillStartLoad(_WebKitWebView*) () at /usr/src/debug/webkit2gtk-4.1/webkitgtk-2.38.5/Source/WebKit/UIProcess/API/glib/WebKitWebView.cpp:2456
#5 WebKit::PageClientImpl::didStartProvisionalLoadForMainFrame() () at /usr/src/debug/webkit2gtk-4.1/webkitgtk-2.38.5/Source/WebKit/UIProcess/API/gtk/PageClientImpl.cpp:494
#6 0x00007f8327f01a26 in WebKit::WebPageProxy::didStartProvisionalLoadForFrameShared(WTF::Ref<WebKit::WebProcessProxy, WTF::RawPtrTraits<WebKit::WebProcessProxy> >&&, WTF::ObjectIdentifier<WebCore::FrameIdentifierType>, WebKit::FrameInfoData&&, WebCore::ResourceRequest&&, unsigned long, WTF::URL&&, WTF::URL&&, WebKit::UserData const&) () at /usr/src/debug/webkit2gtk-4.1/webkitgtk-2.38.5/Source/WebKit/UIProcess/WebPageProxy.cpp:4849
#7 0x00007f8327f01ec5 in WebKit::WebPageProxy::didStartProvisionalLoadForFrame(WTF::ObjectIdentifier<WebCore::FrameIdentifierType>, WebKit::FrameInfoData&&, WebCore::ResourceRequest&&, unsigned long, WTF::URL&&, WTF::URL&&, WebKit::UserData const&) ()
at /usr/src/debug/webkit2gtk-4.1/webkitgtk-2.38.5/Source/WebKit/UIProcess/WebPageProxy.cpp:4815
#8 0x00007f8329aabc0e in IPC::callMemberFunctionImpl<WebKit::WebPageProxy, void (WebKit::WebPageProxy::*)(WTF::ObjectIdentifier<WebCore::FrameIdentifierType>, WebKit::FrameInfoData&&, WebCore::ResourceRequest&&, unsigned long, WTF::URL&&, WTF::URL&&, WebKit::UserData const&), std::tuple<WTF::ObjectIdentifier<WebCore::FrameIdentifierType>, WebKit::FrameInfoData, WebCore::ResourceRequest, unsigned long, WTF::URL, WTF::URL, WebKit::UserData>, 0ul, 1ul, 2ul, 3ul, 4ul, 5ul, 6ul>(WebKit::WebPageProxy*, void (WebKit::WebPageProxy::*)(WTF::ObjectIdentifier<WebCore::FrameIdentifierType>, WebKit::FrameInfoData&&, WebCore::ResourceRequest&&, unsigned long, WTF::URL&&, WTF::URL&&, WebKit::UserData const&), std::tuple<WTF::ObjectIdentifier<WebCore::FrameIdentifierType>, WebKit::FrameInfoData, WebCore::ResourceRequest, unsigned long, WTF::URL, WTF::URL, WebKit::UserData>&&, std::integer_sequence<unsigned long, 0ul, 1ul, 2ul, 3ul, 4ul, 5ul, 6ul>) () at /usr/src/debug/webkit2gtk-4.1/webkitgtk-2.38.5/Source/WebKit/Platform/IPC/HandleMessage.h:131
#9 IPC::callMemberFunction<WebKit::WebPageProxy, void (WebKit::WebPageProxy::*)(WTF::ObjectIdentifier<WebCore::FrameIdentifierType>, WebKit::FrameInfoData&&, WebCore::ResourceRequest&&, unsigned long, WTF::URL&&, WTF::URL&&, WebKit::UserData const&), std::tuple<WTF::ObjectIdentifier<WebCore::FrameIdentifierType>, WebKit::FrameInfoData, WebCore::ResourceRequest, unsigned long, WTF::URL, WTF::URL, WebKit::UserData>, std::integer_sequence<unsigned long, 0ul, 1ul, 2ul, 3ul, 4ul, 5ul, 6ul> >(std::tuple<WTF::ObjectIdentifier<WebCore::FrameIdentifierType>, WebKit::FrameInfoData, WebCore::ResourceRequest, unsigned long, WTF::URL, WTF::URL, WebKit::UserData>&&, WebKit::WebPageProxy*, void (WebKit::WebPageProxy::*)(WTF::ObjectIdentifier<WebCore::FrameIdentifierType>, WebKit::FrameInfoData&&, WebCore::ResourceRequest&&, unsigned long, WTF::URL&&, WTF::URL&&, WebKit::UserData const&)) () at /usr/src/debug/webkit2gtk-4.1/webkitgtk-2.38.5/Source/WebKit/Platform/IPC/HandleMessage.h:137
#10 IPC::handleMessage<Messages::WebPageProxy::DidStartProvisionalLoadForFrame, WebKit::WebPageProxy, void (WebKit::WebPageProxy::*)(WTF::ObjectIdentifier<WebCore::FrameIdentifierType>, WebKit::FrameInfoData&&, WebCore::ResourceRequest&&, unsigned long, WTF::URL&&, WTF::URL&&, WebKit::UserData const&)>(IPC::Connection&, IPC::Decoder&, WebKit::WebPageProxy*, void (WebKit::WebPageProxy::*)(WTF::ObjectIdentifier<WebCore::FrameIdentifierType>, WebKit::FrameInfoData&&, WebCore::ResourceRequest&&, unsigned long, WTF::URL&&, WTF::URL&&, WebKit::UserData const&)) [clone .constprop.0] () at /usr/src/debug/webkit2gtk-4.1/webkitgtk-2.38.5/Source/WebKit/Platform/IPC/HandleMessage.h:259
#11 0x00007f8327cdcc5d in WebKit::WebPageProxy::didReceiveMessage(IPC::Connection&, IPC::Decoder&) () at /usr/src/debug/webkit2gtk-4.1/build/DerivedSources/WebKit/WebPageProxyMessageReceiver.cpp:1183
#12 0x00007f8327e82eec in IPC::MessageReceiverMap::dispatchMessage(IPC::Connection&, IPC::Decoder&) () at /usr/src/debug/webkit2gtk-4.1/webkitgtk-2.38.5/Source/WebKit/Platform/IPC/MessageReceiverMap.cpp:129
#13 0x00007f8327f17e4a in non-virtual thunk to WebKit::WebProcessProxy::didReceiveMessage(IPC::Connection&, IPC::Decoder&) () at /usr/src/debug/webkit2gtk-4.1/webkitgtk-2.38.5/Source/WebKit/UIProcess/WebProcessProxy.h:505
#14 0x00007f8327e9e4ff in IPC::Connection::dispatchMessage(IPC::Decoder&) () at /usr/src/debug/webkit2gtk-4.1/webkitgtk-2.38.5/Source/WebKit/Platform/IPC/Connection.cpp:1105
#15 IPC::Connection::dispatchMessage(std::unique_ptr<IPC::Decoder, std::default_delete<IPC::Decoder> >) () at /usr/src/debug/webkit2gtk-4.1/webkitgtk-2.38.5/Source/WebKit/Platform/IPC/Connection.cpp:1150
#16 0x00007f8327e9ec6f in IPC::Connection::dispatchIncomingMessages() () at /usr/src/debug/webkit2gtk-4.1/webkitgtk-2.38.5/Source/WebKit/Platform/IPC/Connection.cpp:1254
#17 0x00007f8326e07dec in WTF::RunLoop::RunLoop()::{lambda(void*)#1}::_FUN(void*) [clone .lto_priv.0] () at /usr/src/debug/webkit2gtk-4.1/webkitgtk-2.38.5/Source/WTF/wtf/Function.h:82
#18 0x00007f8326e056b6 in operator() () at /usr/src/debug/webkit2gtk-4.1/webkitgtk-2.38.5/Source/WTF/wtf/glib/RunLoopGLib.cpp:53
#19 _FUN() () at /usr/src/debug/webkit2gtk-4.1/webkitgtk-2.38.5/Source/WTF/wtf/glib/RunLoopGLib.cpp:56
#20 0x00007f83434b582b in g_main_dispatch (context=0x7f83302286c0) at ../glib/glib/gmain.c:3454
#21 g_main_context_dispatch (context=0x7f83302286c0) at ../glib/glib/gmain.c:4172
#22 0x00007f834350ccc9 in g_main_context_iterate.constprop.0 (context=0x7f83302286c0, block=1, dispatch=1, self=<optimized out>) at ../glib/glib/gmain.c:4248
#23 0x00007f83434b40e2 in g_main_context_iteration (context=context@entry=0x7f83302286c0, may_block=may_block@entry=1) at ../glib/glib/gmain.c:4313
#24 0x00007f834391076e in g_application_run (application=0x7f8330228690, argc=<optimized out>, argv=0x0) at ../glib/gio/gapplication.c:2573
#25 0x00005632d796aee3 in Webview::WebKit2Gtk::(anonymous namespace)::Instance::exec (this=0x7ffe89659560) at /usr/include/c++/12.2.1/bits/shared_ptr_base.h:1665
#26 Webview::WebKit2Gtk::Exec() () at /usr/src/debug/telegram-desktop/tdesktop-4.6.3-full/Telegram/lib_webview/webview/platform/linux/webview_linux_webkit2gtk.cpp:1309
#27 0x00005632d5ae5049 in main(int, char**) (argc=<optimized out>, argv=<optimized out>) at /usr/src/debug/telegram-desktop/tdesktop-4.6.3-full/Telegram/SourceFiles/main.cpp:12
This time it looks like a different crash but still occurs inside webkitgtk.
I'll see if it's possible to reproduce the crash outside of Telegram.
Maybe it's a memory corruption :sob:
There were no memory corruption-looking crashes before we migrated to jemalloc, but they started after the migration, even in the updater, so maybe jemalloc is the culprit and it should replaced with scudo (the best behaving allocator when I was testing them back in time, but is a part of a big monorepo)...
Hey there!
This issue was inactive for a long time and will be automatically closed in 30 days if there isn't any further activity. We therefore assume that the user has lost interest or resolved the problem on their own.
Don't worry though; if this is an error, let us know with a comment and we'll be happy to reopen the issue.
Thanks!
It still happens in the latest Flatpak version.
This really smells like a bug in webkit but I have no idea how to report it nor who should report it nor what requirements for a bug report are (e.g. Qt's bug reporting requirements are way too hard as you have to prove the bug with a minimal reproducer and it's not possible to create a minimal reproducer from such complicated code that is closely tied to other parts of application so most likely-to-be-Qt-bugs end never fixed or worked around). Personally I don't feel I should do it as I can't even reproduce it so I won't be able to answer questions.
Fair enough. Do you still want this issue to be open in case anyone wants to dig deeper? Personally, I only use WebKit in tdesktop maybe once a year so I'm fine if you prefer closing it.
Well, there are multiple similar issues, so it clearly disturbs people but no idea how to reproduce that given that it seems to happen on 3-D Secure page of their bank. The fact gtk usage has to be splitted to a separate process to avoid crashes due to conflicts with Qt's gtk usage and the crash reporting code in tdesktop official binary can't handle crashes of that process complicates all that way further (most users don't know how to use gdb and can't build tdesktop to get debug symbols so it makes impossible to get crash traces from most users).
Sadly I have no idea what to do with all that. Having this issue open would at least be a point where duplicates can refer to.
The Linux webview implementation has 2.5 times more code than the Windows implementation (actually Windows has two implementations: 3.3 times more than the EdgeChromium one and 7.5 times more than the EdgeHtml one) and 6.4 times more code than the macOS implementation yet it's still buggy as hell on both X11 and Wayland. On X11 it bugs in various ways like #24356, #24362, #24953, #25086, #26288, #26680 which are likely due to some incompatibility between Qt and those WMs that couldn't reported due to this minimal reproducer requirement while the Linux webview implementation is HUGE, these i3wm "no content" bugs look just like the behavior on mutter and its forks so it had to be blacklisted for the X11 backend and DEs using GNOME technologies had no webview support until the Wayland backend (that can work on X11) was developed. Still, the Wayland implementation needs EVEN WAY MORE code to be mature as those stupid asses developing Wayland protocols have decided that cross-toolkit interoperability is not needed and you have to develop entire nested compositor to embed a widget from another toolkit. Thankfully there's QtWaylandCompositor (I don't know how people would live on other toolkits that aren't based on gtk!) that provides the image to the screen and maps basic mouse/keyboard control (at the price of linking to QtQml/QtQuick while entire tdesktop is QtWidgets) but nothing more: no keyboard layout support, no clipboard support (#26150), no cursor support; you have to implement this on your own which I'm highly doubt I will do. I've asked (1, 2, 3) Qt to provide such functionality but honestly I have no hope they will do as that's not what embedded (their customers) needs. If doing at tdesktop level, this would need two implementations for both features (keyboard layout, clipboard) based on native code: for Wayland and X11 due to the GNOME/i3wm case.
I don't know how Linux wants to get application developers with all that.
PS: #25126
I'm getting this on the latest version of the Windows app today.
Submit the card and address and it says webview crashed.
@codysherman Which version do you try? 4.14 or 4.14.1?
@john-preston 4.14.1
Same thing happening to me today on 4.14.2
Should be fine in 4.14.3. (at least as it was a couple of versions before)
Can confirm checkout worked!
Revisiting this issue on 4.14.3 (flatpak): It looks like clicking "Payment method" now opens a webview (the page is probably not specific to any bank?) but it still crashes, with the following journal message:
Scudo ERROR: misaligned pointer when deallocating address 0x656e6f446e6f
now opens a webview
Isn't that's how it was? The steps to reproduce look like the crash was always happening after going to the bank page.
but it still crashes
I guess it won't be solved until someone reports to the webkitgtk project
Isn't that's how it was? The steps to reproduce look like the crash was always happening after going to the bank page.
Not really? I remember it used to show a native page to collect the card number first, and then open the bank 2FA page in a webview.
Using latest (Snap, 4.15.0) Telegram Desktop for Linux, and I get the WebView crash when I try to complete a Premium gift purchase. Ubuntu 22.04.
@tautau webview in snap doesn't work at all so your case is not related
@hexchain there's a bunch of crash fixes for webview on dev branch. Can you test it (either by building from source or getting an artifact from actions)?
Using the artifact here (https://github.com/telegramdesktop/tdesktop/actions/runs/9082193254), WebView no longer crashes for me.
nice!
Steps to reproduce
Expected behaviour
The webview should display the verification page and allow the user to proceed.
Actual behaviour
The window shows a blank page and the webview process crashes. Stack:
webkit2gtk 2.38.5-1
Operating system
Arch Linux, Plasma 5.27 Wayland
Version of Telegram Desktop
4.6.3
Installation source
Static binary from official website
Logs
No response