November 2009 - Wine-devel - list.winehq.org

howto document for valgrinding application test suites (starting with chromium)
by Dan Kegel 11 Nov '09

11 Nov '09

http://winezeug.googlecode.com/svn/trunk/valgrind/doc/win32.html shows (using Chromium as an example) how windows developers can find memory errors in their windows code by running their test suites under valgrind+wine. It's still an early draft; I expect to improve it as I gain experience tracking down the problems that happen when running this test suite under valgrind+wine. Chromium makes a great example because it has a really good test suite, and, um, because it's my day job :-) This is currently an experiment. If it works out, I might get to do a lot more along these lines. - Dan

2 1

hang in mci tests?
by Dan Kegel 11 Nov '09

11 Nov '09

Hi Joerg, I had a new hang on yesterday's git under valgrind: ../../../tools/runtest -q -P wine -M winmm.dll -T ../../.. -p winmm_test.exe.so mci.c && touch mci.ok preloader: Warning: failed to reserve range 00110000-68000000 mci.c:186: Test failed: mci close all notify (without buffer) returned error: 281 mci.c:190: Test failed: mci close all notify (with output buffer) returned error: 281 mci.c:199: Test failed: mci sysinfo waveaudio quantity open, expected output buffer '0', got: '1' mci.c:279: Test failed: mci status position gave 2333, expected 2000, some tests will fail mci.c:288: Test failed: recorded 74662 bytes, expected 64000 mci.c:298: Test failed: recorded 37331 samples, expected 32000 mci.c:330: Test failed: mci status length gave 2333, expected 2000, some tests will fail. mci.c:333: Test failed: mci incorrect cue output returned: MCIERR_EXTENSION_NOT_FOUND mci.c:148: Test failed: got 0001 instead of MCI_NOTIFY_xyz 0002 from command play mci.c:149: Test failed: PeekMessage should succeed for command status mci.c:437: Test failed: Expected full pathname from info file: tempfile.wav err:wave:wodPlayer_WriteMaxFrags Error in writing wavehdr. Reason: Resource temporarily unavailable err:wave:wodPlayer_WriteMaxFrags Error in writing wavehdr. Reason: Resource temporarily unavailable err:wave:wodPlayer_WriteMaxFrags Error in writing wavehdr. Reason: Resource temporarily unavailable err:wave:wodPlayer_WriteMaxFrags Error in writing wavehdr. Reason: Resource temporarily unavailable ... 1600 dup lines removed ... ALSA lib ../../../src/pcm/pcm.c:7228:(snd_pcm_recover) underrun occured 16 bytes in 1 blocks are definitely lost in loss record 148 of 913 by: RtlAllocateHeap (heap.c:1421) by: mciSendStringW (mci.c:1319) by: mciSendStringA (mci.c:1448) by: test_openCloseWAVE (mci.c:164) by: func_mci (mci.c:652) I had to kill it; dunno if the leak was because I interrupted it or not. - Dan

2 1

Amicus curiae: winenas.drv: Remove broken driver
by Michael Stefaniuc 11 Nov '09

11 Nov '09

Hello Alexandre and Maarten, as you guys where discussing right now on irc about it I'm rushing this email out. On 11/07/2009 02:45 PM, Maarten Lankhorst wrote: > --- > From 88fde5ad95a33dc2da29757605891ccc5047c12f Mon Sep 17 00:00:00 2001 > From: mlankhorst <mlankhorst(a)eee.(none)> > Date: Sat, 7 Nov 2009 13:34:54 +0000 > Subject: [PATCH] winenas.drv: Remove broken driver Data: ----- wine-bugs, wine-devel, wine-users archives from May 2008 to October 2009. Total of 133699 emails and 8313 bugs.winehq.org attachments. Tools: wineoops --------------- - Wine crashes parsed: select count(*) from crash; 2711 - Nr of crashes with module info associated: select count(*) from (select crash_id from crash_modules group by crash_id); 2319 - List of all the Wine audio drivers loaded: select count(*) as nr, name from crash_modules, module where module_id=id and name like "wine%" group by name order by nr desc; 1367|winealsa 156|wineoss 12|wineesd 4|winepulse 3|wineal 3|wineasio 3|winecoreaudio 2|winejack 1|winenas The one crash that has winenas in it is from May 2009. bye michael

1 0

new Lucid gcc compiles wine o
by Susan Cragin 11 Nov '09

11 Nov '09

Lucid has fixed the bug I mentioned earlier, and now Wine can be compiled in pre-alpha Lucid Lynx, providing all updates are as-of today, ll/11. In case anyone is interested, the working gcc is: gcc (Ubuntu 4.4.2-1ubuntu4) 4.4.2

1 0

new invalid read errors in winhttp
by Dan Kegel 11 Nov '09

11 Nov '09

http://kegel.com/wine/valgrind/logs/2009-11-10-17.32/diff-winhttp_notificat… http://kegel.com/wine/valgrind/logs/2009-11-10-17.32/vg-winhttp_notificatio… has a bunch of new errors, all of which seem to look like this: Invalid read of size 4 at check_notification (notification.c:65) by send_callback (session.c:56) by close_connection (request.c:978) by release_object (handle.c:79) by task_thread (request.c:181) by worker_thread_proc (threadpool.c:114) by ??? (signal_i386.c:2279) by call_thread_entry_point (signal_i386.c:2306) by start_thread (thread.c:469) by start_thread (pthread_create.c:297) by clone (clone.S:130) Address 0x7f21f8f8 is not stack'd, malloc'd or (recently) free'd but I don't see any recent changes in that area? - Dan

1 0

[Fwd: 64bit wine]
by Michael Stefaniuc 11 Nov '09

11 Nov '09

3 4

Where to receive MCI PostMessageW notifications?
by Joerg-Cyril.Hoehle＠t-systems.com 11 Nov '09

11 Nov '09

Hi, the MCI relies on notification to implement auto-open correctly. When the command is done, it must send out a notification via PostMessageW. The receiver then ought to call mciClose. One possible implementation would be to have auto-open start a thread that does nothing else but wait for this message to arrive, then call mciClose. I wonder if there's something more lightweight than a thread (this is not Erlang) that could be used inside Wine. What could be used that reacts asynchronously to PostMessageW? Currently, the missing auto-open functionality causes - unclosed files (some seen as error messages when Wine exits) (here it is essential that the notification works 100%) - some application hangs, some of them in Bugzilla. Thanks, Jörg Höhle

2 1

Re: shell32: Use Unicode for GetFileNameFromBrowse
by Alexandre Julliard 11 Nov '09

11 Nov '09

Owen Rudge <orudge(a)codeweavers.com> writes: > For some reason, we have implemented the GetFileNameFromBrowse > function in shell32 with ANSI functions. According to MSDN, the > function should use Unicode, and IE7 (which uses the function for its > File -> Open routine) expects this. This patch fixes that. It should probably be an AW function instead. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 02/16] comctl32: Add basic structure for IImageList interface
by Henri Verbeet 11 Nov '09

11 Nov '09

2009/11/10 Owen Rudge <orudge(a)codeweavers.com>: > +static HRESULT WINAPI ImageListImpl_Add(IImageList *iface, HBITMAP hbmImage, > + HBITMAP hbmMask, int *pi) > +{ > + FIXME("STUB: %p %p %p %p\n", iface, hbmImage, hbmMask, pi); > + return E_NOINTERFACE; > +} This is minor at this point, but E_NOTIMPL is usually a more appropriate return code for stubs.

1 0

Re: [PATCH 01/16] comctl32: Add class factory for IImageList interface
by Alexandre Julliard 11 Nov '09

11 Nov '09

Owen Rudge <orudge(a)codeweavers.com> writes: > These patches finish the implementation of the IImageList v6 interface > in comctl32. This doesn't seem to match Windows, even independently from the structure layout issue. There's no DllGetClassObject or clsid registration on Windows, it's not handled as a standard COM dll. -- Alexandre Julliard julliard(a)winehq.org

1 0