Wine Regression Testing

From Wine-Wiki

Jump to: navigation, search
This article is part of the HOWTO series.
Installing Wine • Business • Games • Internet • Multimedia • System and Utilities
• Education • Other


Warning: This HOWTO comes with no explicit or implicit warranty whatsoever. Use at you own risk!



Contents

[edit] Information

If Wine stops working for you - you can help find the solution by doing Regression Testing.

This process will allow you to go back and find the cause of the problem. If you can identify the person who is at 'fault' and also inform the developers which 'patch' caused your problem, half the work is done, and that will get you going again much faster.

Regression Testing is important for the Wine project. Developers are continually improving the code but because they are human, occasionally they make a mistake or even misunderstand how a aspect of Microsoft Windows is implemented. However, by catching these breakages early, their fixes are also often relatively easy. Not to be overlooked is that by identifying the developer, you can help it get fixed faster. Developers take great pride in their work, and when an error is found, they like to fix it.

What is involved

Regression Testing involves downloading the source and then rolling back the patches, recompiling each time to check when the program broke. This sounds scary for some, but in fact is relatively easy. The developers work hard so that patches do not break wine, making it easy for non technical people to test and find the offending patch. For you to find a patch that causes a bug, you will need a little time to let your computer recompile wine. If in the rare case you need help, you can always get further assistance by emailing the wine-user mailing list.

The need for speed

While a User who manages to locate a bug is likely to spend a few hours, this saves valuable time. Lets see an example: 20 different users find 12 bugs(we are going to say a few were duplicates), each spending 2 hours. This has saved a developer a week of merely trying to identify these bugs! Now he can spend that week fixing bugs and improving wine. While regression testing is not a requirement, those who are willing to do this testing allow the wine developers to wisely focus their efforts and time fixing the bug (rather than spending their time merely trying to find it).

Faster Checking of each Release for Bugs

For those Checking each release or pulling from Git the daily changes may find checking for bugs can be time consuming. For those with little time, perhaps investigate Automated Regression Testing

[edit] Regression Testing for Wine

You will need to have an internet link and preferrably broadband. You can succeed with dialup, though it is more drawnout and a fair bit of patience is needed. If using dial up, you will likely wish to make the larger downloads (approx 40MB) overnight. Ask on the Wine Developer mailing list for suggestions of which dlls are likely to be involved with your regression and check those patches first, otherwise regression test by date. [update, since Sept 06, the official documentation now refers to using GIT for regression testing]. The first time you compile wine, takes the longest. Subsequent times are much faster, as not everything will be re compiled. How long does it take? Rayhen [ Oct 07] On modern hardware regression test will took about 20-40 minutes (time depends on how big "window" of your regression test). On old hardware it will took more. If for some reason you cannot do regression test please fill bug report "as is". This is better than nothing and will take just a few minutes. However if you do regression testing, you will help yourself even more by assisting the developers who can quickly fix your problem.


Further Reading


Hiji [Jun 05]: Here's what I usually do:

  • rename the ".wine" folder [located by default in your home directory] to something else like ".wine-old"
  • go into the source code directory of the current wine install, and "make uninstall" to remove it
  • on the new version, use the "wineinstall" script provided with the source code to install it. [See the readme for details]
  • test
  • if it doesn't work, "make uninstall" newer version and remove the ".wine" folder it created
  • Anon: Start wine by using winecfg
  • on the old version, use the "wineinstall" script provided with the source code to reinstall previous version
  • delete the ".wine" folder just created, and rename ".wine-old" to ".wine"

It's pretty clean and quick to reinstall previous version since it's already been compiled. Wine Archive

The [ed: preferable] alternative is to run wine from it's source tree. This was described in Bug 1947 Aug 07: Call the wine binary out of your git directory, ie:

$ ~/wine-git/wine /path/to/app.exe

It makes git bisect easy and it's faster with not having to do "make install" first.


[Ed[ Dont worry about Fixme messages too much as these are not usually a sign of what broke. A fixme message is a note by a developer where something can be improved in the future, but as applications do not seem to rely on the behavior it will be done later.


Further Reading


[edit] How far can I go?

Testing should be done early, so that the programmer has the work fresh in his mind, and can quickly design a fix. Testing each version of Wine is Highly Recommended. It's probably not fruitful to go back more than 6 months or so - despite the developers best efforts there are some breakages in the Wine tree, and you're very likely to end up with something that doesn't work out of the box. The problems you'll encounter if you try are of course fixable, but:

  • There is no central place where the Wine project maintains hotfixes for older versions, and
  • As wine has yet to reach version 1, the Wine developers do not yet list patches for backports.

If you do try to go farther back, you can

  • Search the mailing lists for relevant material, obviously, or
  • In case you can drill down to a single file or directory that's causing you problems, use:
svn log <filename / dir name>

to view patches relevant to any particular file or directory. Both is laborious, so if you do not have a time, going back further than 6 months is not for you.

A user tried to build an old version and in the discussion the following comments were found: S. Petreolle [May 06]: [wine] 2004xx or 2005xx are very old, and the whole configuration methods did change since it reached the 0.9.x stage.

W. Ogburn suggested when attempting to go back to very old versions: "make depend" and the "make" separately, so you know which one is the problem

J. Huizer: you should really get a known-good source (like one of the tarballs from winehq.org) one suggestion if you want to try more on the source you're using now - it sometimes helps to do a 'make distclean' and restart building, if you didn't clean up after the last compile error - though normally that happens at link time -- these errors are really at compile time, so I wouldn't bet on it wine archive

[edit] Using CVS for regression testing

Because Wine now uses GIT this means CVS is less recommended and may not be supported in future. However, with some work GIT can pretend to be CVS so this is not certain. While you can still use what ever you feel you are comfortable with, GIT is preferred. That said, CVS is the old friend in the corner. It is very common and you used to be able to use it for regression testing without much ado. Because it is so common, there are many users who should be able to help with questions posted in the wine-users mailing list

CVS or Concurrent Versioning System allows multiple developers the wine project to centrally store the many different versions of the code for Wine. A. Julliard holds the keys to this server and every time he accepts a change it is stored on the server, and the server assigns a new version number to the files that were altered. You can at any time retrieve older versions (which allows us to find when mistakes crept in) and it can show the differences between versions. CVS is designed to allow multiple developers to work on different parts of the same file at the same time, which is what is meant by concurrent. The system automatically merges the files if possible, or reports a conflict which is then resolved by hand. What is important for those wanting to do regression testing, is that it often enables non technical people who are willing to use the command line, to find who and what caused the breakage with wine.


In the example below you will have a folder in your home directory called "wine" which will contain the wine tree. After using the commandline to "cd" into where you stored the Wine tree, you can then use the other cvs commands.

Further Reading

[edit] Using CVS to obtain a complete wine tree

D. Clark: The easy way to use CVS is to: 1 Create the file ~/.cvspass ('~' refers to your home directory) containing the single line: 

:pserver:cvs@cvs.winehq.com:/home/wine Ah<Z

2 Create the file ~/.cvsrc containing three lines (using your favourite editor): 

cvs -z 3
update -PAd
diff -up

3 Type the command in a terminal window: 

cvs checkout wine

Assuming a reasonably fast internet connection, you should have a complete wine tree in a few minutes.


[edit] Using CVS to Check Patches

[based on advice and information for a bug report (link below) by D. Clark] CVS can go back and forward in time easily. If for example the 20050111 version is ok and the 20050419 version is broken, pick a day midway between those two, and do a CVS update: 

cvs update -D "2005-02-27 CDT"

Compile that and see whether it is broken. If it is, pick a day midway between then and 20050111 (Jan 11 2005). If not, pick a day midway between that and 20050419. You should be able to narrow it down to a particular day fairly quickly. Once you have narrowed it down to a specific day, then review the patches for that particular day here http://www.winehq.org/pipermail/wine-cvs/ and pick a patch roughly in the middle. For example, on the Jan 14 2005 it looks like the one with the time stamp of "Fri Jan 14 2005 - 10:09:34 CST" is roughly in the middle. So you could execute the command: 

cvs update -D "2005-01-15 10:09:00CST"

Since the January patches use the "CST" timezone, be sure to use that when running CVS or the results will be confusing. You can then shift the time back and forth to find the exact patch that caused the problem. Once you use the commandline to "cd" into the Wine tree, you can just execute the cvs update commands.


D. Navea had difficulty with getting CVs to update backwards [Nov 05]: follownig the instructions on the regression testing page... The instructions are quoted with (aka double quote), but for my cvs to do it, it has to be ' (aka single quote). wine archive

[edit] Using your Brower to view CVS Commits

D. Calvio [Dec 05]: The wine-cvs archive mailing list linked in the documentation is http://www.winehq.org/hypermail/wine-cvs This archive ends in August 2005. I think the archive linked should be http://www.winehq.org/pipermail/wine-cvs/

J. Hawkins [Dec 05] pointed out that the pipermail list has changed and now has the entries relevant to GIT. To check the entries for CVS : http://cvs.winehq.org/cvsweb/wine

[edit] Troubleshooting using CVS

Why does the 'cvs login' command tells me this:
cvs login: can only use `login' command with the 'pserver' method
cvs [login aborted]: CVSROOT: /home/chimi/wine

D. Clark: I think that the step you missed was that you need to "cd" into your top level Wine directory. Once you are there, the CVS commands will figure out that you want to operate on that CVS tree.

Where do I define my wine repository?
Your "repository" is the Wine tree you already downloaded via CVS

where do I define the cvs server

This was defined in ~/.cvspass. Once you cd into the Wine directory, CVS will know the correct server to use.

why does the 'cvs login' command tells me this

You don't need to do a cvs login. The ~/.cvspass does this for you. Once you cd into the Wine tree, you can just execute the cvs update commands.

How do I locate the next patch

D. Calvio [Dec 05]: the date [shown in the patches] isn't the CVS commit date. Instead, it is the Git commit date (or at least I think so). The Git to CVS gateway seems to get some time to commit the changes to the CVS. So I don't know how can I get the exact patch that caused the problem.

I'll try to explain it with my problem. When I update the CVS to "2005-12-21 21:29:02 +0100", the game runs perfectly. However, if I update the CVS to "2005-12-21 21:29:03 +0100", it crashes. However, looking in the [git] mailing list, there are no commits at "2005-12-21 21:29:03 +0100" (the previous was made at "2005-12-21 21:19:47 +0100").

M. Meissner: There is a CVS commit that has:

revision 1.24
date: 2005-12-21 21:29:03 +0100; author: julliard; state: Exp; lines: +2 -0
msvcrt: Implemented wctime(), wasctime().
Free thread data in DLL_THREAD_DETACH.

So you are looking for this:

Its likely that there is a delay between the GIT commit and the CVS integration.[...]([In this case] 1 hour before approximately)

J. Hawkins [Dec 05] pointed out that the pipermail list has changed and now has the entries for GIT. To check the entries for CVS : http://cvs.winehq.org/cvsweb/wine

M. Meissner: [to examine the] log for a file [write on the command line]:

cvs log file.c

to see diff between dates wine archive:

cvs diff -u -D "time1" -D "time2"


The command should be invoked in the directory which differences want to be seen, so to see all the differences in the CVS it should be invoked in your wine root directory. This command also outputs what directories are being checked. This information can be annoying, and can be ommited to get only the diffs with the -Q option:

cvs -Q diff -u -D "time1" -D "time2"

Once a difference between two revisions of a file is shown, you can get the associated patch information looking for the newest revision of the file in the log command for this file. And when you have the patch information, simply look for it in the git mailing list.

Cannot find module
A programmer reported during regression testing [APR 06]: [I] want to checkout for the patch submitted 05:20:20, I run the command: 

[redacted]@r32_1600$ cvs -d $CVSROOT checkout wine "2005-09-21 05:20 CDT"

which ends up returning:

cvs checkout: cannot find module `2005-09-21 05:20:20 CDT' - ignored

I would like to be able to determine which patch specifically is responsible. Any help with CVS would be useful here.

S. Leichter wine archive:

export CVSROOT=:pserver:cvs@cvs.winehq.org:/home/wine cvs -d $CVSROOT checkout -D "2005-09-21 05:20 CDT" wine

How do I apply or remove a patch
If you sent a bug report and a developer asks you to test a patch, here is how:


To apply a patch, use a command like: 

patch -p0 < patch.diff

To reverse a patch: 

patch -p0 -R < patch.diff

The "-p0" can differ depending on how the patch was formed. For example, the patches in CVS generally require "-p1" instead of "-p0". Read the patch man page to understand what that is doing.

[Then recompile wine...]

further reading

[edit] Using Subversion

Consider Subversion if you are familiar with it, or feel like trying something different.

[edit] Using Subversion to obtain a complete wine tree

M. Bestefich: I'd do it like this:

  • [step 1] Download + Install Subversion
  • [step 2] If the bug appears in 20050930 but not 20050211, I'd check out something in between - there's 231 days, so say 20050606. Run:
svn checkout --revision "{2005-06-06}" svn://wine-svn.troy.rollo.name/wine/wine/trunk wine-svn
  • [step 3] CD into wine-svn and run
./configure
make depend
make
make install
  • [step 4] Test if your app works.
  • [step 5] If it works, adjust the date forward by 50% of the days in between (say, 57 days, after the first iteration). If it doesn't work, adjust the date backwards by 50%. Then run
svn update --revision "{...date...}"

and go to step 3.

With 231 days in between, you will do a maximum of 8 iterations, then you'll have your bug pinpointed to a day. There's usually ~50 ? patches a day, so you'll want to list them:

svn log --quiet --revision "{2005-06-06}:{2005-06-07}"

lists patches from June 6th, 2005.

Pick a patch in the middle and run (example)

svn update --revision 20664

(the correct number will be in the output of the 'log' command). Iterate a few times more and you'll soon have the exact patch that breaks things.

Then it's time to go ask the developers what's going on. Or look at the log entry with svn log --revision XXX and go ask the guy that's mentioned in the log entry what the devil he was thinking.


[edit] Offline Subversion

If you have limited access to the internet you could ask Troy to zip up the SVN repository (either a couple of database files or ~23.000 revision files, depends..), dump 'em in a directory on your local pc and run 'svnserve --daemon .' in that directory. After that, point your working copy to your local repository (svn://localhost/). Then you'd be able to take a brisk walk back and forth in Wine versions without being on the 'Net.


[edit] Using GIT for Regression Testing

Git is the new kid on the block. It has specialized commands to simplify regression testing and help you find a bug. Since A. Julliard moved wine's development into git toward the end of 2005, it's popularity with wine's developers has increased.

M. McCormack [Nov 06]: It's much easier to use Git for regression testing. It will give you an exact commit ID which you can put in your bugzilla report.

P. Romanyszym [Nov 06 Wine user]: Using your package manager (RPM or APT) it would be difficult or impossible to set up different installed versions. So to run different versions you need to compile from source and run from the source tree of each version. Once you set up the required tool chain to compile you can do regression tests.

Finding regressions takes time to compile but that can happen in background while are using your system. Start with getting the Git tool working.

Once it is working from the wine source directory you can use the following to update your source to latest.

git-checkout -f
git-fetch

in the wine Source directory run ./configure --verbose It will spit out what is missing. Using that info find and install the missing libs.

Then to compile your source use:

./configure && make clean && make depend && make

See the official link regarding regression testing using bisecting http://wiki.winehq.org/RegressionTesting

Dimesio wine user aug 08: If you got the message "0 revisions left to test" that means you have to run it one more time.

Further Reading

[edit] Regression Testing using GIT

Git has a tool to help regression testing called bisect

M. Finagin [Sept 06]: What I do is to follow along with things on the shortlog:http://source.winehq.org/git/?p=wine.git;a=shortlog

Lets say you want to move your current branch to my recent patch "riched20: Rewrite of scrolling and some redrawing code." - you'd click the link "commit" to the right of it. In the page that you'll be taken to, you'll see a line like this: commit abecd9e393925e008449a80ec14682790b29042c

you can then do a "git reset --hard abecd9e393925e008449a80ec14682790b29042c"

and your git will be moved to the point in time right after that commit. If you then want to manually apply a patch, click "commitdiff" to the right of it's entry in the shortlog, followed by "plain" on the top - this will take you to a plaintext diff of the patch, which you could save to a file and apply with the patch command. ("patch -p1 < thepatch.diff" usualy works well for me)

M. McCormack [Sept 06]: There's easier ways to do the second bit.

  1. Use git cherry-pick
    git branch master-20060913
    git reset --hard abecd9e393925e00
    (#examine the log for commits)
    git log master-20060913..abecd9e39392
    (#pull in commits)
    git cherry -r 112810a480aaee4d6d8
    git cherry -r aaca30cf039c227e
    (#etc)
  2. Use git format-patch to get all the patches in the tree before
    resetting:
    put them all in one file named mb)
    git format-patch --stdout abecd9e39392 > mb
    or create multiple files)
    git format-patch abecd9e393925e008
    Then reset (remember to have a clean tree!)
    git reset --hard abecd9e393925e
    Then edit "mb" and "git am" the patches you want:
    git am mb


You don't need the full SHA1 ID... just enough to make it unique in the tree. wine archive

[edit] Multiple Processors and Git

From the Git Mailing List

Q1:if you have a multiple core computer, can't you make git build new versions in the background while testing the previuos version? Alright, if you build 2 versions, one of them will never be tested, but you will perhaps save some time by letting it build in the background?

A1Yes, you can do that. If you have cloned your repository twice (or more), then you can bisect compile and test at the same time in your 3 repositories (or more if you really want).

For example if bisecting in one repo asks you to test revision X, then you can bisect and then build (and even maybe start testing) in another repo assuming revision X is good, and in yet in another one assuming revision X is bad.

(In the repo where you assume X is good you use:

"git bisect start CURRENT-BAD X"

and in the third one, where you assume X is bad, you use:

"git bisect start X CURRENT-GOOD")

A2 In fact, you have to give all the good revisions you have, not just the last one. So it should be

"git bisect start CURRENT-BAD X GOOD1 GOOD2 ..."

or

"git bisect start X GOOD1 GOOD2 ..."

instead of the above.

> When you know that X was good then you can kill the build or test processes and "git bisect reset" in the repository where you assumed

> wrongly X was bad. You can then assume something else with "git bisect start B G" and build and test in this repo again.

Above also you must give all the good ones, so it is:

"git bisect start B G1 G2..."

> In the repo that told you X was good, then you need only to use "git bisect good" or "git bisect bad" without building and testing to assume

> something about the revision that should be built and tested.

A3: Adding parallelism to a binary search scales very badly -- I'd say about logarithmically, but I haven't thought hard about it. If it's possible to use the extra cores to speed up the build+test cycle, that's vastly preferable.

A4: Probably logarithmically with the number of cores. But for reasonable machines, this number is relatively low, so the log is not so costly.

[edit] Applying a patch using GIT

A user asked: I add [a patch Diffed against 1d40bf0141b7f67b1188555962698f5dab631bc3] to to my local wine copy, using git ?

Krasuckus: I'd make some experimental branch or "master" or defined commit, then patch it with given diff, and commit the changes under single name. [One of the benefits of GIT is that is easily allows you to make throwaway branches]

  1. download the patch
    $ bunzip2 --keep origin_sd1.diff.bz2
  2. Use GIT
    $ git branch ntoskrnl 1d40bf0141b7f67b1188555962698f5dab631bc3
    $ git branch
    $ git checkout ntoskrnl
    $ git branch
  3. [...]instruct git to add [the] newly created files [to the throwaway branch]
    $ cat origin_sd1.diff | patch -p1 | awk '{print $3}' | xargs git-update-index --add
    $ tools/make_requests
    $ git commit -a -m "ntoskrnl: Experimental implementation."
  4. recompile Wine
    $ ./configure && make depend && make && tools/wineprefixcreate
    --use-wine-tree .
    • below goes your experiments
    $ ...
  5. and here we go back to the normal tree [Returning to the Official Wine tree]
    $ git checkout master
  6. recompile Wine
    $ ./configure && make depend && make && tools/wineprefixcreate
    • use-wine-tree and do our stuff
    $ ...

M. McCormack: If the patch is created with "git format-message" [instead of using git commit -a -m....], you can use "git am origin_sd1.diff" to add it to your tree. 'am' applies a mailbox, which is a series of patches and their commit info.

J.W. Stolk: I noticed [in these instructions] that the typical "make install" is missing. I ran ./wine-git/programs/winecfg/winecfg and it seems to work ok. I found more info about this in an old Wine newsletter: http://www.winehq.com/?issue=269#Speeding%20Up%20Builds And a script to setup the correct wine variables without installing wine. General_Developer_Information#Running_Wine_from_its_source_tree wine archive

[edit] Compiling Wine

After noting some have difficulties in recompiling M. Meissener said the correct sequence is : 

make clean
cvs up 
./configure ...
make depend
make

[because] After [a] "cvs update" it no longer new how to clean the tree. Wine Archive

R. Jensen explained [Oct 05] why make clean is sometimes necessary: it does make the build take longer, however, if the makefiles are altered it's too late to 'make clean' after_ the cvs update. [...] The other suggestion to this error was to delete the entire tree and pull an new CVS down from the net.

As you get closer to finding the bug, you could quickly check over wine patches for makefile changes so as to avoid using make clean unless really necessary. These changes are not very common but do occour.

To see what "make clean" would delete (hopefully without actually deleting anything) try: 

make clean RM='@echo would-rm'


Further Reading

[edit] Dependencies

It may seem hard to get all the parts of wine that are needed to compile wine, but that is not necessarily true. Install a Wine source package and remove it and then you should have all the dependencies already set up.

If you are really stuck, then carefully check the configure error messages and keep installing the packages that are listed as needed.

Further Reading

[edit] Using ccache

McCormack: [Aug 05]:[using CVS until you find the problem] is the best way to find the problem. It's not as bad as you think, especially if you use ccache and a binary search. 

CC="ccache gcc" ./configure

Additionally, the search gets faster and there's less re-compiling as you narrow it down further. If you know the problem is only in the comctl32 code, you might be able to regress that only...Wine Archive

Further Reading

Jun 08 wine user posted his error from configure which showed how he used ccache: 

Rob@Office:~/wine-git$ CC="ccache gcc" ./configure --verbose 
checking build system type... i686-pc-linux-gnulibc1 
checking host system type... i686-pc-linux-gnulibc1 
checking whether make sets $(MAKE)... yes checking for gcc... ccache gcc
checking for C compiler default output file name... configure: error: C compiler cannot create executables

A. English: You need lots of dependencies, namely, a compiler. Look at: hhttp://wiki.winehq.org/Recommended_Packages

TlarchicesL You are compiling using ccache : 

CC="ccache gcc"

You will need to install the ccache package in order to use it. (And this package is not in the recommended packages list as it only appears in the bisection explanations) Of course you will still need all the other packages from the wiki page.

[edit] Avoiding compiling Tests

If you are new to regression testing, you might not worry about this more advanced trick as it suits those who do regression testing regularly.

update2 Since Nov 21, configure has a new option: configure: Add a --disable-tests option to avoid building regression tests. Since Nov 21 2008 you can disable the tests when you are compiling wine for regression testing. Of course if you wish to do any development you would most likely need to be running those tests before submitting any pat


D. Kegal [Dec 07 wine devel] Lots of the time in regression searches is spent compiling tests, but when you're only going to run the app that's breaking, that's not too useful. How does one disable compilation of conformance tests?

M. Lankhorst: Try my hack: [broken link]

You need to do autoconf after applying, then build with configure --disable-tests.

update1. This is now covered in the official wine wiki under Disabling Tests to Speed up Compliation, download the file disable_test_new.diff and check the instructions here: http://wiki.winehq.org/RegressionTesting ches.

[edit] Avoiding Make Install

A wineuser Aug 08 psoted: I compiled wine 1.2.2 from git as per instructions on the AppDB page, applying a patch to wine.[..] I am wondering, I have a wine-git folder as I just compiled it[...] [to run cc3.exe]

jeffz: If you build wine in your wine-git folder, you can then use that compiled version by specifying it on the commandline such as: 

cd ~/.wine/drive_c/CC3
~/wine-git/wine cc3.exe

The user clarified Aug 08 wine user: so I would leave the existing wine install alone, and just rebuild wine-git with the patch I need and run CNC3 as you indicated?

A. English: Yes

I'm quite new to the compiling process so for my sake, "make depend && make" is what actually makes wine, and sudo make install just installs it into the system with links and such? So I can just do the make depend && make [..] right?

A. English: Yes

Vitamin Aug 08 wineuser: The best way to no not overwrite your current version is to not install your compiled version at all. But rather running it from the compile dir. The only side affect is you have to specify [the full] path to "wine".

[edit] Reporting Regression Tests

Originally regressions were posted to the Wine developer list but this has changed as noted by M. McCormack Nov 06: the right place to report bugs is http://bugs.winehq.org

When you have found the patch involved, bugzilla can be your friend. It is there you can enter all the gory details and upload screenshots. D. Navara is the hard working maintainer of bugzilla - he or another bug hunter will likely contact your for further information about the bug.

Because the developers are already working on plenty of bugs, when posting a bug you can make the life of a developer easier by including important information:

  • Subject with small description of the bug including the word 'regression'
    (try to let them at least know if it's a DirectX issue or an ntdll one, as developers working on the former would probably not be interested in bugs related to the latter)
    • To demonstrate the regression - screenshots are very helpful
  • The patch that caused the regression (and its' contributer)
  • The program that experienced the regression - and a link for a developer to download it (if possible)
  • quick analysis of the problem (if you can)

A quick caution: If you have a long trace or screenshot, make it an attachment (Busy bug zappers should not need to download a 1Gb page to read your post).

With that information a [busy] developer reading [the bug] will know whether it's worth digging deeper and actually look at the bug report and patch. Wine Archive Link

Even if the original developer does not see the message, with this information others will. M. Stefaniuc explains: Regressions bugs are quite interesting especially if the culprit patch is already known.

Sometimes a note may be made to the Developer Mailing List, wine-devel as shown in February 2007. What is interesting here is how the bug report made use of git to describe the exact commit: A. Pignotti: I've noticed that commit 12252d058914a66f40e976484cc7d8aa52ffca47 on the git tree causes a regression in the sims, making characters flipped upside down. It's seems to me that the y axis is flipped. I hope this helps

The developer involved quickly replied: Oops [...] Is there a demo for this game I could use to debug this? [wine devel Feb 14 2007]


Further Reading

[edit] Regression Test Example

Finding and indentifying a March 2003 Visual Regression with Internet Explorer: Wine Archive Link

Total Time taken: A couple of hours with an AMD 1.8Gh
J. Hoizer: Internet explorer was installed using winetools, some months ago, in a clean ~/.wine tree (so nothing else messed with registries). I kept [the] installed internet explorer untouched, and used the wine in the build tree (without any system-wide installed wine, just to be sure the right wine version was running)

Whilst working on other things (when waiting for compiling to finish), he then did:

  1. cvs update to 15 march, compiled with ./configure && make depend && make
    • Ensured it was ok,
  2. then cvs update 19 march (middle between 15 and 23).. then.. 21 then... 23
    • At compiling 23 CDT the regression was not there yet;
  3. Updated to 24 CDT and recompiled - just in case, confirming the regression was really there.


Armed with this information, J.Huizer posted to the List: 

Okay, I found the regression happened some time on 23 march:
  cvs update -PAd -D "2005-03-23 CDT" doesn't have the regression
  cvs update -PAd -D "2005-03-24 CDT" has the regression
Now how will I be able to find exactly what's causing it? Can I download the individual patch files of that date somehow?


H.Valtonen:You can update by time as well as by year/month/day. Just look at the wine-cvs list archives for potential times to update to. eg: 

cvs update -PAd -D "2005-03-23 16:00"


P.van Schayck: http://www.winehq.org/hypermail/wine-cvs/2005/03/index.html shows all the cvs patches. I would try the comctrl patches from the 23th. Not things like winealsa (which are sound related). [Ed. since the update to pipermail The cvs patches are now available here http://www.winehq.org/pipermail/wine-cvs/2005-March/date.html. While pipermail does not display the dates, it does list in date order. An alternative is gmane.comp.emulators.wine.cvs using your favorite newsreader]


Because of J.Huizer's hard work identifing the patch, the developer was able to quickly check his work and found a possible fix:

Wine Developer (Rob Shearman, the very next day):Thanks for narrowing the regression down. Does the attached patch help?


J.Huizer:After applying the patch IE draws its bar normally again :) ...

Thanks.

[edit] Troubleshooting

A developer [May 06] upgraded to fedora core 5 (from fedora 3) In my old system i had about 20 wine-versions (back to april 2004) installed which was great for tracking down regressions. Trying to compile older wineversions now on my new installation fails with various errors (like wine-20050419 fails with error:

union <anonymous> has no member named a_ptr)

Even wine-0.9 (first beta release) won't compile anymore. I guess that's due to newer gcc/glibc versions. Is there a (easy) way to get older wine-versions compiling again?

P. Beutner[May 06]: identify and porting the necessary changes back is probably the easiest way, atleast easier than installing another glibc ;) Assuming you are using git:

  1. create a new branch 'v0.9' starting at version 0.9 git checkout -b v0.9 wine-0.9
  2. fix for the flex issue(needed for wine < 0.9.10) git cherry-pick -r 69dcbaaf93a65820a28fe2485b6d15a90f423899
  3. fix for undefined CLK_TCK (needed for wine < 0.9.1) git cherry-pick -r 5c256c518faf2344266cabecad9fdbfd9d0095ad

Thats all you need atleast back until 0.9. I never tried anything older.

As for the error you mentioned:

$ git log wine-20050419..upstream | grep -B4 a_ptr commit 2b6e7dad58833b0e4bf3a05c8ae2de3542728c2e Author: Marcus Meissner [email redacted] Date: Thu Jun 2 10:30:08 2005 +0000 Elf32_auxv_t.a_un.a_ptr no longer exists in HEAD glibc CVS, use

so I guess you want that commit too for wine-20050419.wine archive

M. Bestefich:

  • any Wine before 2004-01-02 won't work because it won't compile against newer ALSA versions.
  • any Wine before 2003-12-01 needs patches to the build system before 'make depend' will even run.

[...]I've managed to fix the above two. They're really simple things. [Ed. Link includes discussion on older versions of wine] Wine Archive


[edit] Wine Links

Retrieved from "http://wiki.jswindle.com/index.php/Wine_Regression_Testing"
Personal tools