May 2010 - Wine-devel - list.winehq.org

Re: Valgrind's wine_cp_wcstombs warnings
by Dan Kegel 07 May '10

07 May '10

Hi Joerg, did you try the --track-origins option? That can sometimes give more detail (see e.g. the traces in this old message): On Thu, Jul 31, 2008 at 10:14 AM, Dan Kegel <dank(a)kegel.com> wrote: > Hi Colin, > your change > http://source.winehq.org/git/wine.git/?a=commitdiff;h=c2c1a55f1c08f35ae02b8… > seems to have triggered some valgrind warnings, > http://kegel.com/wine/valgrind/logs/2008-07-31-07.46/vg-kernel32_codepage-d… > e.g. > > + Use of uninitialised value of size 4 > + at wcstombs_sbcs (wctomb.c:186) > + by wine_cp_wcstombs (wctomb.c:457) > + by WideCharToMultiByte (locale.c:1936) > + by test_string_conversion (codepage.c:288) > + by func_codepage (codepage.c:351) > + by run_test (test.h:488) > + by main (test.h:537) > + Uninitialised value was created by a stack allocation > + at test_string_conversion (codepage.c:216) > > + Use of uninitialised value of size 4 > + at wcstombs_sbcs_slow (wctomb.c:246) > + by wine_cp_wcstombs (wctomb.c:453) > + by WideCharToMultiByte (locale.c:1936) > + by test_string_conversion (codepage.c:288) > + by func_codepage (codepage.c:352) > + by run_test (test.h:488) > + by main (test.h:537) > + Uninitialised value was created by a stack allocation > + at test_string_conversion (codepage.c:216) > > Could you have a look? >

2 3

How to change text on winehq.org ?
by Marco Meijer 07 May '10

07 May '10

Hi WineDevs, If make the packages for mandriva on sourceforge. And the text on the download page on the website (winehq,org) for mandriva is getting old. Who can I write a mail to change the text ? I already tried web-admin ad winehq.org some weeks ago but no reaction so far. greetings Marco

4 3

Re: [PATCH] wordpad: add units (in/inch/pt)
by Dylan Smith 06 May '10

06 May '10

>- /* FIXME: Allow other units and convert between them */ > if(!lstrcmpA(endptr, units_cmA)) >+ { >+ if (punit != NULL) *punit = UNIT_CM; >+ endptr += 2; >+ } >+ else if (!lstrcmpA(endptr, units_inA)) >+ { >+ if (punit != NULL) *punit = UNIT_INCH; >+ endptr += 2; >+ } >+ else if (!lstrcmpA(endptr, units_inchA)) >+ { >+ if (punit != NULL) *punit = UNIT_INCH; >+ endptr += 4; >+ } >+ else if (!lstrcmpA(endptr, units_ptA)) >+ { >+ if (punit != NULL) *punit = UNIT_PT; > endptr += 2; >+ } > > return *endptr == '\0'; > } You should really use strlen(units_*A) instead of a constant for incrementing endptr since these strings may be different lengths once localized. For instance I believe inch in French is "pouce" which is 5 characters so the null byte would truncate it to "pouc". This should have already been done with "cm" units even though no translation has made it different from 2 characters in length.

1 0

Re: Stack corruption in dsound.c
by Dan Kegel 06 May '10

06 May '10

>* Can i make assumption, that log produced by wine is not buffered anywhere >and is written to console sequentially and immediately when that event >happened? (in other words log output doesn't outrun each other lines) Sadly, not in a multithreaded program. >* Is HEAP_ValidateInUseArena called automatically when HeapAlloc() or >HeapFree() is called? When WINEDEBUG=+heap, it's called on HeapFree, HeapReAlloc, or HeapSize. See http://source.winehq.org/ident?i=HEAP_ValidateInUseArena http://source.winehq.org/ident?i=validate_block_pointer Now that you know there is heap corruption, you may be able to pinpoint the line of code that causes it using Valgrind. See http://wiki.winehq.org/Wine_and_Valgrind (It's slow and uses lots of memory, so it's not practical for all apps, but when it works it's great.)

1 0

Stack corruption in dsound.c
by wylda＠volny.cz 06 May '10

06 May '10

Hi, for those of readers who don't know yet, i'm a "Hello word" programmer, so sorry for bad wording or speculation etc. I decided to look into a regression since wine 1.1.30, who nobody apparently not know what to do, otherwise it would be solved ;) The game freezes during sound initialization and i tracked it down by printf debugging to heap allocation in DirectSoundDevice_Create(). Game goes: ... DirectSoundDevice_Create() //HeapAlloc OK ... OpenAL Init ... DirectSoundDevice_Create() //HeapAlloc returns insane values ... fixme:dbghelp:validate_addr64 Unsupported address ffffffffb5e70000 fixme:dbghelp:validate_addr64 Unsupported address ffffffffb5a60000 fixme:dbghelp:validate_addr64 Unsupported address ffffffffb5a40000 fixme:dbghelp:validate_addr64 Unsupported address ffffffffb5950000 fixme:dbghelp:validate_addr64 Unsupported address ffffffffb5940000 fixme:dbghelp:validate_addr64 Unsupported address ffffffffb5920000 Frozen This happens only when builtin OpenAL is used. In this case HeapAlloc gives values always beginning with 0x234vwxyz. Builtin OpenAL example (*** BAD - Game freezes ***): device = HeapAlloc(GetProcessHeap(),HEAP_ZERO_MEMORY,sizeof(DirectSoundDevice)); First call of DirectSoundDevice_Create(): 0x0014f908 = HeapAlloc(0x00110000, 0x00000008, 0x000003d4) Second call of DirectSoundDevice_Create(): 0x234228e0 = HeapAlloc(0x00110000, 0x00000008, 0x000003d4) Native OpenAL example(*** OK - Game runs***): First call of DirectSoundDevice_Create(): 0x0014fa30 = HeapAlloc(0x00110000, 0x00000008, 0x000003d4) Second call of DirectSoundDevice_Create(): 0x001566c0 = HeapAlloc(0x00110000, 0x00000008, 0x000003d4) So how do i find out, why HeapAlloc does not return sane values like in first call of DirectSoundDevice_Create()?

5 10

Wine looses a bit gaming and wins mobility?
by André Hentschel 06 May '10

06 May '10

Hi Folks, Steam seems to add a Linux client in the near future, so maybe Wine will not be needed anymore for that. or did i get something wrong? That might reduce our "market share" a bit as i guess that many Wineusers play steam games. On the other hand Intel presented its Z600, which is basically x86 but without IDE, SATA or a BIOS. Thats the reason that it cant run Windows. So Linux runs and so should Wine i guess. So we might see some mobil advantures in the near future? -- Best Regards, André Hentschel

9 14

Re: usp10: implement mirroring for bidi support
by testbot＠testbot.winehq.org 06 May '10

06 May '10

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=1920 Your paranoid android. === WINEBUILD (build) === Patch failed

1 0

LinuxTag Berlin - call for projects
by Jan Gerrit Möltgen 06 May '10

06 May '10

Hello together, I'm not sure, if this is the right place for my question, but I thought it's better than the user-list. The LinuxTag in Berlin makes a call for projects ( http://wiki.linuxtag.org/w/fp:Call_for_Projects ) and in my oppinion Wine should be represented there. Has somebody already submitted an application? If yes, I would like to support, otherwise I'd like to submit an application and would be happy about every helping hand. Greetings, Jan Gerrit -- Dipl.-Wirt.-Inf. Jan Gerrit Möltgen . . . . . .gerrit.moeltgen(a)itomig.de ITOMIG GmbH . . . . . . . . . . . . . . . . . . Tel.: +49 7031 389 25 06 Otto-Lilienthal-Str. 36 . . . . . . . . . . . . . . http://www.itomig.de D-71034 Böblingen . . . . . . . . . . . . . . . http://www.itomig.de/fr Geschäftsführer: David Gümbel . . . . . HRB 728519 Amtsgericht Stuttgart Sitz der Gesellschaft: Böblingen . . . . . . . . . . . . . . . . . . . .

3 5

A revision for common PageSetup dialog
by Love Nystrom 05 May '10

05 May '10

File: dlls\comdlg32\printdlg.c Function: static void subclass_margin_edits(HWND hDlg) Hi WineDevs, I have a revision for the common page setup dialog for You. I'm not a Wine dev, but a participant in ReactOS, and we synchronize ComDlg32 with You regularly, so this revision _should_ go to You. I'll submit the full function, not a patch, since I don't work in the Wine source tree. The ReactOS sync has a different path, and most likely line numbers too, so a patch merge would go astray. I've registered with the wine-patches and wine-devel mailing lists so You can notify in case You need something else from me. Since this is not a straight 'diff' mail-body I'll post it here on wine-devel first, as I'm unsure how You handle wine-patches mail. Now to the small revision: This revision adds an error check on the winproc pointer returned by SetWindowLongPtr(.. GWLP_WNDPROC ..) and fixes a build warning issued because GCC thinks 'old_proc' is computed but never used.. I assume the reason for repeating the attempt to set 'edit_proc' is because we're not certain which editors will be present, so there _should_ be a fail-check on 'old_proc' anyway. If you _know_ 'edt4' will always be present, it would be better to move the assign for 'edit_proc' out of the loop, and avoid the repeated conditional assign. Both variants are #if'ed in the patch. Just remove the variant you don't want. --- code begin --- static void subclass_margin_edits(HWND hDlg) { int id; WNDPROC old_proc; #if 1 for(id = edt4; id <= edt7; id++) { old_proc = (WNDPROC)SetWindowLongPtrW(GetDlgItem(hDlg, id), GWLP_WNDPROC, (ULONG_PTR)pagesetup_margin_editproc); /* InterlockedCompareExchangePointer((void**)&edit_wndproc, old_proc, NULL); */ if ((edit_wndproc == NULL) && (old_proc != NULL)) edit_wndproc = old_proc; } #else old_proc = (WNDPROC) SetWindowLongPtrW ( GetDlgItem( hDlg, edt4 ), GWLP_WNDPROC, (ULONG_PTR) pagesetup_margin_editproc ); if ((edit_wndproc == NULL) && (old_proc != NULL)) edit_wndproc = old_proc; for( id = edt5; id <= edt7; id++ ) SetWindowLongPtrW ( GetDlgItem( hDlg, id ), GWLP_WNDPROC, (ULONG_PTR) pagesetup_margin_editproc ); #endif } --- code end --- The reason for the build warning is that the definition of InterlockedCompareExchangePointer() confuses GCC. It thinks 'old_proc' is computed but never used, and issues an over-sensitive, even misleading, warning. It seems like GCC doesn't realize that an intrinsic uses the value. It would be good to fix InterlockedCompareExchangePointer, or GCC. Sadly, I can't figure out how to do that. Best Regards Love N

2 1

[rfc] server: Use rtkit to set realtime priority, try 3
by Maarten Lankhorst 05 May '10

05 May '10

--- Hi gus, Thought I'd try again :) This is a cleaned up version. The license on rtkit.c will still have to change, but since it's so heavily modified to get it into a shape for wine, that only a few lines in make_realtime are still original, so it would be easy to rewrite the remainder of that function to get it fully lgplv2.1. See also https://tango.0pointer.de/pipermail/pulseaudio-discuss/2010-May/007058.html Are there any issues left, or shall I submit this one to wine-patches after the patch linked above is merged into rtkit.git ? Cheers, Maarten

1 0