[Wine]old Wine from CVS
dclark at akamail.com
Thu Oct 28 13:50:24 CDT 2004
Mark Knecht wrote:
> On Thu, 28 Oct 2004 10:45:52 -0700, Duane Clark <dclark at akamail.com> wrote:
>>Mark Knecht wrote:
>>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
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.
More information about the wine-users