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

Re: wineserver epoll

by Shachar Shemesh

Alexandre Julliard wrote: >Shachar Shemesh <wine-patches(a)shemesh.biz> writes: > > > >>After much talk, the patch seems ready for commit. Since there are many >>systems with slightly older glibc that have the header but do not have >>the implementation in glibc, or that have a stub implementation that is >>guaranteed to fail, we are calling the kernel functions directly. This >>also allows compiling on older systems than the code actually ships to. >> >>Accordingly, the autoconf checks for epoll_create in glibc were dropped. >> >> > >That's wrong; if the libc function exists you should use it, direct >system calls should only be used as a fallback. And when using system >calls you must not depend on the libc header, you have to define the >structures yourself. > > The problem is that on many platforms, the functions are defined in glibc, but stubbed out to always fail. It seems a waste to lose these platforms. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/

Aug. 30, 2004

Re: trouble debugging

by Mike McCormack

James Hawkins wrote: > Unhandled exception: page fault on read access to 0x00000000 in 32-bit Try this: WINEDEBUG=+relay,+seh wine prog.exe >& log that will give a reasonably sized log, maybe 100Mb. Then search it for lines starting with seh. less log /seh Then look backwards from the location of the exception that caused the debugger to start. If you're lucky, the function that caused the exception will be somewhere just before the exception. Mike

Aug. 30, 2004

Re: trouble debugging

by James Hawkins

I ran the prog with WINEDEBUG=+relay,+seh this time at the advice of Mike, and this is the last couple of lines before the exception: 0009:Call kernel32.GlobalGetAtomNameW(0000c007,408dba30,0000003c) ret=40858760 0009:Ret kernel32.GlobalGetAtomNameW() retval=00000006 ret=40858760 0009:Call kernel32._EnterSysLevel(408d9bc0) ret=4087bfcc 0009:Call ntdll.RtlEnterCriticalSection(408d9bc0) ret=40509fb9 0009:Ret ntdll.RtlEnterCriticalSection() retval=00000000 ret=40509fb9 0009:Ret kernel32._EnterSysLevel() retval=40589960 ret=4087bfcc 0009:Call kernel32.lstrcpynW(408dbaa8,403c58a8 L"c:\\My Shared Folder",00000010) ret=4087f42b 0009:Ret kernel32.lstrcpynW() retval=408dbaa8 ret=4087f42b 0009:Call kernel32._LeaveSysLevel(408d9bc0) ret=4087bffc 0009:Call ntdll.RtlLeaveCriticalSection(408d9bc0) ret=4050a0e8 0009:Ret ntdll.RtlLeaveCriticalSection() retval=00000000 ret=4050a0e8 0009:Ret kernel32._LeaveSysLevel() retval=00000000 ret=4087bffc 0009:Call ntdll.RtlLeaveCriticalSection(408d9bc0) ret=4050a0e8 0009:Ret ntdll.RtlLeaveCriticalSection() retval=00000000 ret=4050a0e8 0009:Ret kernel32._LeaveSysLevel() retval=00000000 ret=4087bffc 0009:Ret window proc 0x40853520 (hwnd=0x10092,msg=WM_SETTEXT,wp=00000000,lp=403 c5230) retval=00000001 0009:Call ntdll.RtlFreeHeap(40370000,00000000,403c5230) ret=4088af53 0009:Ret ntdll.RtlFreeHeap() retval=00000001 ret=4088af53 0009:Call kernel32.GlobalLock16(00001107) ret=4087312c 0009:Ret kernel32.GlobalLock16() retval=403a8bb0 ret=4087312c 0009:Ret user32.SetWindowTextW() retval=00000001 ret=40b59857 trace:seh:EXC_RtlRaiseException code=c0000005 flags=0 addr=(nil) trace:seh:EXC_RtlRaiseException info[0]=00000000 trace:seh:EXC_RtlRaiseException info[1]=00000000 trace:seh:EXC_RtlRaiseException eax=00000001 ebx=00000000 ecx=40213be8 edx=0000 0001 esi=00000000 edi=00000000 trace:seh:EXC_RtlRaiseException ebp=00000000 esp=406cd594 cs=0073 ds=007b es=00 7b fs=003b gs=0033 flags=00210202 trace:seh:EXC_CallHandler calling handler at 0x4057a0a0 code=c0000005 flags=0 0009:Call ntdll.NtCreateEvent(406ccf40,001f0003,406cd108,00000001,00000000) ret= 404d153c 0009:Ret ntdll.NtCreateEvent() retval=00000000 ret=404d153c wine: Unhandled exception (thread 0009), starting debugger... Maybe the problem is with the call to SetWindowText? On Mon, 30 Aug 2004 00:05:01 -0400, James Hawkins <truiken(a)gmail.com> wrote: > I have just run the program with WINEDEBUG=trace+shell and i will > attach the results to this message. The last function to be called > before the crash is PathCompactPathW. I'm not sure whether this is > the cause of the crash or not, but I put some test code (from msdn) > into the path section of the shlwapi test suite. Here are the > results: > > MSDN: > The un-truncated path is C:\path1\path2\sample.txt > The truncated path at 125 pixels is : C:\path1\...\sample.txt > The truncated path at 120 pixels is : C:\pat...\sample.txt > The truncated path at 110 pixels is : C:\p...\sample.txt > The truncated path at 25 pixels is : ...\sample.txt > > WINE:The un-truncated path is C:\path1\path2\sample.txt > The truncated path at 125 pixels is : C:\path1\path2\sample.txt > The truncated path at 120 pixels is : C:\path1\path2\sample.txt > The truncated path at 110 pixels is : C:\path1\path2\sample.txt > The truncated path at 25 pixels is : C:\path1\path2\sample.txt > > Im sure this isnt a very vital function, but I thought I would bring > it to the attention of the developers. > > > > On Sun, 29 Aug 2004 23:41:11 -0400, James Hawkins <truiken(a)gmail.com> wrote: > > Hi, > > > > I'm having a real tough time debugging a program im trying to get to > > run called KLConfigWizard.exe. I had a problem earlier that was fixed > > by a tip from Rob. After trying a bunch of different native dll's > > that this program uses, I located the culprit dll (which is about as > > much as I seem to be able to do.) If I use native shlwapi then the > > crash doesnt happen. When i'm not using native shlwapi, the output I > > get is: > > > > [truiken(a)cmu-127081 Kazaa Lite K++]$ wine KLConfigWizard.exe > > Please use the registry key HKEY_CURRENT_CONFIG\Sotfware\Fonts\LogPixels > > to set the screen resolution and remove the "Resolution" entry in the > > config file > > fixme:commctrl:InitCommonControlsEx Unknown class! dwICC=0x4000 > > wine: Unhandled exception (thread 0009), starting debugger... > > fixme:console:SetConsoleCtrlHandler (0x405fbab0,1) - no error checking > > or testing yet > > WineDbg starting on pid 0x8 > > Unhandled exception: page fault on read access to 0x00000000 in 32-bit > > code (0x00000000). > > In 32 bit mode. > > 0x00000000: addb %al,0x0(%eax) > > Wine-dbg>bt > > Backtrace: > > =>1 0x00000000 (0x00000000) > > Wine-dbg>q > > WineDbg terminated on pid 0x8 > > > > I do have the log of WINEDEBUG=trace+all, but the log file is ~243mb? > > I tried scanning through it looking for anything that would give me a > > clue, but it was hard to tell where any error was. It also doesnt > > help that the backtrace doesnt contain much of anything. Any ideas? > > > > -- > > James Hawkins > > > > > -- > James Hawkins > > > -- James Hawkins

Aug. 30, 2004

Re: trouble debugging

by James Hawkins

I have just run the program with WINEDEBUG=trace+shell and i will attach the results to this message. The last function to be called before the crash is PathCompactPathW. I'm not sure whether this is the cause of the crash or not, but I put some test code (from msdn) into the path section of the shlwapi test suite. Here are the results: MSDN: The un-truncated path is C:\path1\path2\sample.txt The truncated path at 125 pixels is : C:\path1\...\sample.txt The truncated path at 120 pixels is : C:\pat...\sample.txt The truncated path at 110 pixels is : C:\p...\sample.txt The truncated path at 25 pixels is : ...\sample.txt WINE:The un-truncated path is C:\path1\path2\sample.txt The truncated path at 125 pixels is : C:\path1\path2\sample.txt The truncated path at 120 pixels is : C:\path1\path2\sample.txt The truncated path at 110 pixels is : C:\path1\path2\sample.txt The truncated path at 25 pixels is : C:\path1\path2\sample.txt Im sure this isnt a very vital function, but I thought I would bring it to the attention of the developers. On Sun, 29 Aug 2004 23:41:11 -0400, James Hawkins <truiken(a)gmail.com> wrote: > Hi, > > I'm having a real tough time debugging a program im trying to get to > run called KLConfigWizard.exe. I had a problem earlier that was fixed > by a tip from Rob. After trying a bunch of different native dll's > that this program uses, I located the culprit dll (which is about as > much as I seem to be able to do.) If I use native shlwapi then the > crash doesnt happen. When i'm not using native shlwapi, the output I > get is: > > [truiken(a)cmu-127081 Kazaa Lite K++]$ wine KLConfigWizard.exe > Please use the registry key HKEY_CURRENT_CONFIG\Sotfware\Fonts\LogPixels > to set the screen resolution and remove the "Resolution" entry in the > config file > fixme:commctrl:InitCommonControlsEx Unknown class! dwICC=0x4000 > wine: Unhandled exception (thread 0009), starting debugger... > fixme:console:SetConsoleCtrlHandler (0x405fbab0,1) - no error checking > or testing yet > WineDbg starting on pid 0x8 > Unhandled exception: page fault on read access to 0x00000000 in 32-bit > code (0x00000000). > In 32 bit mode. > 0x00000000: addb %al,0x0(%eax) > Wine-dbg>bt > Backtrace: > =>1 0x00000000 (0x00000000) > Wine-dbg>q > WineDbg terminated on pid 0x8 > > I do have the log of WINEDEBUG=trace+all, but the log file is ~243mb? > I tried scanning through it looking for anything that would give me a > clue, but it was hard to tell where any error was. It also doesnt > help that the backtrace doesnt contain much of anything. Any ideas? > > -- > James Hawkins > -- James Hawkins

Aug. 30, 2004

trouble debugging

by James Hawkins

Hi, I'm having a real tough time debugging a program im trying to get to run called KLConfigWizard.exe. I had a problem earlier that was fixed by a tip from Rob. After trying a bunch of different native dll's that this program uses, I located the culprit dll (which is about as much as I seem to be able to do.) If I use native shlwapi then the crash doesnt happen. When i'm not using native shlwapi, the output I get is: [truiken(a)cmu-127081 Kazaa Lite K++]$ wine KLConfigWizard.exe Please use the registry key HKEY_CURRENT_CONFIG\Sotfware\Fonts\LogPixels to set the screen resolution and remove the "Resolution" entry in the config file fixme:commctrl:InitCommonControlsEx Unknown class! dwICC=0x4000 wine: Unhandled exception (thread 0009), starting debugger... fixme:console:SetConsoleCtrlHandler (0x405fbab0,1) - no error checking or testing yet WineDbg starting on pid 0x8 Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0x00000000). In 32 bit mode. 0x00000000: addb %al,0x0(%eax) Wine-dbg>bt Backtrace: =>1 0x00000000 (0x00000000) Wine-dbg>q WineDbg terminated on pid 0x8 I do have the log of WINEDEBUG=trace+all, but the log file is ~243mb? I tried scanning through it looking for anything that would give me a clue, but it was hard to tell where any error was. It also doesnt help that the backtrace doesnt contain much of anything. Any ideas? -- James Hawkins

Aug. 30, 2004

Re: mixing SHELL32.DLL and SHFOLDER.DLL

by Juan Lang

Saulius wrote: > Lets try. I am not sure about many things: > > 1, whether is better to duplicate code > SHGetFolderPathW() or to try finding it by an > ordinal its value (the case for the older versions > of SHELL32.DLL) as it was stated by Juergen? What are you trying to accomplish? For example, it seems reasonable to assert that you must use the builtin shell32 and shfolder.dll in combination, or not at all, as Alexandre once suggested. Or, in order for Wine's shfolder.dll to succeed on older (native) versions of shell32.dll, it seems reasonable to have it call SHGetSpecialFolderPath* from SHGetFolderPath*, as MS' version does. In other words, why do you need the combination of native shell32 and builtin shfolder.dll? --Juan __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail

Aug. 30, 2004

Re: CommonUnimpStub looping

by Juan Lang

Mike wrote: > On Sun, 29 Aug 2004 09:23:31 -0700, Steven Edwards > wrote: > > I dont see how native loading of Advapi32 ever > > worked anyway. Its a case like ntdll, kernel32, > > user32 or gdi. Maybe the Win9x advapi32 can..... > > I thought native NT advapi just forwarded to ntdll? Yeah. It depends on a bunch of security APIs that aren't implemented in ntdll though. The win9x advapi32 used to sort of work under wine iirc. I forget at what point that stopped being the case, probably about the time the builtin one became useful. --Juan __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail

Aug. 30, 2004

Re: working together on stdole.tlb and a end to dcom9x

by Jacek Caban

> <>You're right to be suspicious, and there may actually be a bug with the > reference counting in typelib2.c, but fnGetTypeInfoOfGuid should -not- > directly AddRef() the containing typelib. Such an AddRef() rightfully > belongs in with the implemetations of QueryInterface(), AddRef(), and > Release() on ICreateTypeInfo2. It is supposed to be set up that the > TypeInfo objects never deallocate themselves when they hit 0 references, > but they do hold a reference to their containing typelib. The TypeLib > objects never hold a reference to any of their typeinfos (so as not to > cause a reference cycle), but they are set up to deallocate the typeinfo > structures when the typelib hits 0 references. > Application can use fnGetTypeInfoOfGuid function to get ITypeInfo, next release ITypeLib and still use ITypeInfo, so GetTypeInfoOfGuid must directly AddRef the contaning typelib. See this patch: http://www.winehq.org/hypermail/wine-patches/2004/08/0167.html and test "typelib". I think similar thing should be done in typelib2.c. Jacek

Aug. 30, 2004

Re: working together on stdole.tlb and a end to dcom9x

by Jacek Caban

> You're pretty much right. I tried to create *very* simple > HelloWorld-type type library with it and and it reported me bunch of > "stub!" messages and crashed. I also found a bug in implementation of > ITypeLib2_fnGetTypeInfoOfGuid (in fact both implementations, the one > in typelib.c and the second in typelib2.c). It should reference the > typelib it's called on. This ensures that later call > ITypeInfo_GetContainingTypeLib will not return bogus pointer if the > original caller already released the TypeLib. See the attached test. > If any COM hacker around can fix it, it would be nice. > It's not a bug. It's a difference between Wine's and native Windows implementation. When you run the attached test with the builtin version, you'll get: ref = 2 ref = 3 ITypeLib has a reference to the linked list of ITypeInfo. Functions GetTypeInfo and GetTypeInfoOfGuid search this list, call ITypeInfo::AddRef and returns the reference to ITypeInfo. ITypeInfo is destroyed when ITypeLib is destroyed (it means that each other ITypeInfos are destroyed too). Running this test with native Windows dll, results are: ref = 1 ref = 2 While Wine creates ITypeInfo interfaces when creating ITypeLib, native Windows probably create ITypeInfo "on call" when GetTypeInfoOfGuid is called for the first time. ITypeInfo can be deleted in this way while ITypeLib exists, while, in Wine, ITypeInfo has to be deleted together with ITypeLib. I don't thik it Wine's bug. Applications don't depend on this stuff and Wine's ref handling is correct. Jacek

Aug. 30, 2004

Re: [ck] Re: Threading issues? [ck-request@vds.kolivas.org: ck Digest, Vol 3, Issue 16]

by michael＠cherryblossom.homelinux.com

On Sun, Aug 29, 2004 at 09:51:30AM +0200, Ove Kaaven wrote: > s?n, 29.08.2004 kl. 04.13 skrev Michael Chang: > > > I argued with myself about the logic in this for ages. The best I could > > > come up with is - I don't know :| I'd need to know about windows > > > scheduling (which I don't) > > > > Obviously, if Win apps have been written to expect this, there's > > documentation somewhere... if someone has free time, maybe look for it? > > A book I have described how it works... > > The Windows scheduler is in its most basic form remarkably similar to > the scheduling policy known in Linux as SCHED_RR, with a few > "enhancements". For example, the thread owning the foreground window > gets a priority boost relative to other threads in the system. There's > also some stuff in there to help deal with the priority-inversion > problem known to real-time programmers, I think. (When a low priority > thread can keep blocking the execution of a high priority thread by > holding a lock the high priority thread needs, with the result that > medium priority threads get to run but the high priority thread does > not, it's called priority inversion, if I understand right.) > > Also note that Windows allows a Win32 process to boost its own priority > all the way to what they call "real time". As I recall, most apps fall under two catagories (basically): a) those who don't bother with priority (they use the default one, mostly toward lesser end users and general audiences) and b) those who allow the user to change this via a menu or command line option (advanced apps only or advanced feature only). Of the latter, there seem to be mostly two types: a) those who allow general priority change, but only to a minor extent (i.e. High/Normal/Low, as seen in the Windows' Version of POV-Ray) and b) those who allow all priority choices (such as Windows' Gameboy Emulators that I've seen, Visual Boy Advance comes to mind). > Only root can do this under Linux. Maybe I sound naive, but would it be possible to get the highest priority supported by the user (root or otherwise) without going to root; getting as close to real-time as possible? It would be a performance hit as opposed to actually using real-time, but otherwise, we'd be okay, I guess... > I'm not sure if you need administrator privileges to do this > under Windows (probably not), On 3.1 and 9x series, where there was no user administration, this was 100% true, since a) only one user at a time, b) file system didn't allow privilages (FAT), and c) the "users" in the default windows just stored settings, (different user registries and desktops and doc folders and such), unless in netware or a such setting, but those didn't control CPU usage, only resource usage on the network. > but since every Windows user runs as > administrator anyway, it's probably not unlikely that many applications Except in recent Windows versions, such as XP and it's NTFS 5 or whatever filesystem which now supports advanced privilages and user administration (such as a super user, the only guy who can install apps and run certain apps and access certain folders). In XP, there's actually an "administrator" and "users"! > expect this ability anyway. > > Internally, Windows assigns each thread a priority, determined by > process priority class, thread priority class (all programmatically > set), and some other factors such as whether it's running in the > foreground (owns the foreground window) or not. Threads with the same > scheduling priority are scheduled round-robin. Threads with higher > priority preempt anything with lower priority, so that lower priority > threads will not get to run as long as a higher priority thread is > runnable. It is of course recommended and assumed that applications use > high priority only for threads that won't use much CPU, since if they > do, execution of that thread will block all threads with lower priority > than itself. > > The book described no kind of dynamic scheduling based on how much CPU > time a thread is spending, only the aforementioned "is in foreground" > thing. Does imply that a Win32 app running an infinite loop could run > fine in the background, but would hang the system if brought to the > foreground, I think (assuming Windows doesn't see that it has hung, > which it probably checks by seeing if it responds to messages). > > > > and how wine treats that scheduling (which I also don't). > > I don't see how that's relevant. Wine doesn't schedule threads, the > Linux kernel does. He didn't say wine scheduled the threads. He said how wine *treats* that scheduling. Which makes sense. You have to figure out how to sync all the threads in an app, and then compare how to sync the different apps to emulate the scheduling -- if you don't, then you end up with desynced threads, garbling video, audio, keyboard handling, processing, etctera. It's sort of like how wine deals with the linux scheduling and windows scheduling, by trying to bridge the gap between the two. Remember, I'm just a Windows/Linux user, and this is all sepculation. --Michael Chang

Aug. 30, 2004