Hello!
Something strange to happened my Wine installation recently. I'm getting following messages if I run any program from Wine:
$ winemine wine_main_preload_info not found err:dosmem:setup_dos_mem Cannot use first megabyte for DOS address space, please report wine_main_preload_info not found err:dosmem:setup_dos_mem Cannot use first megabyte for DOS address space, please report
The programs still work fine after those for lines are printed. What's worse is that that Windows PE files don't work at all, including those that come with Wine:
$ wine winhlp32.exe wine_main_preload_info not found wine: could not load L"C:\windows\winhlp32.exe": Module not found
I'm using current Wine from git on Fedora Core development (future FC6) for x86_64, glibc-2.4.90, gcc-4.1.1, Linux 2.6.18-rc2 (actually, the current version from the wireless-2.6 branch). The CPU is Intel with EM64T. Wine is compiled with default settings for i386 by the i386 compatibility compiler and i386 compatibility libraries included in Fedora. I removed ~/.wine to start with a clean system.
Since I keep updating the kernel and Wine almost every day and I upgraded from FC5 to Development recently, it's hard to say what's the exact reason.
P.S. I have a 32-bit Ubuntu 6.04 installation on the same machine, so I used chroot to compile and run Wine under Ubuntu under the same 64-bit kernel. I also used linux32 to fool uname into thinking it's an i686 machine. The messages from ELF programs are gone, but PE files still fail:
$ winemine $ wine winhlp32.exe wine: could not load L"C:\windows\winhlp32.exe": Module not found
Moreover, if I run this Wine on Fedora, the results are the same - no more messages about wine_main_preload_info and setup_dos_mem. I guess it's a compile issue. Unfortunately, the difference between config.status in both builds is quite significant to pinpoint the reason.
Pavel Roskin wrote:
Something strange to happened my Wine installation recently. I'm getting following messages if I run any program from Wine:
$ winemine wine_main_preload_info not found err:dosmem:setup_dos_mem Cannot use first megabyte for DOS address space, please report
Looks like the wine-preloader isn't being run, so memory that wine needs isn't reserved.
Maybe check that configure is setting the EXTRA_BINARIES variable?
mike@black:~/wine$ grep ^EXTRA_BINARIES loader/Makefile EXTRA_BINARIES = wine-kthread wine-pthread wine-preloader
Mike
Hello, Mike!
On Sat, 2006-07-29 at 18:23 +0900, Mike McCormack wrote:
Pavel Roskin wrote:
Something strange to happened my Wine installation recently. I'm getting following messages if I run any program from Wine:
$ winemine wine_main_preload_info not found err:dosmem:setup_dos_mem Cannot use first megabyte for DOS address space, please report
Looks like the wine-preloader isn't being run, so memory that wine needs isn't reserved.
It is installed and it is run. If I replace wine-preloader with a script that logs the arguments and runs the renamed wine-preloader, I see it being called twice when an exe file with run with Wine. For example:
$ wine FarManager170.exe wine_main_preload_info not found wine_main_preload_info not found wine: could not load L"Z:\home\proski\dist\windows\FarManager170.exe": Invalid address
In the log of wine-preloader invocations:
/usr/local/bin/../lib/../bin/wine-pthread FarManager170.exe /usr/local/bin/../lib/../bin/wine-pthread FarManager170.exe
/usr/local/bin/../lib/../bin/wine-pthread is a valid path, wine-pthread is actually located there.
What's interesting is that running wine-pthread instead of Wine goes one step further:
$ wine-pthread FarManager170.exe wine_main_preload_info not found err:dosmem:setup_dos_mem Cannot use first megabyte for DOS address space, please report err:x11drv:X11DRV_CreateWindow invalid window width -193421 err:x11drv:X11DRV_CreateWindow invalid window height -2665207 fixme:richedit:RichEditANSIWndProc EM_EXLIMITTEXT: stub fixme:shell:SHAutoComplete SHAutoComplete stub fixme:exec:SHELL_execute flags ignored: 0x00000580 wine_main_preload_info not found wine: could not load L"C:\windows\temp\RarSFX0\FarManagerSetup.exe": Invalid address wine_main_preload_info not found wine: could not load L"C:\windows\temp\RarSFX0\FarManagerSetup.exe": Invalid address fixme:exec:SHELL_execute flags ignored: 0x00000180 wine_main_preload_info not found wine: could not load L"C:\windows\temp\RarSFX0\FarManagerSetup.exe": Invalid address wine_main_preload_info not found wine: could not load L"C:\windows\temp\RarSFX0\FarManagerSetup.exe": Invalid address
I even see a window appearing for a short time. So, FarManager170.exe is actually run, but it fails when another file needs to be executed.
Similar test with Jardinains installer:
$ wine jardinains_1_2.exe wine_main_preload_info not found wine_main_preload_info not found wine: could not load L"Z:\home\proski\dist\windows\jardinains_1_2.exe": Invalid address
It fails here. But:
$ wine-pthread jardinains_1_2.exe wine_main_preload_info not found err:dosmem:setup_dos_mem Cannot use first megabyte for DOS address space, please report
And I get the installer window here!
Maybe check that configure is setting the EXTRA_BINARIES variable?
mike@black:~/wine$ grep ^EXTRA_BINARIES loader/Makefile EXTRA_BINARIES = wine-kthread wine-pthread wine-preloader
Same thing here:
$ grep ^EXTRA_BINARIES loader/Makefile EXTRA_BINARIES = wine-kthread wine-pthread wine-preloader
I enabled all debug in loader/preloader.c, and the stderr output of "wine jardinains_1_2.exe" is attached.
By the way, "wine winhlp32.exe" was a bad choice. It tries to run /usr/local/lib/wine/winhlp32.exe.so, which doesn't exist. It's a completely separate bug that exists even on pure 32-bit systems.
Pavel Roskin wrote:
It is installed and it is run. If I replace wine-preloader with a script that logs the arguments and runs the renamed wine-preloader, I see it being called twice when an exe file with run with Wine. For example:
$ wine FarManager170.exe wine_main_preload_info not found wine_main_preload_info not found wine: could not load L"Z:\home\proski\dist\windows\FarManager170.exe": Invalid address
OK, it seems to be that the preloader can't lookup the ELF symbol "wine_main_preload_info" in wine-pthread.
That's bad, because the preloader is reserving memory, but has no way to let wine-pthread know which memory it reserved.
Can you see that symbol exported from wine-pthread?
mike@black:~/wine$ nm loader/wine-pthread | grep wine_main_preload_info 7bf023d8 B wine_main_preload_info
Also, which version of gcc/ld are you using? For me:
GNU ld version 2.17 Debian GNU/Linux gcc version 4.1.2 20060715 (prerelease) (Debian 4.1.1-9)
Mike
On Mon, 2006-07-31 at 20:43 +0900, Mike McCormack wrote:
OK, it seems to be that the preloader can't lookup the ELF symbol "wine_main_preload_info" in wine-pthread.
I agree. My gdb cannot show variables in 32-bit binaries (or maybe it's just something Wine specific), but it shows the line numbers. I traced find_symbol() in preloader.c, and it seems like symtabend is 0, so that the last loop is skipped and NULL is returned. This is also evidenced by the lack of "Found" in the log I sent in the previous message.
That's bad, because the preloader is reserving memory, but has no way to let wine-pthread know which memory it reserved.
Can you see that symbol exported from wine-pthread?
mike@black:~/wine$ nm loader/wine-pthread | grep wine_main_preload_info 7bf023d8 B wine_main_preload_info
$ nm loader/wine-pthread | grep wine_main_preload_info 000000007bf02434 B wine_main_preload_info
Also, which version of gcc/ld are you using? For me:
GNU ld version 2.17 Debian GNU/Linux gcc version 4.1.2 20060715 (prerelease) (Debian 4.1.1-9)
Apart from the custom kernel, that's all from the current Fedora Development:
gcc (GCC) 4.1.1 20060721 (Red Hat 4.1.1-13) GNU ld version 2.17.50.0.3-2 20060715
It's a x86_64 system, but I have the necessary packages for i386 development. I don't have SELinux enabled.
Hi Mike,
I have found a workaround!
On Mon, 2006-07-31 at 00:23 -0400, Pavel Roskin wrote:
I agree. My gdb cannot show variables in 32-bit binaries (or maybe it's just something Wine specific), but it shows the line numbers. I traced find_symbol() in preloader.c, and it seems like symtabend is 0, so that the last loop is skipped and NULL is returned. This is also evidenced by the lack of "Found" in the log I sent in the previous message.
Adding more debug information confirms that:
dyn->d_tag=00000001 dyn->d_un.d_ptr=00000001 dyn->d_tag=00000001 dyn->d_un.d_ptr=00000094 dyn->d_tag=00000001 dyn->d_un.d_ptr=00000179 dyn->d_tag=0000000f dyn->d_un.d_ptr=000001c1 dyn->d_tag=0000000c dyn->d_un.d_ptr=7bf00b94 dyn->d_tag=0000000d dyn->d_un.d_ptr=7bf0123c dyn->d_tag=6ffffef5 dyn->d_un.d_ptr=7bf00434 dyn->d_tag=00000005 dyn->d_un.d_ptr=7bf00770 dyn->d_tag=00000006 dyn->d_un.d_ptr=7bf004e0 dyn->d_tag=0000000a dyn->d_un.d_ptr=0000027f dyn->d_tag=0000000b dyn->d_un.d_ptr=00000010 dyn->d_tag=00000015 dyn->d_un.d_ptr=00000000 dyn->d_tag=00000003 dyn->d_un.d_ptr=7bf023bc dyn->d_tag=00000002 dyn->d_un.d_ptr=000000b0 dyn->d_tag=00000014 dyn->d_un.d_ptr=00000011 dyn->d_tag=00000017 dyn->d_un.d_ptr=7bf00ae4 dyn->d_tag=00000011 dyn->d_un.d_ptr=7bf00ad4 dyn->d_tag=00000012 dyn->d_un.d_ptr=00000010 dyn->d_tag=00000013 dyn->d_un.d_ptr=00000008 dyn->d_tag=6ffffffe dyn->d_un.d_ptr=7bf00a44 dyn->d_tag=6fffffff dyn->d_un.d_ptr=00000003 dyn->d_tag=6ffffff0 dyn->d_un.d_ptr=7bf009f0 DT_HASH=00000004 symtab=7bf004e0 strings=7bf00770 symtabend=00000000 wine_main_preload_info not found
find_symbol() looks for DT_HASH (4) to set symtabend and fails to find it. As I understand it, we should trick ld into creating the DT_HASH tag or use some other way to locate wine_main_preload_info.
The 6ffffef5 tag is DT_GNU_HASH - that may be a good alternative to DT_HASH. Adding -Wl,--hash-style=sysv to the gcc flags when linking wine-pthread solves the problem!!!
I think adding support for DT_GNU_HASH would be a good idea anyway.
I've been posting my findings on this very matter to wine-users - look for "cannot run under Fedora 6 tset 1".
I have also found that, if you are running in an SELinux system, you cannot directly run a Windows program using binfmt_misc - the program must have the same security context labels set as the Wine executables do.
And on my system, wine-pthread and wine-kthread both have the wine_main_preload_info symbol exported - only the actual "wine" executable lacks this. Directly running wine-pthread works for me for simple Windows programs, however installers don't work as the temporary executable created by the installer a) does not have the correct security tags and b) is passed directly to "wine" not wine-pthreads.
David D. Hagood wrote:
I've been posting my findings on this very matter to wine-users - look for "cannot run under Fedora 6 tset 1".
Alexandre has committed a patch that looks like it should fix the problem to the git tree.
Mike
On Wed, 2006-08-02 at 03:10 +0900, Mike McCormack wrote:
David D. Hagood wrote:
I've been posting my findings on this very matter to wine-users - look for "cannot run under Fedora 6 tset 1".
Alexandre has committed a patch that looks like it should fix the problem to the git tree.
I confirm that it's working for me. Thank you!
Pavel Roskin wrote:
find_symbol() looks for DT_HASH (4) to set symtabend and fails to find it. As I understand it, we should trick ld into creating the DT_HASH tag or use some other way to locate wine_main_preload_info.
The 6ffffef5 tag is DT_GNU_HASH - that may be a good alternative to DT_HASH. Adding -Wl,--hash-style=sysv to the gcc flags when linking wine-pthread solves the problem!!!
I think adding support for DT_GNU_HASH would be a good idea anyway.
Great work! There's some information on DT_GNU_HASH here:
http://sourceware.org/ml/binutils/2006-06/msg00418.html
Looks like we don't actually use the hash table to look up the symbol, just to find the last entry in the symbol table.
I agree with you the best way to solve the problem would be to handle DT_GNU_HASH.
Mike
Pavel Roskin wrote:
I agree. My gdb cannot show variables in 32-bit binaries (or maybe it's just something Wine specific), but it shows the line numbers. I traced find_symbol() in preloader.c, and it seems like symtabend is 0, so that the last loop is skipped and NULL is returned. This is also evidenced by the lack of "Found" in the log I sent in the previous message.
Perhaps you could try printing out some more debug information in the preloader's find_symbol() function? Can it see any symbols at all? Is it getting past line 795 ((!symtab) || (!strings))?
It's a x86_64 system, but I have the necessary packages for i386 development. I don't have SELinux enabled.
My system is also x86_64, and it works correctly.
Mike
-
David D. Hagood -
Mike McCormack -
Pavel Roskin