DevPet needs to be careful about calling X functions from GLib error callbacks
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Midori Web Browser |
New
|
Undecided
|
Unassigned |
Bug Description
I experienced a crash about XLib not being used in a threading-correct manner when attempting to play an HTML5 video with DevPet enabled. This happens consistently when DevPet is enabled and not otherwise; the backtrace is attached, as well as the console output of a run without DevPet enabled.
It looks like, because GStreamer starts its own threads to do media playback, and those threads can generate GLib errors which DevPet would catch, DevPet needs to ensure that its error handler is fully threadsafe and does not call directly into XLib. In the case in which the error generated in a secondary thread is the first one caught by DevPet, it can result in X operations such as realizing the DevPet tray icon; these actions apparently need to occur in the main thread rather than whichever thread causes the first error.