Divide by zero exception at start

[metayan]

Environment

• OS: macOS Catalina
• Scrcpy version: dev - v3.3.3-13-g5b51396a
• Installation method: manual build
• Device model: Sony Xperia
• Android version: 9

Describe the bug

Divide by zero exception at start leading to crash.
It has only happened this once during all the years that I've been using scrcpy, but might be good to catch.

(I have a local addition that handles the swedish a-ring key, but it has nothing to do with the crash.)

scrcpy-sdl2 -S --tcpip=10.1.5.21
scrcpy 3.3.3 <https://github.com/Genymobile/scrcpy>
INFO: Connecting to 10.1.5.21:5555...
INFO: Connected to 10.1.5.21:5555
[...]/scrcpy-sdl2/scrcpy-server: 1 file pushed, 0 skipped. 40.9 MB/s (90716 bytes in 0.002s)
[server] INFO: Device: [Sony] Sony G8441 (Android 9)
[server] WARN: Audio disabled: it is not supported before Android 11
INFO: Renderer: metal
WARN: Demuxer 'audio': stream explicitly disabled by the device
INFO: Texture: 720x1280
[server] INFO: Device display turned off
Floating point exception: 8

From macOS crash report:

Crashed Thread:        0

Exception Type:        EXC_ARITHMETIC (SIGFPE)
Exception Codes:       EXC_I386_DIV (divide by zero)
Exception Note:        EXC_CORPSE_NOTIFY

Termination Signal:    Floating point exception: 8
Termination Reason:    Namespace SIGNAL, Code 0x8
Terminating Process:   exc handler [55148]

Thread 0 Crashed:
0   scrcpy-sdl2                         0x000000010757a64c sc_screen_convert_window_to_frame_coords + 156
1   scrcpy-sdl2                         0x0000000107576791 scrcpy + 12065
2   scrcpy-sdl2                         0x0000000107567aab main + 3419
3   ???                                 0x00007fff70104cc9 0 + 140735073504457

[metayan]

Found the culprit:
Handling a mouse event before the frame is created leads to division by zero in sc_screen_convert_drawable_to_frame_coords.

Fix in #6569

It seems that it only crashes if the mouse is moved in the area where the window will be.

Used lots of logging to track down what was happening:
metayan@3b0a182

[rom1v]

Thank you for your investigations!

Handling a mouse event before the frame is created leads to division by zero in sc_screen_convert_drawable_to_frame_coords.

So SDL_GetWindowSize() "returns" 0 for the width and/or the height:

scrcpy/app/src/screen.c

Line 941 in db2f72a

SDL_GetWindowSize(screen->window, &ww, &wh);

It seems that it only crashes if the mouse is moved in the area where the window will be.

Maybe SDL should not send a mouse event if the window is not visible yet? Or maybe this is expected? (cc @slouken)

[slouken]

Does this happen with SDL3? If so, please report a bug at https://github.com/libsdl-org/SDL/issues

[rom1v]

@metayan Please test on top of #6216.

[metayan]

Same crash with sdl3.30.

Should scrcpy really be handling mouse events before the window is created?
To me it seems like a scrcpy issue.
Easily fixed with #6569 .

[rom1v]

Should scrcpy really be handling mouse events before the window is created?

Maybe the mouse events should never be received before the window is created in the first place (a mouse event occurs from a window).

But I will probably still merge the fix/workaround.

[rom1v]

@metayan Btw, can you reproduce the division by zero after you minimize/unminimize the window, or does it only happen on startup?

[metayan]

Haven't been able to reproduce with minimize/unminimize, but it's a bit cumbersome to move the mouse in the area of the middle of the screen while unminimizing, so not a conclusive check.

However, after the window is minimized, it still receives events in the area of the screen where it was before being minimized. Very strange.

Tested with both SDL 3.2.28 and 3.3.6 prerelease.

[rom1v]

However, after the window is minimized, it still receives events in the area of the screen where it was before being minimized. Very strange.

Indeed, this is probably not expected.

You should report a bug then: #6568 (comment)

[rom1v]

However, after the window is minimized, it still receives events in the area of the screen where it was before being minimized. Very strange.

So the mouse events are still being injected into the device while the window is minimized?

[metayan]

Yes.
After minimizing the scrcpy window, I can for example see the message list highlight move as I move the mouse over the area where the window was before.

However, it seems that some applications do something to prevent this, for example Vivaldi and Mail.
Finder, Emacs, and the terminal program I use, kitty, let the mouse movement through.

Scrolling is not sent to the device.
It seems to be mouse movement only.