On Thu, Feb 10, 2011 at 3:54 AM, Bert Freudenberg <b...@freudenbergs.de> wrote: > libsugarize only works for "well-behaved" simple X11 programs. It relies on > certain functions being called that have been redirected to the library's > overrides. It's a preload-hack, not a proper library, so I'd expect many > programs not to work correctly.
Indeed. At this point, we think the crash comes not so much from libsugarize but from changing windows very quickly during startup. If we don't use libsugarize, Sugar doesn't recognize the window as interesting, and doesn't get the callbacks. I have a fixed-up libsugarize that doesn't cache the call results in a static var -- it was caching the window handle too. Not sure why it is structured like that, it doesn't seem to make sense with apps that may switch windows. If we do use libsugarize, Sugar gets the callbacks (jarabe.model.shell._window_opened_cb()) and crashes querying the window that was valid a ms ago, and now is no longer valid. This app (Adobe AIR stuff) seems to trigger 4 window switches (that trigger the callback) during startup. The crash doesn't always happen -- you gotta get the timining "right" for the race condition. We're tracing this to strengthen Sugar in the face of "flipping windows" -- so it won't crash. But it won't be able to keep track of the correct window for the app either. On the other side of the fence, I'm working with the "upstream" on the activity side so that it doesn't flip windows faster than the eye can see. Where the eye has 'persistence of vision', xorg has race conditions. Progress? m -- martin.langh...@gmail.com mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel