January 2011 - Wine-Devel - list.winehq.org

Re: [07/13] kernel32: Avoid checking the output parameter for WriteConsoleOutputAttribute.

by Marvin

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=8074 Your paranoid android. === WINEBUILD (build) === Patch failed to apply Patch failed to apply

Jan. 3, 2011

Re: [03/13] kernel32: Improve parameter validation for WriteConsoleInputW.

by Marvin

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=8070 Your paranoid android. === WINEBUILD (build) === Patch failed to apply Patch failed to apply

Jan. 3, 2011

Re: [04/13] kernel32: Improve parameter validation for WriteConsoleInputA.

by Marvin

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=8071 Your paranoid android. === WINEBUILD (build) === Patch failed to apply Patch failed to apply

Jan. 3, 2011

Question on yHeight values for CHARFORMAT2A/CHARFORMAT2W

by James McKenzie

All: It is interesting that I am getting NEGATIVE values for this. I've ran this against the testbot and received 195 as the value for the System font in WindowsXP/WindowsVista/Windows7 but when I run this against Wine installed on a Mac, I get -240. Is this expected behavior or should I file a bug? Thank you. James McKenzie

Jan. 3, 2011

Re: RFC: include: Add '_ONCE' variants of DPRINTF, FIXME, WARN and ERR

by Dan Kegel

On Sun, Jan 2, 2011 at 11:33 PM, Sven Baars <sven.wine(a)gmail.com> wrote: > But I'm not sure if the ##__LINE__ is really necessary. Yeah, that was overkill. > #ifdef __WINESRC__ > #define ONCE(x) WINE_ONCE(x) > #endif Good idea. - Dan

Jan. 3, 2011

Re: RFC: include: Add '_ONCE' variants of DPRINTF, FIXME, WARN and ERR

by Sven Baars

Dan Kegel wrote: > How about this: > > #define WINE_ONCE(x) { static int wine_once_var##__LINE__; if > (!wine_once_var##__LINE__++) { x; }} > > Example use: > > - static int once; > - if (!once++) FIXME_(keyboard)("(%p,%d,0x%08x,%X): > stub\n",hwnd,id,modifiers,vk); > + WINE_ONCE(FIXME_(keyboard)("(%p,%d,0x%08x,%X): > stub\n",hwnd,id,modifiers,vk)); Hmm... Yeah... That's also a solution of course. Though it's not as elegant :P But I'm not sure if the ##__LINE__ is really necessary. And the ++ might cause an overflow. So this might be better #define WINE_ONCE(x) { \ static int wine_once_var; \ if (!wine_once_var) { \ wine_once_var = 1; \ x; }} and possibly #ifdef __WINESRC__ #define ONCE(x) WINE_ONCE(x) #endif And then a char can be used to save space (if that's of any concern). And volatile in case the compiler does some weird things (but probably won't). Thanks for the idea Dan. Sven

Jan. 2, 2011

Re: msctf/tests: Wait a bit for registrations to become active on Win7

by Marvin

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=8042 Your paranoid android. === W7PRO (32 bit inputprocessor) === inputprocessor.c:749: Test failed: Activation came unexpectedly inputprocessor.c:757: Test failed: Deactivation came unexpectedly === W7PROX64 (32 bit inputprocessor) === inputprocessor.c:749: Test failed: Activation came unexpectedly inputprocessor.c:225: Test failed: Unexpected TextStoreACP_RequestLock sink inputprocessor.c:246: Test failed: Unexpected TextStoreACP_GetSelection sink inputprocessor.c:757: Test failed: Deactivation came unexpectedly === W7PROX64 (64 bit inputprocessor) === inputprocessor.c:749: Test failed: Activation came unexpectedly inputprocessor.c:225: Test failed: Unexpected TextStoreACP_RequestLock sink inputprocessor.c:246: Test failed: Unexpected TextStoreACP_GetSelection sink inputprocessor.c:757: Test failed: Deactivation came unexpectedly

Jan. 2, 2011

re: RFC: include: Add '_ONCE' variants of DPRINTF, FIXME, WARN and ERR

by Dan Kegel

How about this: #define WINE_ONCE(x) { static int wine_once_var##__LINE__; if (!wine_once_var##__LINE__++) { x; }} Example use: - static int once; - if (!once++) FIXME_(keyboard)("(%p,%d,0x%08x,%X): stub\n",hwnd,id,modifiers,vk); + WINE_ONCE(FIXME_(keyboard)("(%p,%d,0x%08x,%X): stub\n",hwnd,id,modifiers,vk));

Jan. 2, 2011

Re: How to find out locking problem

by Henri Verbeet

On 2 January 2011 17:43, <wylda(a)volny.cz> wrote: > The truth is, that wine outputs the first line ("...wait timed out > in thread 001c, blocked by 0041...") only once and after that only > the 2nd line repeats every 60sec ("...wait timed out in thread 0045, > blocked by 0044..."). Don't know if that's normal in these cases or > both lines should repeated. > Thread 0041 is probably just a bit slow at some point then, but it does sound like it eventually releases the lock. It would be interesting to figure out what's taking so long, but it's probably not the main problem. For a proper deadlock you'd have at least two threads waiting for each other, that doesn't seem to be the case here. It looks more like 0044 is either busy doing something expensive or dead. The backtraces for those threads aren't very helpful unfortunately, the stacks for both of them look damaged / altered. You may have more luck with something like a +relay,+seh,+tid log. > So what should i do now to be more helpful? I think that kernel has > some infrastructure for logging of locks or detecting deadlock or > whatever... Is there an equivalent in wine?? > I guess you're referring to lockdep. AFAIK there's no such thing in Wine, but it would probably be a useful tool on occasion. For the reasons mentioned above, I don't think it would have been much help for this specific bug though.

Jan. 2, 2011

How to find out locking problem

by wylda＠volny.cz

Hi Henri, thank you for analysis, it's first time when i'm trying to help with this kind of problem... > > From that backtrace, it doesn't look like 001c is > waiting for a critical section at all. > The truth is, that wine outputs the first line ("...wait timed out in thread 001c, blocked by 0041...") only once and after that only the 2nd line repeats every 60sec ("...wait timed out in thread 0045, blocked by 0044..."). Don't know if that's normal in these cases or both lines should repeated. So what should i do now to be more helpful? I think that kernel has some infrastructure for logging of locks or detecting deadlock or whatever... Is there an equivalent in wine?? Thanks for support. W.

Jan. 2, 2011