Newbie Wine question... Borland C++ Builder and Firebird via FIBplus
I have a Borland C++ Application (with full source code) that I am trying to get to run under Wine 20050830. (I plan on switching to CVS builds once I see some progress) I keep getting "segmentation fault" when running the app. I found info on WINEDEBUG and am currently running it set to +relay This results in 300+ Megabyte debug file. (Ran system out of memory trying to loot at it with Konq) I have then been using "tail" to grab just the last few thousand lines of it... It always ends with hundreds/thousands of calls to ntdll.RtlEnterCriticalSection and ntdll.RtsLeaveCriticalSection followed by err:seh:setup_exception stack overflow ### bytes in thread #### eip ###### esp ###### stack 0x##### - 0x#### I am planning on using the HKLM\Software\Wine\Wine existence to let the app know it is running on wine... The app itself also has a "debug mode" that logs events to a file while running - is there a way to send these messages to the same log as WINEDEBUG? That way I would be able to see what method or function of the app resulted in the thousands of calls into the WIN32 API... I am trying to figure out how to: A> Turn the above errors into useful bug reports B> Be able to resolve limitations or errors in wine as I came across them... I do NOT speak for the U.S.Army Corps of Engineers. I am a contractor supporting one of their projects... The recent developments in Mass re Open Formats motivated me to try to get this app working under wine so that running Windows (only platform currently supported by this software) would not be a requirement in order to work on large USACE contracts... __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com
Thursday, September 22, 2005, 10:12:52 AM, Esko Woudenberg wrote:
I keep getting "segmentation fault" when running the app. I found info on WINEDEBUG and am currently running it set to +relay This results in 300+ Megabyte debug file. (Ran system out of memory trying you can add this to your user.reg file to limit size of it (It's two lines, split for readability):
[Software\\Wine\\Debug] 1125240062 "Relayexclude"="RtlEnterCriticalSection;RtlLeaveCriticalSection; _EnterSysLevel;_LeaveSysLevel;_CheckNotSysLevel;NtCurrentTeb; LdrAccessResource;RtlUpperChar;kernel32.97;kernel32.98;TlsGetValue"
err:seh:setup_exception stack overflow ### bytes in thread #### eip ###### esp ###### stack 0x##### - 0x#### Ok, here it looks like it either really runs out of stack or just trying to access the last page of the stack. Wine has a problem in those areas. It doesn't grow stack and throws that exception when app tries to access last page of the stack, that works under windows.
I am planning on using the HKLM\Software\Wine\Wine existence to let the app know it is running on wine... Bad idea. You need to find out what is wrong with Wine and fix it. Or find the problem and let us fix it.
The app itself also has a "debug mode" that logs events to a file while running - is there a way to send these messages to the same log as WINEDEBUG? Yes, just write to stderr.
Vitaliy
Would I be correct in guessing that: "Relayexclude"="RtlEnterCriticalSection;RtlLeaveCriticalSection; _EnterSysLevel;_LeaveSysLevel;_CheckNotSysLevel;NtCurrentTeb; LdrAccessResource;RtlUpperChar;kernel32.97;kernel32.98;TlsGetValue" are generally not important messages for debugging? (and also is +relay enough or should I use +all?) > Ok, here it looks like it either really runs out of > stack or just > trying to access the last page of the stack. Wine > has a problem in those > areas. It doesn't grow stack and throws that > exception when app tries to > access last page of the stack, that works under > windows. If that is the case, is there a work-around? Detecting Wine... > Bad idea. You need to find out what is wrong with > Wine and fix it. > Or find the problem and let us fix it. I understand your concerns but aim to follow parallel paths... (Might end up prompting user "Wine detected - Work around known problems? Y/N") __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com
Thursday, September 22, 2005, 11:23:43 AM, Esko Woudenberg wrote: > Would I be correct in guessing that: > "Relayexclude"="RtlEnterCriticalSection;RtlLeaveCriticalSection; > _EnterSysLevel;_LeaveSysLevel;_CheckNotSysLevel;NtCurrentTeb; > LdrAccessResource;RtlUpperChar;kernel32.97;kernel32.98;TlsGetValue" > are generally not important messages for debugging? I think wine beat them to death so you can be sure they do work ;-) Also they are the most commonly called functions that don't mean anything unless you are interested in that particular area. > (and also is +relay enough or should I use +all?) +relay is a good starting point to see what is going on. But having a source, you don't really need it. You should know where is your program fails what part of Wine (like ole, comctl, file ops, etc.) Then you can enable that trace and investigate that part. >> Ok, here it looks like it either really runs out of >> stack or just >> trying to access the last page of the stack. Wine >> has a problem in those >> areas. It doesn't grow stack and throws that >> exception when app tries to >> access last page of the stack, that works under >> windows. > If that is the case, is there a work-around? Sort of. I have a program that just clears whole stack after it's done. For this I just disabled guard pages that Wine uses to raise that exception. If your program really runs out of stack - i.e. ESP points to the last stack page then you need to find out why does it do that. It could be just a case of nested functions that never return because they not getting correct results from Wine. > Detecting Wine... >> Bad idea. You need to find out what is wrong with >> Wine and fix it. >> Or find the problem and let us fix it. > I understand your concerns but aim to follow parallel > paths... (Might end up prompting user "Wine detected > - Work around known problems? Y/N") Most of the time, you should be able to find the problem and fix it in Wine. The hardest part is to find it, not to fix it (unless that is something really complicated. But then you can't just remove huge chunk of your program anyway.) If you can find the problem, I'm sure people here will help you fix it, if you don't know how. What you can do in this case is to add a test to Wine's regression test suite. Vitaliy
Esko Woudenberg wrote:
I found info on WINEDEBUG and am currently running it set to +relay This results in 300+ Megabyte debug file. (Ran system out of memory trying to loot at it with Konq) I have then been using "tail" to grab just the last few thousand lines of it... It always ends with hundreds/thousands of calls to ntdll.RtlEnterCriticalSection and ntdll.RtsLeaveCriticalSection
Wonderful tool, that WINEDEBUG! I'm very much a newbie too, and the WINEDEBUG stuff really helps me getting just a little bit of understanding about what is going on. Love it. In the manual here: http://www.winehq.com/docs/wine-user.html#CONFIG-FILE-HOW I've found that you can exclude those CriticalSection messages which you probably don't care about. That should give you a much smaller file and faster execution times, which is always nice when you're debugging. You need to put the following key/value somewhere in your registry - the manual and winehq pages are, ahem, not very explicit about where to put them, but supposedly somewhere under key named 'Debug'...: "RelayExclude" = "RtlEnterCriticalSection;RtlLeaveCriticalSection"
followed by err:seh:setup_exception stack overflow ### bytes in thread #### eip ###### esp ###### stack 0x##### - 0x####
Found a bit in a wine debugging tutorial: http://wiki.winehq.org/Debugging_'Wild_Metal_Country' Which explains nicely that what you see is an infinite loop, I think somewhere in Wine's exception handling code, and that you should debug with +seh to see what's going on.
I am planning on using the HKLM\Software\Wine\Wine existence to let the app know it is running on wine...
Sounds hackish :-).
The app itself also has a "debug mode" that logs events to a file while running - is there a way to send these messages to the same log as WINEDEBUG? That way I would be able to see what method or function of the app resulted in the thousands of calls into the WIN32 API...
Quah? Mebbe. Easiest thing would probably be to make your app write to stderr instead of that file it's using? There's also a hack in the manual (see first link) that will send WINEDEBUG messages to a file, but then again so will 2> ...
participants (3)
-
Esko Woudenberg -
Molle Bestefich -
Vitaliy Margolen