On Thu, 28 Oct 2004 10:45:52 -0700, Duane Clark <dclark@xxxxxxxxxxx> wrote:
Mark Knecht wrote:
Found it!!
http://www.winehq.org/hypermail/wine-cvs/2004/05/0228.html
Yikes, that looks pretty scary;) That may take an Alexandre to fix. Though another possibility is if there is a list for jack_fst, the developers there might have a shot at figuring it out.
That's what I've come to discover on my own. This fix only touched 6-7 files, so my first silly experiment was to print the file. After 100 pages it basically when in the recycling bin.
I think asking for some help from Alexandre is going to be needed, but before I went there I thought it best to do my homework. I've now created two parallel directories - good-20040524-20:00:00 and bad-20040524-21:00:00. I've just set up xxdiff so that I can view the good and bad files against each other. The first couple that I looked at are actually not large changes. I hope they give me some clues. My thought is to set up a 3rd directory called 'test' which would use the bad directories code but patched to attempt a fix. Does this make sense?
Generally I just go ahead and make changes in the main tree. At any time, you can get back to the original by doing something like:
cvs diff loader/main.c > tmp.diff patch -p0 -R < tmp.diff
And that will leave you with a file that will allow you to easily reinsert your changes:
patch -p0 < tmp.diff
When the program crashes, does it dump you into the Wine debugger so that you can get a backtrace?
The easiest way I find to debug is to insert lots of TRACE statements into the code to see what is happening. By scattering them all through the routines, and seeing what TRACEs get executed prior to the crash, you might be able to find out exactly what line of code is causing the crash. Though with memory corruption bugs, the corruption might have occurred long before the crash.
_______________________________________________ wine-users mailing list wine-users@xxxxxxxxxx http://www.winehq.org/mailman/listinfo/wine-users
