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

Re: wine-20050930 Warblade install error

by Marcus Meissner

On Sat, Oct 01, 2005 at 02:55:01PM +0200, Sebastien Fievet wrote: > Hi all, > > I have the following error when trying to install Warblade (old fashioned > shoot'em up) : > > WINEDLLOVERRIDES="comctl32=n" wine Download/Warblade_12E_full.exe > err:heap:HEAP_ValidateInUseArena Heap 0x41a20000: in-use arena 0x41a2c408 next > block has PREV_FREE flag > > I found various messages related to heap error by browsing the mailing-lists > archives, but no patch neither solution so far... > > Any clue on how to fix this? You need to find out the actual heap corruption. Please run with WINEDEBUG=+relay,+heap WINEDLLOVERRIDES="comctl32=n" wine Download/Warblade_12E_full.exe >logfile 2>&1 And check logfile at the place of the actual heap corruption. Ciao, Marcus

Oct. 1, 2005

Re: Autoresolving our 554 old UNCONFIRMED bugs

by Molle Bestefich

Dan Kegel wrote: > We have 554 unconfirmed bugs older than 90 days. > Most of these are likely to be obsolete. > It would be really easy to write a script to > ping the people who submitted those bugs, > and ask them to update the bug if it's still valid. > If there's no reply in two weeks, we could mark > the bug 'resolved abandoned'. > > Detailed proposal, including the text of the message to be > sent, are at http://kegel.com/wine/qa/autoresolve.html For what it's worth, I like the proposal. As a user, I'd like to be told that it's been 6 months and nobody's gonna look at my bug it if I don't do something proactively myself. IMHO much better to ping users so they can keep their bugs alive if they still exist rather than the bug entries just bitrotting and nobody knowing what state they're in. Thanks, /me

Oct. 1, 2005

wine-20050930 Warblade install error

by Sebastien Fievet

Hi all, I have the following error when trying to install Warblade (old fashioned shoot'em up) : WINEDLLOVERRIDES="comctl32=n" wine Download/Warblade_12E_full.exe err:heap:HEAP_ValidateInUseArena Heap 0x41a20000: in-use arena 0x41a2c408 next block has PREV_FREE flag I found various messages related to heap error by browsing the mailing-lists archives, but no patch neither solution so far... Any clue on how to fix this? Regards, Sebastien.

Oct. 1, 2005

Re: Autoresolving our 554 old UNCONFIRMED bugs

by peter＠piments.com

I agree, ppl take the time to notify bugs and what you are basically saying is "we havenot even got around to looking at the bug you submitted, we are hoping it may have gone away but just incase there is still a bug in our software could you please spend some more time to look at it again , update the bug report and then we will have a smaller list of old bugs that we may still not look at. But at least the bug stats will look good. "If you dont reply within two weeks , we'll ignore the bug anyway and mark it as resolved. "Thanks for your time in supporting our software. " Maybe not the best approach. On Sat, 01 Oct 2005 12:43:02 +0200, Marcus Meissner <marcus(a)jet.franken.de> wrote: > On Fri, Sep 30, 2005 at 11:13:46PM -0700, Dan Kegel wrote: >> We have 554 unconfirmed bugs older than 90 days. >> Most of these are likely to be obsolete. >> It would be really easy to write a script to >> ping the people who submitted those bugs, >> and ask them to update the bug if it's still valid. >> If there's no reply in two weeks, we could mark >> the bug 'resolved abandoned'. >> >> Detailed proposal, including the text of the message to be >> sent, are at http://kegel.com/wine/qa/autoresolve.html >> >> I'd like to send this once packages are ready. > > I am not sure that I like this approach. > It might appear to our users that we do not care. > > The timelines are a bit strict too. ;) > > Ciao, Marcus > > > -- Using Opera e-mail on Gentoo Linux

Oct. 1, 2005

Re: Autoresolving our 554 old UNCONFIRMED bugs

by Marcus Meissner

On Fri, Sep 30, 2005 at 11:13:46PM -0700, Dan Kegel wrote: > We have 554 unconfirmed bugs older than 90 days. > Most of these are likely to be obsolete. > It would be really easy to write a script to > ping the people who submitted those bugs, > and ask them to update the bug if it's still valid. > If there's no reply in two weeks, we could mark > the bug 'resolved abandoned'. > > Detailed proposal, including the text of the message to be > sent, are at http://kegel.com/wine/qa/autoresolve.html > > I'd like to send this once packages are ready. I am not sure that I like this approach. It might appear to our users that we do not care. The timelines are a bit strict too. ;) Ciao, Marcus

Oct. 1, 2005

Bug Triage: Infinite loop in painting.c / winpos.c (2658)

by Molle Bestefich

Hello I'd like to take a stab at helping clear out bugzilla. I've chosen this particular entry: http://bugs.winehq.org/show_bug.cgi?id=2658 A trial version can be downloaded here: http://www.download.com/Trillian/3000-2150-10047473.html The installer runs the setup wizard, which will crash and misbehave. Ignore that, and continue onwards with running "wine trillian.exe". In today's CVS, the application behaves as explained in the Bugzilla. The app goes into an infinite loop somewhere around user/painting.c and user/winpos.c. The visual effect is that: 1. The splash screen pops up in the middle of the screen, 2. It moves a notch (3 by 3 pixels) down and to the right, 3. Step 2.) repeats almost ad infinitum. That is, until the window is at the bottom edge of the screen and halfway to the right edge. 4. The application then waits for a very short while before finally starting over from step 1. Google gives us a few hints, so I'll take you on a short tour: http://bugs.winehq.org/show_bug.cgi?id=2658 "With previous versions, at least the splash window worked [...] but 20050111 makes the splash screen go crazy [...]! It shows up in the middle of the screen, but then goes down until the bottom of the screen." http://article.gmane.org/gmane.comp.emulators.wine.user/3048 "I've been running Trillian Pro quite successfully on wine-20030508 since, well, May 8th." http://article.gmane.org/gmane.comp.emulators.wine.user/6 "CodeWeavers Crossover Plugin works 100% with Trillian, no window move issues." http://www.desktoplinux.com/news/NS4813802007.html "Jan. 23, 2003 [...] CodeWeavers, Inc. today announced the release of CrossOver Plugin Version 1.2, [...] the new release also [... has] improved support for [...] Trillian." http://www.codeweavers.com/site/compatibility/browse/name?app_id=251;forum=1 "Has anyone tested the new version 3.0 already with Crossover?" "Yes. It works somewhat okay - there are bugs that need to be ironed out (i.e. new windows don't pop up well, dragging windows causes artsd to lock up on KDE)." Also slightly interesting: http://www.codeweavers.com/site/compatibility/browse/name?app_id=251;issues… So, it seems it works with CrossOver, but not vanilla Wine. Something fishy seems to be going on in Wine's USER32. I've run with +win, which gives an infinitely repeating list consisting of RedrawWindow, BeginPaint, GetWindowRect, SetWindowPos, MoveWindow, WINPOS_GetMinMaxInfo and others. Here's the infinitely looping part of a +win run: win:RedrawWindow 0x10028 whole window flags: RDW_ALLCHILDREN RDW_UPDATENOW win:BeginPaint hdc = 0xbb4 box = (0,0 - 177,368), fErase = 0 win:GetWindowRect hwnd 0x10028 (741,1244)-(924,1634) win:GetWindowRect hwnd 0x10028 (741,1244)-(924,1634) win:SetWindowPos hwnd 0x10028, after (nil), 549,317 (183x390), flags 80000015 win:dump_winpos_flags flags: SWP_NOSIZE SWP_NOZORDER SWP_NOACTIVATE 80000000 [ notice the block below.. ] win:RedrawWindow 0x10028 whole window flags: RDW_ERASE RDW_ERASENOW RDW_FRAME win:GetWindowRect hwnd 0x10028 (549,317)-(732,707) win:RedrawWindow 0x10028 whole window flags: RDW_INVALIDATE RDW_ERASE RDW_FRAME win:GetWindowRect hwnd 0x10028 (549,317)-(732,707) win:MoveWindow 0x10028 552,336 183x390 0 win:SetWindowPos hwnd 0x10028, after (nil), 552,336 (183x390), flags 0000001c win:dump_winpos_flags flags: SWP_NOZORDER SWP_NOREDRAW SWP_NOACTIVATE win:GetWindowRect hwnd 0x10028 (549,317)-(732,707) win:WINPOS_GetMinMaxInfo 183 390 / 552 336 / 183 390 / 183 390 [ it's repeated now, below.. ] win:RedrawWindow 0x10028 whole window flags: RDW_ERASE RDW_ERASENOW RDW_FRAME win:GetWindowRect hwnd 0x10028 (552,336)-(735,726) win:RedrawWindow 0x10028 whole window flags: RDW_INVALIDATE RDW_ERASE RDW_FRAME win:GetWindowRect hwnd 0x10028 (552,336)-(735,726) win:MoveWindow 0x10028 555,355 183x390 0 win:SetWindowPos hwnd 0x10028, after (nil), 555,355 (183x390), flags 0000001c win:dump_winpos_flags flags: SWP_NOZORDER SWP_NOREDRAW SWP_NOACTIVATE win:GetWindowRect hwnd 0x10028 (552,336)-(735,726) win:WINPOS_GetMinMaxInfo 183 390 / 555 355 / 183 390 / 183 390 [ above block repeats 10 more times, only coordinates changing. ] [ then poof happens the below. Almost a repeat, except for the GetMinMaxInfo params: ] win:RedrawWindow 0x10028 whole window flags: RDW_ERASE RDW_ERASENOW RDW_FRAME win:GetWindowRect hwnd 0x10028 (642,906)-(825,1296) win:RedrawWindow 0x10028 whole window flags: RDW_INVALIDATE RDW_ERASE RDW_FRAME win:GetWindowRect hwnd 0x10028 (642,906)-(825,1296) win:MoveWindow 0x10028 645,925 183x390 0 win:SetWindowPos hwnd 0x10028, after (nil), 645,925 (183x390), flags 0000001c win:dump_winpos_flags flags: SWP_NOZORDER SWP_NOREDRAW SWP_NOACTIVATE win:GetWindowRect hwnd 0x10028 (642,906)-(825,1296) win:WINPOS_GetMinMaxInfo 1282 1026 / -1 -1 / 1288 1032 / 112 27 win:RedrawWindow 0x10028 whole window flags: RDW_ERASE RDW_ERASENOW RDW_FRAME win:GetWindowRect hwnd 0x10028 (645,925)-(828,1315) win:RedrawWindow 0x10020 region 0x192c box (642,906)-(825,1296) flags: RDW_INVALIDATE RDW_ALLCHILDREN win:RedrawWindow 0x10028 whole window flags: RDW_INVALIDATE RDW_ERASE win:RedrawWindow 0x10020 region 0x1934 box (639,887)-(822,1277) flags: RDW_INVALIDATE RDW_ALLCHILDREN win:RedrawWindow 0x10028 whole window flags: RDW_INVALIDATE RDW_ERASE [ above repeats 30 times, albeit with new coordinates etc. ] After this, the trace "wraps around" and repeats itself from the beginning. Coordinates change slightly though, it's a few pixels off from the first run. Please help me understand why the above infinite loop occurs! I also did a +relay trace and ran it through examine-relay. The resulting call stack is awe inspiring - it's as deep as the Mariana Trench. See the attached snippet. Does it not seem "wrong"? I also did a +all trace, which instantly got very big and confusing. I tried grepping to get rid of parts of it, which went OK, but then examine-relay wouldn't indent half of the lines in it, and in the end it complained about a bunch of leftover calls. So I patched Wine (attached) to output only toplevel calls, which gave me this listing: Call window proc 0x3400c710 (hwnd=0x10028,msg=WM_WINDOWPOSCHANGING,wp=00000000,lp=4069e7b0) Ret window proc 0x3400c710 (hwnd=0x10028,msg=WM_WINDOWPOSCHANGING,wp=00000000,lp=4069e7b0) retval=00000000 Call window proc 0x3400c710 (hwnd=0x10028,msg=WM_NCPAINT,wp=00000001,lp=00000000) Ret window proc 0x3400c710 (hwnd=0x10028,msg=WM_NCPAINT,wp=00000001,lp=00000000) retval=00000000 Call window proc 0x3400c710 (hwnd=0x10028,msg=WM_ERASEBKGND,wp=00000bb4,lp=00000000) Ret window proc 0x3400c710 (hwnd=0x10028,msg=WM_ERASEBKGND,wp=00000bb4,lp=00000000) retval=00000001 Call window proc 0x3400c710 (hwnd=0x10028,msg=WM_WINDOWPOSCHANGED,wp=00000000,lp=4069e7b0) [ window moves a lot now ] Ret window proc 0x3400c710 (hwnd=0x10028,msg=WM_WINDOWPOSCHANGED,wp=00000000,lp=4069e7b0) retval=00000000 Call window proc 0x3400c710 (hwnd=0x10028,msg=WM_WINDOWPOSCHANGING,wp=00000000,lp=4069e7b0) Ret window proc 0x3400c710 (hwnd=0x10028,msg=WM_WINDOWPOSCHANGING,wp=00000000,lp=4069e7b0) retval=00000000 Call window proc 0x3400c710 (hwnd=0x10028,msg=WM_NCPAINT,wp=00000001,lp=00000000) Ret window proc 0x3400c710 (hwnd=0x10028,msg=WM_NCPAINT,wp=00000001,lp=00000000) retval=00000000 Call window proc 0x3400c710 (hwnd=0x10028,msg=WM_ERASEBKGND,wp=00000bb4,lp=00000000) Ret window proc 0x3400c710 (hwnd=0x10028,msg=WM_ERASEBKGND,wp=00000bb4,lp=00000000) retval=00000001 Call window proc 0x3400c710 (hwnd=0x10028,msg=WM_WINDOWPOSCHANGED,wp=00000000,lp=4069e7b0) [ window moves a lot now ] Etc. ad infinitum. The above should be the stuff that Trillian actually calls in Wine, but my patch might be wrong. Seems odd that the WM_blah calls do not show up in +relay mode. Please help me understand: Why is that? Thank You for Paying Attention. And Please Help Me Fix This Bug! :-)

Oct. 1, 2005

Re: Release plans

by Molle Bestefich

Dan Kegel wrote: > Anyway, I'm trying hard to come up with a web page that > makes it easy for even non-wine-developers to help > triage bug reports. It's changed a fair bit since I first > announced it; if any of you has time to review it, I'd > love to hear your feedback. Hello Dan, I've just chosen a bug that I'm triaging now. It's *damn* hard :-). You asked for feedback from non-wine-developers, so here's my 2 cents. 1.) Your web page is a little hard to read. Not sure why, maybe it's just that it's 5-guides-in-1 along with code samples that makes it hard to get a proper overview. 2.) The bugzilla engine that you refer to is hard to use. Which is also witnessed in your page - you seem to do too much explaining (also on referenced pages) about how to actually perform a search in the Bugzilla. It doesn't make your guides easier to follow that the tools I have to learn on the way are (IMHO!) a bit horrible :-/. Try: http://bugs.winehq.com/query.cgi Search for NEW+UNCONFIRMED (default) and "Trillian". Bugs 620 and 621 is found. Consider: http://bugs.winehq.org/show_bug.cgi?id=2658 which both contains the word "Trillian" and has status NEW. Why's it not found? Yaarrrr!... I've spent an hour staring at the search page before it struck me: I have to put the string "Trillian" in the "Comments" field. That's just horrid for newbies. Another thing that would help the newbie experience is to, per default, change the STATUS field to contain all color and flavors. That said, it seems that Bugzilla maybe just in general has a horrible interface. Maybe there are much better solutions out there, which could also spare you some precious time having to do those Bugzilla reports you are currently making... See for instance Trac, which has built-in reports, and where the user can in a very simple way create h(is/er) own reports: http://projects.edgewall.com/trac/report (click "Custom Query" to try that out). Or do a simple search, cleanly separated from the reporting function: http://projects.edgewall.com/trac/search Trac also sports an integrated Wiki where bugs and source code can be cross-referenced. (In Wine's case, Trac would have to point to Troy's SVN repo, since Wine uses CVS.) Example of what that's good for: http://projects.edgewall.com/trac/timeline The above bears resemblence to the 'modified in last 14 days' thingy that you also do, at least if you tick only the 'Tickets' checkbox. Well, just a suggestion :-) Have several nice days /me

Oct. 1, 2005

Autoresolving our 554 old UNCONFIRMED bugs

by Dan Kegel

We have 554 unconfirmed bugs older than 90 days. Most of these are likely to be obsolete. It would be really easy to write a script to ping the people who submitted those bugs, and ask them to update the bug if it's still valid. If there's no reply in two weeks, we could mark the bug 'resolved abandoned'. Detailed proposal, including the text of the message to be sent, are at http://kegel.com/wine/qa/autoresolve.html I'd like to send this once packages are ready. Comments? -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html

Oct. 1, 2005

Re: [Regression] WSACleanup() again?

by JustFillBug

On 2005-09-14, Robert Shearman <rob(a)codeweavers.com> wrote: >>On 2005-09-10, JustFillBug <mozbugbox(a)yahoo.com.au> wrote: >>>I saw the bug described in: >>>http://winehq.com/hypermail/wine-users/2001/01/0516.html >>>happened again to a program I was trying to use. At least the behavior >>>is the same. I have no access to the source code. It seems the problem >>>was fixed in revision 1.42 of socket.c. But now at 1.139, WSACleanup >>>again return 0 forever on repeating calls. >>> > > > Does this patch fix it? > Are you going to send the patch to be commited?

Oct. 1, 2005

Re: Release plans

by Dan Kegel

On 9/30/05, Dan Kegel <daniel.r.kegel(a)gmail.com> wrote: > I'll be updating the page > http://kegel.com/wine/qa/ > with bugzilla statistics > > State2005.09.29 > Unconfirmed 836 > New 403 > Assigned 68 > Resolved 421 > Closed 1476 (Sorry 'bout that. I'm not used to gmail's interface yet.) Anyway, I'm trying hard to come up with a web page that makes it easy for even non-wine-developers to help triage bug reports. It's changed a fair bit since I first announced it; if any of you has time to review it, I'd love to hear your feedback. Thanks!

Oct. 1, 2005