-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, I've been trying to use the free Borland C++ 5.5 command-line tools to compile some Windows applications for my school assignments. To be specific, I am in a graphics class where every turnin has to be Windows. :-( Anyways, Borland C++ runs fine until it tries to link the program in question, at which point ilink32.exe just sits there and eats CPU cycles. I've tried letting it run in case it was simply slower than normal due to the Wine layer, but that doesn't seem to be case (I've let it sit for minutes at a time). This occurs no matter how I run it (with wine or either of wineconsole's two modes). I was wondering if there is a way I can help figure out what the problem is so that we can get this bug fixed. Obligatory specs: OS: Gentoo w/ Linux 2.6.3 (Wine was not compiled using NPTL, but OpenGL support is in) ATI OpenGL drivers XFree86 4.3 GCC 3.3.1 Using fake_windows support Please CC: any replies to me, as I am not subscribed to this list. Also, let me know if there is any other information which would be useful. Regards, - Michael Pyne -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAQVAQqjQYp5Omm0oRAofOAKDEhWcFavrlg/3VdjMOcx90hF/iiwCgvWUj IS/FYImIKOxThQRj89LvwYc= =+Gxw -----END PGP SIGNATURE-----
On Sat, 28 Feb 2004 21:35:52 -0500, Michael Pyne wrote:
Anyways, Borland C++ runs fine until it tries to link the program in question, at which point ilink32.exe just sits there and eats CPU cycles. I've tried letting it run in case it was simply slower than normal due to the Wine layer, but that doesn't seem to be case (I've let it sit for minutes at a time).
Hmm, I've used Delphi under Wine to compile apps just fine, but I guess the linkers share no code. Try attaching to the process using winedbg: $ winedbg
walk process .... attach 0xf walk thread bt 0x9 bt 0xwhatever
to get the backtraces of the different threads (there may only be one). See if any are stuck inside the heap code. If so try running with +heap and remember to redirect to a file, as the resultant output will be large.
OS: Gentoo w/ Linux 2.6.3 (Wine was not compiled using NPTL, but OpenGL support is in)
NPTL is detected at runtime now. thanks -mike
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday 29 February 2004 05:48 am, you wrote:
Try attaching to the process using winedbg:
$ winedbg .... to get the backtraces of the different threads (there may only be one).
See if any are stuck inside the heap code. If so try running with +heap and remember to redirect to a file, as the resultant output will be large.
Well, after fixing Gentoo's winedbg wrapper, I got the backtraces you requested (actually, the whole session, in case it helps). I couldn't tell if it was the heap code, all of the functions seem to be related to threading. I eventually ran --debugmsg +all, but still didn't see any heap-related output. :-/ I attached backtraces of both sessions of winedbg in case that's where +heap made a difference. I will try the patch that others suggested and report back on it's effect. Regards, - Michael Pyne -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAQikxqjQYp5Omm0oRApsxAJ9dfQE2LwifCA54glwq8K9dBaoREgCgrT8C YOS1e/dfwnsHnzkb/kUOrh4= =iu3h -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday 29 February 2004 01:02 pm, you wrote:
I will try the patch that others suggested and report back on it's effect.
I've compiled Wine with debugging support, so now I get all of the debugging messages. The patch that was provided is unfortunately too old. It searches for a file in a directory that doesn't exist, for starters. I think I found the file it was looking for, however: dlls/ntdll/virtual.c. I tried patching that file, but then Wine wouldn't start because of a relocation error involving VirtualAlloc. I then went ahead and expanded the VirtualAlloc into the equivalent NtAllocateVirtualMemory call, and then Wine would simply segfault. :-( I'm thinking of just getting an old version of Wine that the patch worked on to handle the case of compiling the programs, but I'd rather fix the problem.
Regards, - Michael Pyne -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQFAQoUNqjQYp5Omm0oRAswjAJ9Lh+2nFwou5QoeD3RMxQLAfPNqLwCgs2uA If36rGZ9Z0NR1pzb4U64iBw= =/ce1 -----END PGP SIGNATURE-----
On Sat, Feb 28, 2004 at 09:35:52PM -0500, Michael Pyne wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi all,
I've been trying to use the free Borland C++ 5.5 command-line tools to compile some Windows applications for my school assignments. To be specific, I am in a graphics class where every turnin has to be Windows. :-(
Anyways, Borland C++ runs fine until it tries to link the program in question, at which point ilink32.exe just sits there and eats CPU cycles. I've tried
Somebody made a patch to support this in the past, but it was not the proper way to do it. It's got something to do with address space not being setup the same way as on Windows as far as I can recall. -- regards, Jakob It's is not, it isn't ain't, and it's it's, not its, if you mean it is. If you don't, it's its. Then too, it's hers. It isn't her's. It isn't our's either. It's ours, and likewise yours and theirs. -- Oxford University Press, Edpress News
On Mon, 1 Mar 2004 00:53, Jakob Eriksson wrote:
Somebody made a patch to support this in the past, but it was not the proper way to do it. It's got something to do with address space not being setup the same way as on Windows as far as I can recall.
Part of the problem is that there doesn't appear to be a "right" way to do it. I think one of the "hacks" just prevented NtQueryVirtualMemory from indicating there was a block of memory crossing the 0x80000000 boundary. Under Windows, it's only on the "Enterprise Edition" operating systems that such a result could be returned from NtQueryVirtualMemory, so this is perhaps not as incorrect as might otherwise be thought. On non EE NT systems, the user address space ends at 0x7fffffff. On Windows 95 series systems, there is a bunch of memory already allocated at 0x7fffffff and down, thus preventing there from ever being a single block of memory (allocated or unallocated) crossing this boundary. On the other hand, there's another problem with NtQueryVirtualMemory - it won't report memory that has been used by native executables and libraries, so that, for example, although the "wine-*" executables (and lots of .so files) take up memory, NtQueryVirtualMemory will not report this (unless this has changed recently). It is not out of the question that an application might use NtQueryVirtualMemory to look for a suitable block to allocate and then explicitly request that block, but find that they've actually hit the location where the WINE code is, so that the request fails. Now on Linux it would be possible to fix NtQueryVirtualMemory to report all allocations by grovelling at /proc/{pid}/maps, but this may not be possible on other systems, or where it is possible will require some other mechanism. So there's really two issues: 1. How should we deal with the 0x80000000 boundary anomaly? 2. Should we attempt to deal with the fact that NtQueryVirtualMemory doesn't report memory used by native executables and libraries?
Troy Rollo <wine(a)troy.rollo.name> writes:
So there's really two issues:
1. How should we deal with the 0x80000000 boundary anomaly?
By allocating something there.
2. Should we attempt to deal with the fact that NtQueryVirtualMemory doesn't report memory used by native executables and libraries?
Only if we find an actual app that depends on that. -- Alexandre Julliard julliard(a)winehq.org
søn, 29.02.2004 kl. 03.35 skrev Michael Pyne:
I was wondering if there is a way I can help figure out what the problem is so that we can get this bug fixed.
You could always start with http://www.winehq.org/hypermail/wine-devel/2002/07/0102.html
participants (6)
-
Alexandre Julliard -
Jakob Eriksson -
Michael Pyne -
Mike Hearn -
Ove Kaaven -
Troy Rollo