I am trying to find out why Wine is not working with some closed application, and fix it. I have narrowed it down from the logs to something to do with MDI (Multiple Documents Interface). However - trying to connect with a debugger to the program causes the program to bomb quite bombastically.
It appears that someone (ddd/gdb won't give me a stack frame, so I can only assume this is in the PE portion of the native application, rather than inside Wine) keeps calling STI and CLI (Set Interrupt and Clear Interrupt). This generates a segmentation fault (makes sense - this is priveleged command). If I do "cont", things continue (I can't vouch as to how long they do), but another sementation fault is right around the corner then.
On the other hand, if I detach the debugger from the process, the process runs fine. I am at a loss as to what might be the cause.
Is there any way to tell gdb to ignore the segmentation fault, and just let the builtin handler take care of it?
Will using winedbg instead do me any good?
On an unrelated note - I tried running valgrind-wine on the process. It complained right at the start that wine calls system vector 7 (waitpid), which is unsupported by valgrind. This seems odd to me, as this would suggest noone has ever ran valgrind successfully on wine.
Implementing waitpid in valgrind produces even stranger result - it seems valgrind exists almost immedietly, while the main process continues onward. Anyone has similar experience with valgrind? Is there any need for me to submit my waitpid implementation?
Shachar
-- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
