282172 2024-10-28 08:32:19 -0700 [GTK] [2.46.2] WebCore::DisplayUpdate::nextUpdate(): Arithmetic exception on i386 2026-03-17 02:27:46 -0700 1 1 1 Unclassified WebKit WebKitGTK WebKit Nightly Build PC Linux RESOLVED FIXED https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1085710 P2 Normal --- 1 berto webkit-unassigned ajv-691-701-2657 anjana.r bugs-noreply givemeagoodun oldest_to_newest 2070910 0 berto 2024-10-28 08:32:19 -0700 One Debian user reports the following crash using WebKitGTK 2.46.0 and 2.46.2 in i386 when running Evolution 3.54.0 on Debian trixie: Thread 48 "VBlankMonitor" received signal SIGFPE, Arithmetic exception. [Switching to Thread 0xccc7bb40 (LWP 21804)] Download failed: Argument invalide. Continuing without source file ./build-soup3/./build-soup3/WebCore/PrivateHeaders/WebCore/DisplayUpdate.h. WebCore::DisplayUpdate::nextUpdate () at ./build-soup3/WebCore/PrivateHeaders/WebCore/DisplayUpdate.h:44 warning: 44 ./build-soup3/WebCore/PrivateHeaders/WebCore/DisplayUpdate.h: Aucun fichier ou dossier de ce nom #0 WebCore::DisplayUpdate::nextUpdate () at ./build-soup3/WebCore/PrivateHeaders/WebCore/DisplayUpdate.h:44 #1 WebKit::DisplayLink::notifyObserversDisplayDidRefresh () at ./Source/WebKit/UIProcess/DisplayLink.cpp:217 #2 0xf1f734db in operator() () at ./Source/WebKit/UIProcess/glib/DisplayLinkGLib.cpp:38 #3 call () at ./build-soup3/WTF/Headers/wtf/Function.h:53 #4 0xf1f73bbc in WTF::Function<void()>::operator() () at ./build-soup3/WTF/Headers/wtf/Function.h:82 #5 operator() () at ./Source/WebKit/UIProcess/glib/DisplayVBlankMonitor.cpp:101 #6 call () at ./build-soup3/WTF/Headers/wtf/Function.h:53 #7 0xeeca1d20 in WTF::Function<void()>::operator() () at ./Source/WTF/wtf/Function.h:82 #8 WTF::Thread::entryPoint () at ./Source/WTF/wtf/Threading.cpp:266 #9 0xeed0a9f8 in wtfThreadEntryPoint () at ./Source/WTF/wtf/posix/ThreadingPOSIX.cpp:239 #10 0xf0dda872 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:447 #11 0xf0e72b48 in __GI___clone3 () at ../sysdeps/unix/sysv/linux/i386/clone3.S:111 From the line numbers the problem seems to be here: https://github.com/WebKit/WebKit/blob/webkitgtk-2.46.2/Source/WebCore/platform/graphics/DisplayUpdate.h#L44 And that is likely a division by zero: DisplayUpdate nextUpdate() const { return { (updateIndex + 1) % updatesPerSecond, updatesPerSecond }; } The CPU is an Intel Core2 Duo T9300 2087286 1 ajv-691-701-2657 2025-01-14 16:50:11 -0800 I can confirm this SIGFPE on the VBlankMonitor thread. It happens on an Atom N270 (32-bit Debian/Devuan) with libwebkit2gtk-4.0-37 I don't see debug symbols in the repo, but happy to work with somebody. This happens on the Vala-based Midori browser, right after initial screen paint. 2087828 2 givemeagoodun 2025-01-16 12:38:42 -0800 Can also confirm on Atom N270 on Debian (libwebkit2gtk-4.1, version 2.46.5), using any application that uses webkitgtk, I'm currently working on getting it to compile to make debug symbols for it (I keep running out of virtual memory space though) Based on the fact that it happens in VBlankMonitor, it might be worthwhile to note that I'm using xserver-xorg 1.21.1.15 according to X -version, using the mesa gallium i915 driver. 2088136 3 ajv-691-701-2657 2025-01-17 13:48:30 -0800 (In reply to Alberto Garcia from comment #0) > ... > From the line numbers the problem seems to be here: > https://github.com/WebKit/WebKit/blob/webkitgtk-2.46.2/Source/WebCore/ > platform/graphics/DisplayUpdate.h#L44 > > And that is likely a division by zero: > > DisplayUpdate nextUpdate() const > { > return { (updateIndex + 1) % updatesPerSecond, updatesPerSecond }; > } > > The CPU is an Intel Core2 Duo T9300 The code at the SIGFPE doesn't clearly match that function: (gdb) x/6i $pc => 0xb27c03d8: divl 0x18(%ebx) 0xb27c03db: mov %edx,0x14(%ebx) 0xb27c03de: test %cl,%cl 0xb27c03e0: je 0xb27c0430 0xb27c03e2: mov 0x30(%esp),%eax 0xb27c03e6: movl $0x0,0x1c(%eax) (gdb) x/16xw $ebx 0x8405e0: 0x004d56e0 0x00000001 0x008b3cb0 0x00000001 0x8405f0: 0x00000000 0x00000000 0x00000000 0x00000000 0x840600: 0xb1ef0830 0x00000000 0xb1ef0234 0x00000031 0x840610: 0x00000000 0x00000000 0x00000000 0xb7caec70 (gdb) Quit It's putting the modulo back into the structure from which it got the 0 value for the SIGFPE. Andy 2115612 4 anjana.r 2025-05-07 04:13:05 -0700 Hello All, Any update on this bug? I am also facing a similar issue. I have Debian Bookworm installed on my PC which is intel i3 Core. I am trying to execute the "MiniBrowser" Application. The application is crashing with Floating Point exception. Upon further debugging, I have observed that the issue is coming because "updatesPerSecond" is 0 in the function "nextUpdate() " Any reason why this is happening? Thanks & Regards, Anjana 2190444 5 ajv-691-701-2657 2026-03-15 17:05:50 -0700 So I hunted this down; a 32-bit overflow bug in Gtk, now reported: https://gitlab.gnome.org/GNOME/gtk/-/issues/8103 2190526 6 berto 2026-03-16 04:00:12 -0700 Thanks, I prepared some patched GTK packages for Debian trixie users to test, I'll come back with the results: https://people.debian.org/~berto/bug-1085710/trixie/ 2190573 7 ajv-691-701-2657 2026-03-16 07:45:31 -0700 The Gtk side is asking about a Merge Request. Does this mean you'll handle that as well? You might want to tack something onto the bug over there. 2190578 8 berto 2026-03-16 07:56:19 -0700 At the moment I'm just testing if this solves the problem or not, but I can help with the merge request if necessary. Since you have been able to reproduce it, I understand that the bug is in this line: refresh_rate = (1000 * xmode->dotClock) / (xmode->hTotal * xmode->vTotal); From your analysis it should be enough with replacing that 1000 with 1000ULL, right? What are the values of dotClock, hTotal and vTotal that are causing the overflow? 2190581 9 ajv-691-701-2657 2026-03-16 08:00:08 -0700 It's in the gdb log over on that ticket: (gdb) p *xmode $23 = {id = 73, width = 1440, height = 900, dotClock = 106500000, hSyncStart = 1520, hSyncEnd = 1672, hTotal = 1904, hSkew = 0, vSyncStart = 903, vSyncEnd = 909, vTotal = 934, name = 0xccb158 "1440x900", nameLength = 8, modeFlags = 6} Along with the calculation with and without forcing to 64 bits. (Unsurprising values for a low end desktop config.) 2190586 10 berto 2026-03-16 08:05:04 -0700 Thanks, then using 1000ULL should be enough. I'm preparing some patches packages for testing. 2190661 11 berto 2026-03-16 12:00:15 -0700 Andy: the Debian reporter confirms that this fixes the crash in WebKit, will you create a MR against GTK or do you need help with that? 2190670 12 ajv-691-701-2657 2026-03-16 12:57:13 -0700 I would be happy to create the MR, but never having done it--yes, help would be welcome. I will get in touch via private email, thank you! 2190929 13 berto 2026-03-17 02:27:46 -0700 Ok, this was fixed in GTK so we can close it.