May 2008 - Wine-Devel - list.winehq.org

Steampowered.com has sent me ~10 e-mails

by Brian Fuller

I've gotten ~10 e-mails from steampowered.com regarding this issue. Everyone of them is virtually nothing but quoted information. I had TF2 crash on my computer, then I went back in, snagged the memory dumps and submitted them to steampowered.com, told them I was on the wine list and I needed better DLL support from Nvidia. Once they established that I had the advanced guide for myself, and I continued to procede by telling them: After running Steam and opening TF2, download initializes from server correctly, as connecting to server system goes down. kern.log: Apr 30 09:51:17 slinker-desktop kernel: [52605.857549] totem-plugin-vi[20091]: segfault at 4 rip 411a15 rsp 7fff5f4cb3e0 error 4 Apr 30 09:51:17 slinker-desktop kernel: [52605.934792] totem-plugin-vi[20089]: segfault at 4 rip 411a15 rsp 7fffaea1a930 error 4 Same two error messages in messages ----------- Next: Brian, Thank you for submitting these minidumps. If you continue to experience problems with game crashes, please complete the steps in the link below. Title: Troubleshooting Game Crashes Link: http://support.steampowered.com/kb_article.php?ref=7169-TIAV-5361 ------------- I'm not sure if this helps, but I was working on WineHT.dll at the same time, and maybe some sort of mis-interaction on the level of an application running on my operating system with your product could've resulted in the crash? I was just hoping with the specific information on those memory locations perhaps you could provide me some knowledge of the Windows/DirectX API that deals with these particular switches, as to enlighten me towards my game not crashing in the future. Sorry to complicate the issue :\ -BAF ----------- they responded with nothing but quotes Now I'm trying to differentiate on an iron curtain the color differences being generated by heat being applied using nothing but a router. Figuring out why it corrupted those packets would be accessed in the API, then put into the CPU, calculating this. Once you've calculated the color differentiations throughout the sheet, you could re-draw this sheet in 3d with the right colors using OpenGL. That's the goal at least. The important part being the edges between the different colors. They finally closed the ticket today. -BAF P.S. Just have a seat, I'll be right with you with valid code.

May 4, 2008

Re: winetest problems

by John Klehm

On Fri, May 2, 2008 at 6:38 PM, James Hawkins <truiken(a)gmail.com> wrote: > Hi, > > I'm trying to fix the failing cross tests, but we haven't had a > winetest build on Paul Millar's server in a few days. I'm not > familiar with Paul's build process, so my only guess is that a recent > commit has broken the build. In the meantime, I've tried a few > things. > > I used John Klehm's crossbuild_tricks script [1] to build winetest. > The build succeeded, but the submitted result [2] is empty or can't be > parsed. The script was errantly depending on my old exception noop patch. I've updated it to work with a clean wine-git. Updated script version 20080503: http://klehm.net/wine/crossbuild_tricks.sh Test results from 0.9.61 my winxp box: http://test.winehq.org/data/c6da2a0b9daa8bdba045559b057ccf43ea2209c7/ Note for anyone testing on server 2k8: test data will not submit to winehq. winetest just aborts after clicking yes to "submit test results". Ideas anyone? --John Klehm

May 4, 2008

Re: [PATCH 1/3] headers: add CM_Reenumerate_DevNode, CM_Locate_DevNode prototypes

by Dmitry Timoshkov

"Dmitry Timoshkov" <dmitry(a)codeweavers.com> wrote: > From: "Vitaly Lipatov" <lav(a)etersoft.ru> wrote: > >> +#ifdef UNICODE >> +typedef DEVNODEID_W DEVNODEID; >> +typedef DEVINSTID_W DEVINSTID; >> +#else >> +typedef DEVNODEID_A DEVNODEID; >> +typedef DEVINSTID_A DEVINSTID; >> +#endif > > Wine headers do that differently. Please ignore my comment, WINELIB_NAME_AW won't work properly in this case. -- Dmitry.

May 4, 2008

Re: [PATCH 1/3] headers: add CM_Reenumerate_DevNode, CM_Locate_DevNode prototypes

by Dmitry Timoshkov

From: "Vitaly Lipatov" <lav(a)etersoft.ru> wrote: > +#ifdef UNICODE > +typedef DEVNODEID_W DEVNODEID; > +typedef DEVINSTID_W DEVINSTID; > +#else > +typedef DEVNODEID_A DEVNODEID; > +typedef DEVINSTID_A DEVINSTID; > +#endif Wine headers do that differently. > +CMAPI CONFIGRET WINAPI CM_Locate_DevNodeA(PDEVINST,DEVINSTID_A,ULONG); > +CMAPI CONFIGRET WINAPI CM_Locate_DevNodeW(PDEVINST,DEVINSTID_W,ULONG); > +#define CM_Locate_DevNode WINELIB_NAME_AW(CM_Locate_DevNode) > + > +CMAPI CONFIGRET WINAPI CM_Reenumerate_DevNode(DEVINST,ULONG); > +CMAPI CONFIGRET WINAPI CM_Reenumerate_DevNode_Ex(DEVINST,ULONG,HMACHINE); You need to add the prototypes when you add implementations. -- Dmitry.

May 4, 2008

Re: wineserver socket file and DOS attacks

by Steven Elliott

On Thu, 2008-05-01 at 06:45 +0200, Ove Kaaven wrote: > Maarten Lankhorst skrev: > > Wine checks ownership of the socket and directory, so race conditions > > aren't really a problem. This means that despite being put in a public > > directory there is no chance of a race condition. I don't see a > > security risk here, if someone is evil they could create that > > directory so wine wouldn't run, but that harm is only restricted to > > 'wine does not start'. > > Which is exactly what the OP was concerned about. You are correct that that is my concern. I just want to say a few additional things about this and then I'll leave it be since I think I've made my point. I've thought a little bit about how multiple directories could be used as a way working around the DOS attack (as I mentioned in my initial post). I think it is really hard to address every possible race condition (wineserver just starting up or shutting down as a new wine process is trying do decide which directory to use and or whether to start a new wineserver). I think Maarten touched on these race condition concerns with his "The latter won't work ..." email in this thread. To add to the confusion the /tmp directory on most Linux systems is subject to a cron job that deletes old files. I think the only perfectly robust way of doing this that isn't vulnerable to either DOS attacks or race conditions is have a permanent directory for each user that wants to use wine that is both owned by that user and is writable so that the socket file can be placed in it. At one time this was ~/.wine. So, what if the socket file was moved back under WINEPREFIX (defaults to ~/.wine) combined with the following requirements for users that don't have writable home directories the first time wine is run for that user: 1) Some new directory is created for the user. 2) The new writable directory is chown'd to the user. 3) WINEPREFIX is set to point to the directory. 4) wineperfixcreate is run. /etc/rc.d/init.d provides various examples of services that are run as users that don't have writable home directories but that do require a one time setup. For example, if "foo" is some service that uses wine then /etc/rc.d/init.d/foo would create /var/lib/foos-wine-dir if it didn't exist and then apply the above steps. You can also consider the SSH example where the ssh-agent process (analogous to wineserver) is started, some tempnam() like API is used to pick a random place for the socket file and then an environment variable (SSH_AUTH_SOCK) points to the socket file that must be inherited by each shell where SSH clients that want to talk to ssh-agent are used. But I've always thought having to deal with SSH_AUTH_SOCK was a pain (I know most distros set it for you when you are logged in at the console, which helps). Maybe I'm making some bad assumptions about why the socket file can't be placed in ~/.wine (that not all users have a writable home directory). I'm guessing based on the snippet from my original post that includes "Since that might not be possible" in reference to placing the socket file under ~/.wine. This made me curious what happens when ~/.wine is not writable. I did a "chattr +i" on the ~/.wine directory of an ordinary user in order to make every file immutable. Things pretty much work except wineserver complains when it exits that it can't write the registry changes to the *.reg files. And as one might expect the registry actually does not get updated. But other than that it kinda works. -- ----------------------------------------------------------------------- | Steven Elliott | selliott4(a)austin.rr.com | -----------------------------------------------------------------------

May 3, 2008

X_BOOL, X_BYTE, X_INT8, etc.?

by Andrew Talbot

In xlldrv.h, various scalar types are redefined, for example #define BOOL X_BOOL If these "X" variants exist on my system, they are not being included in xfont.c. Where should I find them, please? Thanks, -- Andy.

May 3, 2008

Re: Possible Regression in 3Dmark 03 in win2000 mode

by Stefan Dösinger

Am Samstag, 3. Mai 2008 12:52:43 schrieb Steven Edwards: > Hi, > Sorry to spam wine-devel...I don't have the time to file a proper bug > report right now and I did not want to waste my time if the directx > guys were aware of it and working on it but 3DMark03 is crashing for > me in wn2000 mode while it functions in win98 mode. This is a > regression and a new bug, it would be nice to have as many benchmarks > as possible working so when 1.0 ships we can compare results to > windows. I'm not really aware of this, and I currently have little time to work on this(University keeps me busy). A regression test would be helpful.

May 3, 2008

Re: WineD3D: RemoveContextFromArray fix (fixes bug 12924)

by Stefan Dösinger

Am Samstag, 3. Mai 2008 20:23:17 schrieb Roderick Colenbrander: > Hi, > > RemoveContextFromArray forgot to check the last element in the array. This > led to memory corruption (bug 12924) where wined3d started removing a > pbuffer where none was created at all. This patch fixes it. The original > bug was spotted by Peter Oberndorfer and for him a similar fixed some other > program not sure which. Maybe a comment would be helpful, reminding the reader that This->numContexts was decremented already and thus the <= is used. It took me a while to figure that out when reading the patch

May 3, 2008

Re: Fix building tools/widl (for bison 1.75, among others)

by Gerald Pfeifer

On Fri, 2 May 2008, Robert Shearman wrote: >> It turns out that current versions of bison do not enforce the documented >> grammer as strictly as older ones such as bison 1.75. Fixed thusly. > Oops, thanks for spotting it. Actually, I was developing on version 1.28 > and didn't get those errors so it doesn't appear to be a deliberate change > by the bison developers. This is interesting. Possibly the bison developers got feedback that the stricter checks in 1.75 caused to many troubles (even though they were correct per se)? > Looks good. Please send to wine-patches. Oops. Originally I wasn't sure how to address the problem, so I started this e-mail to wine-devel and then failed to adjust the address once I had an actual patch. Thanks for spotting this -- the patch now made it into this week's release. :-) Gerald

May 3, 2008

Five functions that cannot handle a NULL parameter

by Andrew Talbot

In case anyone wishes to note or fix them, here are five functions that are being called with a NULL parameter that they cannot yet properly handle, and which they are passing down to a str...() or mem...() function. I may be wrong, but I don't think these have been caught by Coverity. The number in the brackets is, of course, the parameter affected. advapi/security.c:LookupPrivilegeNameW(3) dbghelp/stabs.c:stabs_pts_read_type_def(2) gdi/freetype.c:WineEngGetOutlineTextMetrics(3) msi/table:get_tablecolumns(3) setupapi/devinst.c:SetupDiGetDeviceInstanceIdW(3) Cheers, -- Andy.

May 3, 2008