-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I realize that that may be an odd question, but I also don't want spend an huge amount of time trying to get something to work that just won't work "at this time" ...
I've been asked to get a Windows application running under FreeBSD ... optimally, I'd prefer to do it under Wine, since the last thing I want is a) to buy a Windows License and b) to run Windows when all I need is this one application ...
First and foremost, I'm most impressed with how far Wine has come ... I remember back when you needed the Windows OS to do anything ... with current Wine, I was able to run the Setup / Installer for this application, it built my .wine directory, installed everything beautifully ...
.. the problem arises when I try and run the app after install ... and the odd thing is that it doesn't appear to actually do anything, it just hangs there, no errors to the screen.
I pop'd into IRC and asked about debugging there, and was pointed to the WINEDEBUG=+all setting, which I've since and re-tried to run, without output redirected to a log file ... it very quickly gets to 65M in size and 900k lines ... most of which looks to be looping around the same dozen lines:
0009:trace:seh:call_stack_handlers calling handler at 0x55779e code=c0000005 flags=0 0009:Call msvcrt._except_handler3(0035f8e4,0035fab0,0035f618,0035f54c) ret=9c1a70fd 0009:trace:seh:_except_handler3 exception c0000005 flags=0 at 0x0 handler=0x55779e 0x35f618 0x35f54c semi-stub 0009:trace:seh:_except_handler3 filter = 0x557756 0009:Call msvcrt._XcptFilter(c0000005,0035f400) ret=00557767 0009:trace:seh:_XcptFilter (c0000005,0x35f400) 0009:Ret msvcrt._XcptFilter() retval=00000000 ret=00557767 0009:trace:seh:_except_handler3 filter returned CONTINUE_SEARCH 0009:trace:seh:_except_handler3 reached TRYLEVEL_END, returning ExceptionContinueSearch 0009:Ret msvcrt._except_handler3() retval=00000001 ret=9c1a70fd 0009:trace:seh:call_stack_handlers handler at 0x55779e returned 1
Using grep -n, it looks like starting around like 43k in the log is where this happens, and continues ad finitum:
43048:0009:trace:seh:_except_handler3 exception c0000005 flags=0 at 0x0 handler=0x55779e 0x35f618 0x35f54c semi-stub 43059:0009:trace:seh:_except_handler3 exception c0000005 flags=0 at 0x0 handler=0x55779e 0x35f618 0x35f54c semi-stub 43070:0009:trace:seh:_except_handler3 exception c0000005 flags=0 at 0x0 handler=0x55779e 0x35f618 0x35f54c semi-stub 43081:0009:trace:seh:_except_handler3 exception c0000005 flags=0 at 0x0 handler=0x55779e 0x35f618 0x35f54c semi-stub 43092:0009:trace:seh:_except_handler3 exception c0000005 flags=0 at 0x0 handler=0x55779e 0x35f618 0x35f54c semi-stub 43103:0009:trace:seh:_except_handler3 exception c0000005 flags=0 at 0x0 handler=0x55779e 0x35f618 0x35f54c semi-stub <alot of lines deleted> 917026:0009:trace:seh:_except_handler3 exception c000013a flags=0 at 0x9c0605d7 handler=0x55779e 0x35f128 0x35f06c semi-stub 917037:0009:trace:seh:_except_handler3 exception c000013a flags=0 at 0x9c0605d7 handler=0x55779e 0x35f128 0x35f06c semi-stub 917048:0009:trace:seh:_except_handler3 exception c000013a flags=0 at 0x9c0605d7 handler=0x55779e 0x35f128 0x35f06c semi-stub 917059:0009:trace:seh:_except_handler3 exception c000013a flags=0 at 0x9c0605d7 handler=0x55779e 0x35f128 0x35f06c semi-stub 917070:0009:trace:seh:_except_handler3 exception c000013a flags=0 at 0x9c0605d7 handler=0x55779e 0x35f128 0x35f06c semi-stub
Looking at the log just before that loop started (not sure how many lines before is significant), there is:
0009:Call msvcrt._initterm(00575000,0057508c) ret=005576e2 0009:trace:msvcrt:_initterm (0x575000,0x57508c) 0009:trace:msvcrt:_initterm Call init function 0x5578f4 0009:trace:seh:raise_exception code=c0000005 flags=0 addr=0x0 0009:trace:seh:raise_exception info[0]=00000000 0009:trace:seh:raise_exception info[1]=00000000 0009:trace:seh:raise_exception eax=005578f4 ebx=9ca6b678 ecx=00000000 edx=00000038 esi=00575004 edi=0057508c 0009:trace:seh:raise_exception ebp=0035f968 esp=0035f93c cs=0033 ds=003b es=003b fs=1007 gs=001b flags=00010206
The fun part is that I don't know what is important, and what isn't ... if someone would like to see the complete log before the semi-stub errors start to loop, please feel free to ask ... the software I'm trying to run is available as a free download, if someone wishes to actually try the software ...
Compared to the graphical games that ppl show listed on AppDB, I would have thought this one would have been simple ... :)
How best to proceed?
Thank you ...
- ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664
On Saturday June 2 2007 01:23, Marc G. Fournier wrote:
the software I'm trying to run is available as a free download, if someone wishes to actually try the software ...
Please tell us the software name at least. Or, even better, provide direct link to where it can be downloaded. Otherwise it is very difficult to help you... Thanks!
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Its trading software ... the software is free, and they provide a demo account to play with before you 'go live' ...
http://www.interbankfx.com/open_a_demo.php
- --On Saturday, June 02, 2007 02:30:26 +0000 "L. Rahyen" research@science.su wrote:
On Saturday June 2 2007 01:23, Marc G. Fournier wrote:
the software I'm trying to run is available as a free download, if someone wishes to actually try the software ...
Please tell us the software name at least. Or, even better, provide direct link to where it can be downloaded. Otherwise it is very difficult to help you... Thanks!
- ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664
On Saturday June 2 2007 03:56, Marc G. Fournier wrote:
Its trading software ... the software is free, and they provide a demo account to play with before you 'go live' ...
"MT4.0" on their website (I suppose) stands for MetaTrader 4.0? If so, MetaTrader 4.0 works perfectly out-of-the-box under Wine (under Linux), I even actually using it and currently I'm writing a program on its MQL 4 language and as far as I have tested everything works perfectly. So your problem is very likely to be FreeBSD-related - in fact, Wine works very bad under FreeBSD. I saw you have opened bug #8562 for this problem, you probably should add there that your issue is FreeBSD-related in order to get more attention from people who knows FreeBSD.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
- --On Saturday, June 02, 2007 04:32:48 +0000 "L. Rahyen" research@science.su wrote:
On Saturday June 2 2007 03:56, Marc G. Fournier wrote:
Its trading software ... the software is free, and they provide a demo account to play with before you 'go live' ...
"MT4.0" on their website (I suppose) stands for MetaTrader 4.0? If so, MetaTrader 4.0 works perfectly out-of-the-box under Wine (under Linux), I even actually using it and currently I'm writing a program on its MQL 4 language and as far as I have tested everything works perfectly.
Sweet, that is definitely encouraging to find out ... what version of Wine are you running? I notice that FreeBSD ports only has 0.9.36, but the web site shows 0.9.38 as being hte latest release ... could it be a difference between those two versions?
So your problem is very likely to be FreeBSD-related - in fact, Wine works very bad under FreeBSD.
I've CC'd in the FreeBSD ports maintainer ... last update to ports was a week or so ago, not sure if he's aware of it "working very bad" ... :(
- ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664
On Saturday June 2 2007 04:48, Marc G. Fournier wrote:
Sweet, that is definitely encouraging to find out ... what version of Wine are you running? I notice that FreeBSD ports only has 0.9.36, but the web site shows 0.9.38 as being hte latest release ... could it be a difference between those two versions?
I think that it should work great under 0.9.36 too. But I always use latest Wine git tree - that is, latest version of Wine compiled from source. And yes, 0.9.38 is the latest release.
I've CC'd in the FreeBSD ports maintainer ... last update to ports was a week or so ago, not sure if he's aware of it "working very bad" ... :(
I'm pretty sure he is. There is problems with FreeBSD that needs to be resolved by FreeBSD community - i.e. by people who knows FreeBSD and have time, will and neccessary skills to help. Problems will never resolve magically themself. Unfortunatelly most (all?) Wine developers know little or nothing about FreeBSD and cannot solve these problems. And I know nothing about FreeBSD too - I even never used it... You may want to search for FreeBSD related bugs in bugzilla to understand current problems with Wine and FreeBSD better.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
- --On Saturday, June 02, 2007 05:28:31 +0000 "L. Rahyen" research@science.su wrote:
I think that it should work great under 0.9.36 too. But I always use latest Wine git tree - that is, latest version of Wine compiled from source. And yes, 0.9.38 is the latest release.
Just built 0.9.38 under FreeBSD, and it doesn't even run :( Never a good sign ... but explains why the port is 2 releases old ...
I'm pretty sure he is. There is problems with FreeBSD that needs to be resolved by FreeBSD community - i.e. by people who knows FreeBSD and have time, will and neccessary skills to help. Problems will never resolve magically themself. Unfortunatelly most (all?) Wine developers know little > or nothing about FreeBSD and cannot solve these problems. And I know nothing about FreeBSD too - I even never used it... You may want to search for FreeBSD related bugs in bugzilla to understand current problems with Wine and FreeBSD better.
Well, it kind of works both ways ... one has to know what the problem if with wine under FreeBSD before one can provide a 'FreeBSD solution' to it :(
As an example, I just upgraded to 0.9.38 on my machine, and tried to run 'terminal.exe', and it SegFaulted:
wine terminal.exe
trace:virtual:NtAllocateVirtualMemory 0xffffffff 0x7ffe0000 00010000 3000 00000004 trace:virtual:add_reserved_area adding 0x9c1fc000-0x9c20c000 trace:virtual:NtAllocateVirtualMemory 0xffffffff 0x0 000001d8 101000 00000004 trace:virtual:map_view got mem with anon mmap 0x110000-0x111000 trace:virtual:VIRTUAL_DumpView View: 0x110000 - 0x110ffftrace:virtual:VIRTUAL_DumpView (anonymous) trace:virtual:VIRTUAL_DumpView 0x110000 - 0x110fff c-rw- trace:ntdll:RtlInitializeBitMap (0x9c1e5b2c,0x110044,64) trace:ntdll:RtlInitializeBitMap (0x9c1e5b34,0x110154,1024) trace:virtual:NtAllocateVirtualMemory 0xffffffff 0x0 00002000 101000 00000004 trace:virtual:map_view got mem with anon mmap 0x111000-0x113000 trace:virtual:VIRTUAL_DumpView View: 0x112000 - 0x113ffftrace:virtual:VIRTUAL_DumpView (anonymous) trace:virtual:VIRTUAL_DumpView 0x112000 - 0x113fff c-rw- sock_init: shutdown() causes EOF wineserver: starting (pid=18067) 0008: *fd* 0x0 -> 18 0009: init_thread( unix_pid=18065, unix_tid=-1, debug_level=1, teb=0x112000, peb=0x110000, entry=0x0, ldt_copy=0x9c033be0, reply_fd=6, wait_fd=8 ) 0009: *fd* 6 <- 18 0009: *fd* 8 <- 19 0009: init_thread() = 0 { pid=0008, tid=0009, info_size=0, server_start=1c7a4d8d6539a04 (-0.0250700), version=304 } 0009:trace:virtual:NtAllocateVirtualMemory 0xffffffff 0x0 00110000 2000 00000004 0009:trace:virtual:map_view got mem with anon mmap 0x114000-0x224000 0009:trace:virtual:VIRTUAL_DumpView View: 0x120000 - 0x22ffff (anonymous) 0009:trace:virtual:VIRTUAL_DumpView 0x120000 - 0x22ffff --rw- 0009:trace:virtual:NtAllocateVirtualMemory 0xffffffff 0x120000 00010000 1000 00000004 0009:trace:virtual:VIRTUAL_SetProt 0x120000-0x12ffff c-rw- 0009:trace:virtual:VIRTUAL_DumpView View: 0x120000 - 0x22ffff (valloc) 0009:trace:virtual:VIRTUAL_DumpView 0x120000 - 0x12ffff c-rw- 0009:trace:virtual:VIRTUAL_DumpView 0x130000 - 0x22ffff --rw- 0009: *fd* 0 <- 20 0009: alloc_file_handle( access=80100000, attributes=00000002, fd=0 ) 0009: alloc_file_handle() = 0 { handle=0x4 } 0009: alloc_file_handle( access=40100000, attributes=00000002, fd=1 ) 0009: *fd* 1 <- 21 0009: alloc_file_handle() = 0 { handle=0x8 } 0009: *fd* 2 <- 22 0009: alloc_file_handle( access=40100000, attributes=00000002, fd=2 ) 0009: alloc_file_handle() = 0 { handle=0xc } 0009: *killed* exit_code=0 Segmentation fault (core dumped)
So, I guess the first question is ... why the SegFault, as far as Wine is concerned? Since 0.9.36 worked, and 0.9.38 isn't, where in the code are things above failing, that I can compare (doing a diff) changes to see if I can figure out what changed between the versions, and what needs to change FreeBSD-specific to bring things back in line again?
I don't find the trace above to be very informative, but that's problem due to not understanding the code itself ...
Now, just a quick look with gdb:
(gdb) where #0 0x9c1aec52 in thread_init () from /usr/X11R6/lib/wine/ntdll.dll.so #1 0x9c194019 in __wine_process_init () from /usr/X11R6/lib/wine/ntdll.dll.so #2 0x9bf38f5a in wine_init () from /usr/X11R6/lib/libwine.so.1 #3 0x7bf011cc in main () (gdb)
but since:
Reading symbols from /usr/X11R6/lib/libwine.so.1...(no debugging symbols found)...done
obviously getting more information from that is going to be useless ... are there any recommended settings for configure'ng / building, so that gdb can get more information?
- ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664
Looks like another duplicate of bug 5732. You should at least check the bugzilla before posting on wine-devel mailing list with user problems. As stated in the bug, there is nothing Wine can do about this. FreeBSD has to be fixed / worked around the limitation.
Vitaliy
Marc G. Fournier wrote:
[snip] lots of debug traces ......
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
- --On Saturday, June 02, 2007 00:25:13 -0600 Vitaliy Margolen wine-devel@kievinfo.com wrote:
Looks like another duplicate of bug 5732. You should at least check the bugzilla before posting on wine-devel mailing list with user problems. As stated in the bug, there is nothing Wine can do about this. FreeBSD has to be fixed / worked around the limitation.
I'm just curious here, but is this a FreeBSD specific issue, or does this affect the other BSDs? NetBSD and/or PC-BSD coming to mind ...
- ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664
On Saturday 02 June 2007 08:07:48 Marc G. Fournier wrote:
--On Saturday, June 02, 2007 05:28:31 +0000 "L. Rahyen"
I'm pretty sure he is. There is problems with FreeBSD that needs to be resolved by FreeBSD community - i.e. by people who knows FreeBSD and have time, will and neccessary skills to help. Problems will never resolve magically themself. Unfortunatelly most (all?) Wine developers know little > or nothing about FreeBSD and cannot solve these problems. And I know nothing about FreeBSD too - I even never used it... You may want to search for FreeBSD related bugs in bugzilla to understand current problems with Wine and FreeBSD better.
Well, it kind of works both ways ... one has to know what the problem if with wine under FreeBSD before one can provide a 'FreeBSD solution' to it :(
Right. And it's not as if we didn't try. Just two days ago, I've sent the following email to the freebsd-hackers mailing list: http://lists.freebsd.org/pipermail/freebsd-hackers/2007-May/020761.html
So far I've received one response, telling me to contact the ports maintainer. I haven't followed up on this yet, but being a maintainer for a couple of RPMs myself, I know that just being the maintainer doesn't mean I know how to fix the source code of the package I maintain. I was kind of hoping for some FreeBSD developers who know the memory management of their OS to at least offer some pointers on where to look. Didn't happen so far.
As I said in my email, I'm really happy to provide the Wine side of things for this bug, but I don't feel like doing the FreeBSD research. I don't use FreeBSD and my time is limited.
Cheers, Kai
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
- --On Saturday, June 02, 2007 10:55:00 +0200 Kai Blin kai.blin@gmail.com wrote:
Right. And it's not as if we didn't try. Just two days ago, I've sent the following email to the freebsd-hackers mailing list: http://lists.freebsd.org/pipermail/freebsd-hackers/2007-May/020761.html
So far I've received one response, telling me to contact the ports maintainer. I haven't followed up on this yet, but being a maintainer for a couple of RPMs myself, I know that just being the maintainer doesn't mean I know how to fix the source code of the package I maintain. I was kind of hoping for some FreeBSD developers who know the memory management of their OS to at least offer some pointers on where to look. Didn't happen so far.
As I said in my email, I'm really happy to provide the Wine side of things for this bug, but I don't feel like doing the FreeBSD research. I don't use FreeBSD and my time is limited.
S'alright, I don't mind working from the FreeBSD side of things, as long as I'm not hitting a 'Linux vs FreeBSD' wall trying to do it :) Why I run FreeBSD is my choice, why you run Linux is yours ... IMHO, neither of us are running Windows, which should be all that truly matters :)
Let me read through your email and see if I can nudge some comments out of some of the 'kernel developers' that I know, who might be able to help shed some light ... or at least get us moving forward ...
- ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664
On Saturday 02 June 2007 20:27:09 Marc G. Fournier wrote:
--On Saturday, June 02, 2007 10:55:00 +0200 Kai Blin kai.blin@gmail.com
As I said in my email, I'm really happy to provide the Wine side of things for this bug, but I don't feel like doing the FreeBSD research. I don't use FreeBSD and my time is limited.
S'alright, I don't mind working from the FreeBSD side of things, as long as I'm not hitting a 'Linux vs FreeBSD' wall trying to do it :) Why I run FreeBSD is my choice, why you run Linux is yours ... IMHO, neither of us are running Windows, which should be all that truly matters :)
Great. Now that this is settled, let's get some work done.
Let me read through your email and see if I can nudge some comments out of some of the 'kernel developers' that I know, who might be able to help shed some light ... or at least get us moving forward ...
Thanks for the help, I really appreciate it.
Cheers, Kai
On Sat, 2 Jun 2007, Marc G. Fournier wrote:
Just built 0.9.38 under FreeBSD, and it doesn't even run :( Never a good sign ... but explains why the port is 2 releases old ...
I debugged this a bit, and believe the change that broke FreeBSD is revision 1.82 of dlls/ntdll/thread.c and related patches to other files.
So, I guess the first question is ... why the SegFault, as far as Wine is concerned? Since 0.9.36 worked, and 0.9.38 isn't, where in the code are things above failing, that I can compare (doing a diff) changes to see if I can figure out what changed between the versions, and what needs to change FreeBSD-specific to bring things back in line again?
Tijl Coosemans (Cc:ed) probably is the one with the best understanding of what changes FreeBSD itself (and possibly Wine) may need to get this running again.
Gerald
-
Gerald Pfeifer -
Kai Blin -
L. Rahyen -
Marc G. Fournier -
Vitaliy Margolen