August 2005 - Wine-Devel - list.winehq.org

Possible critical section bug - lock by invalid thread

by Alex Villacís Lasso

In several RPG I have been testing, I have found deadlocks on the sound thread - the sound loops on and on, and the program freezes. At the same time, I see messages like the following: fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x7fe32708)->(00010022,00000008) err:dsound:DSOUND_MixOne underrun on sound buffer 0x7fe82310 err:dsound:DSOUND_MixOne underrun on sound buffer 0x7fe82880 err:wave:DSDB_MMAPCopy mmap partially failed. err:ntdll:RtlpWaitForCriticalSection section 0x7fe3336c "?" wait timed out in thread 000a, blocked by 0000, retrying (60 sec) err:ntdll:RtlpWaitForCriticalSection section 0x7fe3336c "?" wait timed out in thread 0009, blocked by 0000, retrying (60 sec) err:ntdll:RtlpWaitForCriticalSection section 0x7fe3336c "?" wait timed out in thread 000a, blocked by 0000, retrying (60 sec) err:ntdll:RtlpWaitForCriticalSection section 0x7fe3336c "?" wait timed out in thread 0009, blocked by 0000, retrying (60 sec) I thought that DirectSound was not performing locking properly, until I noticed the following: all the times I see this deadlock, the thread ID "responsible" for the deadlock is 0000. From a little digging in the code, I see that 0 is the value used in the critical section when it is not held by any thread. So these are potentially cases where a previous thread frees the critical section, but somehow the critical section remains locked. I think I saw a select() call in the wineserver, used as an implementation for this wait, and this select() call times out, resulting in the behavior shown above. All these instances happen under heavy CPU load, so I suspect some sort of race condition. If I really try and bog down the CPU, I can even trigger this deadlock on the DirectSound tests (under ALSA). Could anybody who knows about Wine critical sections comment on this? I do not really understand the implementation of critical sections at the wineserver side (other than the fact that a select() is used somewhere), so I could take a long time to unravel this bug. This problem does not seem specific to DirectSound as far as I could tell, so this might be affecting a couple other apps under Wine. Also, comments on how I could supply more information on this are welcome. Alex Villacís Lasso

Aug. 29, 2005

Re: KERNEL: check for NULL in LoadModule16

by Alex Villacís Lasso

Andreas Mohr wrote: >Hi, > >On Mon, Aug 29, 2005 at 12:37:31PM -0500, Alex Villacís Lasso wrote: > > >>An old copy of Print Shop Deluxe Companion manages to supply a NULL as a >>name to be loaded by LoadLibrary16 --> LoadModule16 --> SIGSEGV. This >>patch adds a check to return ERROR_READ_FAULT instead of crashing. >> >>Alex Villacís Lasso >> >>Changelog: >>* Add a NULL check in LoadModule16 >> >> > >Are you sure that Windows does that thing? > >Somehow I really cannot imagine that during all these years this one has gone >unnoticed... > >(and is ERROR_READ_FAULT the correct error to return here?) > >Thanks, > >Andreas Mohr > > > I could not find any MSDN reference on any documented behavior for LoadLibrary16 or LoadModule16 when libname == NULL. Even if Windows does not check for NULL in this function, I do not think that the bug-for-bug compatibility should extend to the point where Wine crashes on the same invalid parameters as Windows does. This only leaves the exact value of the return value - I don't have the tools to generate a 16-bit executable under Windows, or else I don't know of any freely available ones, so I could only check the 32-bit LoadLibrary. Maybe somebody could point me to an URL to download a 16-bit compiler for Windows? The specific value of ERROR_READ_FAULT was chosen because a) it is less than 31, as the MSDN documents, b) it is the closest description of what happens when the function attempts to use the parameter without checking. Alex Villacís Lasso

Aug. 29, 2005

Re: KERNEL: check for NULL in LoadModule16

by Andreas Mohr

Hi, On Mon, Aug 29, 2005 at 12:37:31PM -0500, Alex Villacís Lasso wrote: > An old copy of Print Shop Deluxe Companion manages to supply a NULL as a > name to be loaded by LoadLibrary16 --> LoadModule16 --> SIGSEGV. This > patch adds a check to return ERROR_READ_FAULT instead of crashing. > > Alex Villacís Lasso > > Changelog: > * Add a NULL check in LoadModule16 Are you sure that Windows does that thing? Somehow I really cannot imagine that during all these years this one has gone unnoticed... (and is ERROR_READ_FAULT the correct error to return here?) Thanks, Andreas Mohr

Aug. 29, 2005

Re: Web Server Downtime

by Jeremy Newman

9am CDT == 14:00 GMT and 4pm CDT == 21:00 GMT On Mon, 2005-08-29 at 12:14 -0500, Jeremy Newman wrote: > The Web Server will be offline tomorrow from 9am CDT through 4pm CDT. > (04:00 - 11:00 GMT) > > The website will be up temporarily on our other webserver during the > move. Things like CVS and the Mailing lists will be offline during that > time. > > Note: I plan on upgrading Mailman (the software that controls the > mailing lists) to the latest version in Debian Sarge. (2.1.5). WineHQ > currently runs 2.0.13. The subscription list should port over with no > issues. The list archives I will convert from hypermail to Mailmans own > internal pipermail format. This will change the URL of the archives as > well. I will post the final details once the upgrade is complete. > > Features on Mailman 2.1 > http://www.gnu.org/software/mailman/features.html > > > >

Aug. 29, 2005

Re: WINEALSA: comment on unexpected shrinking of mmap-buffer (resend)

by Alex Villacís Lasso

Robert Reif wrote: > Alex Villacís Lasso wrote: > >> The first test that fails with the ALSA driver is the so-called >> "reference" tone, which, as far as I could see, is played with a >> primary buffer, and no secondary buffer. The reference tone uses the >> hardware position directly, which wraps around at a buffer size that >> changes unexpectedly when switching playback formats. I have prepared >> a patch that "fixes" this, by re-querying the buffer size in the case >> of a primary buffer, and displaying a warning if it detects a buffer >> size change. However, I don't know if the buffer size is supposed to >> remain constant across buffer format changes. If it does, then the >> patch would need to be modified to mark this as a TODO. > > > Fix the wine ALSA driver rather than the test unless you can prove > that the test fails on Windows. > This is a modified patch that marks the problematic buffer resize as a todo_wine. Could somebody please test this patch and confirm that the buffer size actually remains constant across playback format changes?

Aug. 29, 2005

Web Server Downtime

by Jeremy Newman

The Web Server will be offline tomorrow from 9am CDT through 4pm CDT. (04:00 - 11:00 GMT) The website will be up temporarily on our other webserver during the move. Things like CVS and the Mailing lists will be offline during that time. Note: I plan on upgrading Mailman (the software that controls the mailing lists) to the latest version in Debian Sarge. (2.1.5). WineHQ currently runs 2.0.13. The subscription list should port over with no issues. The list archives I will convert from hypermail to Mailmans own internal pipermail format. This will change the URL of the archives as well. I will post the final details once the upgrade is complete. Features on Mailman 2.1 http://www.gnu.org/software/mailman/features.html

Aug. 29, 2005

Re: [Wine]Softlinking to a dvd-drive with inconsistent mount points? => HAL-Support

by peter＠piments.com

On Sun, 28 Aug 2005 01:56:27 +0200, Walt Ogburn <reuben(a)ugcs.caltech.edu> wrote: > Hi guys, > Sorry if I started a contentious discussion. Contentious discussions can be fruitful but I dont see much contention here. It seems that although Detfel is a great fan of making directory names out of what are basically verbose textual labels, no-one else seems too keen at all. There are too many special characters in text labels (not least of which is the space char) and the probable length of any label description makes it very unsuitable for part of a pathname. As for suggesting all applications must rewritten to benefit from this amazing new feature: rediculous waste of effort. I agree with the other poster, I think it is not likely to have a very long life-span. (If it does wine might have to start detecting SuSE on startup!) What does seems to be a more persistant problem is USB devices which can have different device names every time they are plugged in, unless some very specific udev rules are written by hand. It seems that wine would have to plug into hotplug events to do anything about this. But wine is not supposed to be a OS with-in an OS it is a compatability library for running windows software, so it seems a line has to be drawn between program functionality and system functions. 8) -- Using Opera e-mail on Gentoo Linux

Aug. 29, 2005

Re: Need help debugging a memory corruption bug in shfldr_unixfs.c

by Duane Clark

Phil Krylov wrote: > On Fri, 26 Aug 2005 22:10:16 +0200 > Michael Jung <mjung(a)iss.tu-darmstadt.de> wrote: > >> 2) Did other people see this bug already? > > Yes, I confirm it. > I am seeing it now, using winecfg and browsing to "Add application..." in the Applications tab. And this entirely within wine drives. The exact same crash though, always immediately after a double click on a folder. If I click once on a folder and click open, it works fine. So I suspect something being triggered by the double click. Backtrace: =>1 0xffffe002 (0x4076ee80) 2 0x42028c55 abort+0x1d5 in libc.so.6 (0x4076efb0) 3 0x42021043 in libc.so.6 (+0x21043) (0x4076eff0) 4 0x40bf13be in comctl32 (+0x313be) (0x4076f074) 5 0x40bf906f notify_itemactivate+0x5f(infoPtr=0x40257e18, htInfo=0x4076f124) [/home/wine/dlls/comctl32/listview.c:791] in comctl32 (0x4076f104) 6 0x40bf614c LISTVIEW_LButtonDblClk+0x6c(infoPtr=0x40257e18, wKey=0x1, x=0x5, y=0x4d) [/home/wine/dlls/comctl32/listview.c:8100] in comctl32 (0x4076f150) 7 0x40bf7fa8 LISTVIEW_WindowProc+0x534(hwnd=0x10068, uMsg=0x203, wParam=0x1, lParam=0x4d0005) [/home/wine/dlls/comctl32/listview.c:9372] in comctl32 (0x4076f1b4) 8 0x40a5f6d3 WINPROC_wrapper+0x17 in user32 (0x4076f1d8) ...

Aug. 29, 2005

Re: BUG[1481] : unimplemented function msvcrt.dll._mbsbtype

by Dmitry Timoshkov

"Vijay Kiran Kamuju" <infyquest(a)gmail.com> wrote: > I think we can use _mbbtype reactos. > And i think according to the documentation > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore98/h… > the _mbbtype does not depend on locale information I believe that the documentation above is misleading. Native msvcrt handles locale just fine, I don't see why _mbbtype should be an exception. If you have a test showing another behaviour send it to me, and I'll see how it behaves on my locale. -- Dmitry.

Aug. 29, 2005

Re: BUG[1481] : unimplemented function msvcrt.dll._mbsbtype

by Vijay Kiran Kamuju

Hi Dimitry, I think we can use _mbbtype reactos. And i think according to the documentation http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore98/h… the _mbbtype does not depend on locale information bye, vijay On 8/29/05, Ge van Geldorp <gvg(a)reactos.com> wrote: > > From: Vijay Kiran Kamuju > > > > can we use the reactos implementation of the _mbsbtype? > > http://reactos.geldorp.nl/dc/d8d/mbbtype_8c-source.html > > > > Any ReactOS guys, please respond regarding the licensing of the above > > code? > > Most of the code in our C Runtime originates from the DJGPP compiler > package. I've checked, the DJGPP libc is LGPL. So I think using this in Wine > should be no problem. > > Gé van Geldorp. > > > >

Aug. 29, 2005