Updating input_server device nearly halts system

[humdinger]

I was about to release a minor update - v1.2.4 - to Clipdinger. When test-installing the package, the previous v1.2.3 is uninstalled, and v1.2.4 gets installed.

After installing, the system becomes extremely sluggish. Windows get redrawn every few seconds and keyboard input etc. is practically impossible. I can press the power button and after a while the shutdown procedure runs in slo-mo.

I installed bets5 from scratch and installed Clipdinger v1.2.3 from HaikuDepot without this issue, so I assume this is only when replacing the input_server device with the one from the v1.2.4 package...

Clipdinger and its input_server device add-on has been updated with no issues often over the years, so I suppose this is a sideeffect of some more recent change in Haiku.

I attach Clipdinger v1.2.4. You may want to install v1.2.3 from HaikuDepot before updating.

[waddlesplash]

Is there high CPU usage? Does the problem persist after a reboot?

[humdinger]

After rebooting everything's working fine. But I don't want to provide the unsuspecting user with an update that will practically freeze their system and may lead to data loss in all open documents…

There's no telling about CPU usage, as everything but the mouse pointer is more or less at a stand-still.

[humdinger]

I had a look at the input-server related commits in recent history and tried a nightly image before and the next available after the potential culprits. That gives a range between ​hrev57898 (with this issue) and hrev57881 (working OK).

hrev57883 might've been the revision introducing this bug, though it appears to deal mainly with mouse settings...? I dunno, but the culprit definitely lies between hrev57881 and hrev57898.

[madmax]

On add-on removal, the device's stop method is called with the device list lock held, and in the case of Clipdinger that method waits for a thread that never ends.

hrev57883 might've been the revision introducing this bug, though it appears to deal mainly with mouse settings...?

That change fixes some cases of mouse settings handling. In particular, when no mouse name is given it gets the settings from the ones currently in use. For that it traverses the input devices list (containing not only mouse devices) and for that it needs to acquire its lock.

It seems that's triggered frequently to get double-click time, so now whatever triggers it is waiting forever. That includes some apps directly and others through some IK widgets. Not counting other cases not related to mouse click speed. To notice it before the change you probably needed something like connecting or disconnecting another input device or add-on, and it would be just that not working.

[madmax]

​https://review.haiku-os.org/c/haiku/+/8359 changes the input_server side to not wait on the lock for the mouse settings stuff. If the list is already locked it works as if there were no mice: defaults for reading and nothing for writing.

The only contention I found in my (light) system was after stopping Clipdinger's add-on, so I guess it should be OK.

Notice even with that change there's still a problem with the add-on and some stuff will still lock when you update or uninstall it. But at least it won't be most of the desktop.

[madmax]

For whatever reason, closing a Terminal (*any* Terminal, not necessarily the one from which the update/uninstall was made) breaks the loop.

[waddlesplash]

Fix merged in hrev58184.

[humdinger]

Would it be at all possible to pick this for the beta4 branch? It would avoid a 'near' freeze when updating Clipdinger and its InputDevice.

[waddlesplash]

You mean beta5, I suppose? Done.

[humdinger]

Duh, yeah beta5. Thanks!