[Wine]old Wine from CVS

[Duane Clark]

Mark Knecht wrote:
> On Thu, 28 Oct 2004 10:45:52 -0700, Duane Clark <dclark at akamail.com> 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.