On Fri, Jan 08, 2010 at 10:15:35PM +0100, Oldřich Jedlička wrote: > Hi Ping, Peter, > > are you sure that calling DeleteInputDeviceRequest is correct from > xf86WcmUninit? It causes crash on my system. The problem is as follows: > > 1. Server calls CloseDownDevices (devices.c). > 2. The method iterates inputInfo.devices and calls > DeleteInputDeviceRequest(dev). Note the `next` variable assignment (next = > dev->next) before the DeleteInputDeviceRequest is called. > 3. DeleteInputDeviceRequest (xf86XInput.c) calls RemoveDevice > 4. DeleteInputDeviceRequest calls UnInit of the device > > When the DeleteInputDeviceRequest returns, the `next` is used as a parameter > to next call to DeleteInputDeviceRequest. But if the driver in xf86WcmUninit > frees all it's devices, the `next` might get freed (partially?) and the check > > xf86Input.c, 675: if(drv->UnInit) > > fails with drv == NULL. Either the linuxwacom is doing something wrong, or > xserver doesn't do the freeing right (the `next` shouldn't be necessary if > the > list's head device is freed until the list is empty). > > Note that this is my analysis on the fact that "drv == NULL" in xf86Input.c > during session shutdown. I might be wrong :-)
The idea of the whole thing is that the driver only cals DIDR for a device when it is unplugged but not when closing down. The hotplugging order of the driver ensures that the actual device is the last one added to the server. For example, if you plug in a device "foo" you'll see the following devices being added (in this order): foo cursor foo erasor foo pad foo When the device is unplugged, HAL sends the removal event for the device "foo" which then removes the others. If the server is shut down however, the devices are removed in the order added. So once you hit the device "foo", no other devices get removed by the driver because they're already gone. This should work provided the devices remove themselves correctly from the common->wcmDevices list (hence this list is empty once DIDR is called for "foo"). This is the principle and it seems to work here - at least it doesn't crash on my box. drv only becomes NULL once the last input event using this driver has been removed. If you're seeing reproducible crashes on your box when shutting down, it might be worth starting X through valgrind and looking at where the invalid memory access is. That might help to identify what's going on there. In regards to the "next" shouldn't be necessary: we're iterating through a different list here than the server (wcmDevices), hence the pointers are maintained even if the server frees the device. So the next pointer becomes invalid once the device structure was freed. Cheers, Peter ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Linuxwacom-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
