Bug 282172 – [GTK] [2.46.2] WebCore::DisplayUpdate::nextUpdate(): Arithmetic exception on i386

• Status: NEW
• Component: WebKitGTK

[Alberto Garcia]

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

[Andy Valencia]

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.

[[e-mail]]

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.

[Andy Valencia]

(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

[Anjana]

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