hi all, executing a certain program with wine, we get several crashes, in the RDW_UpdateRgns function (winetop/windows/painting.c) and in a DLL of the program itself. the program always crashes after the creation of a subwindow, and the problem appears to be the same, that is, somewhere before the crash the window tree structure gets corrupted. in order to find the exact point in which this happens, is there a better method than running the program step by step and *manually* check the windows structure? in other words, is there any tool to automatically check them? thanks -- pietro giorgianni (giorgian@icube.it) Icube s.r.l. via Ridolfi 15, Pisa (PI) - Italy
giorgian <giorgian@icube.it> wrote: : hi all, : executing a certain program with wine, we get several crashes, in the : RDW_UpdateRgns function (winetop/windows/painting.c) and in a DLL of the : program itself. : the program always crashes after the creation of a subwindow, and the : problem appears to be the same, that is, somewhere before the crash the : window tree structure gets corrupted. : in order to find the exact point in which this happens, is there a : better method than running the program step by step and *manually* check : the windows structure? in other words, is there any tool to : automatically check them? I don't know of a manual tool to check. However in a similar situation as a layman's approach I hacked the relay code to print out the variable on exit ( or perhaps on entry and exit) Bye -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
giorgian wrote:> > hi all, > executing a certain program with wine, we get several crashes, in the > RDW_UpdateRgns function (winetop/windows/painting.c) and in a DLL of the > program itself. > > the program always crashes after the creation of a subwindow, and the > problem appears to be the same, that is, somewhere before the crash the > window tree structure gets corrupted. > > in order to find the exact point in which this happens, is there a > better method than running the program step by step and *manually* check > the windows structure? in other words, is there any tool to > automatically check them?not so many tools avail. there's the WIN_WalkWindows in windows/win.c which could help printing the whole window tree... coupled with some triggering of this dump at some point in time (for example, in relay as Uwe suggested) could help. but you'll have to look closely at the huge haystack and find the needle inside :-( however, if you have spotted which window (WND*) is overwritten, you can use hardware breakpoints (either by attaching gdb to the right thread, or using wine debugger) on the region field of the WND to get back to the spot which overwrittes it. A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle