With yesterday cvs update, whch adds a glibc-threading detection, wine doesnt load a _Windows_ program anymore.
Using the RedHat rpm Yarrow kernel, I get :
err:virtual:map_image Standard load address for a Win32 program (0x00400000) not available - security-patched kernel ? wine: could not load L"C:\arakas.exe" as Win32 binary
Funny thing : If I set up a symlink to the wine-glibc in another directory, it works without problems.
[syl@wine c]$ ls -l /usr/local/bin/wine /home/wine/loader/wine-* -rwxr-xr-x 1 syl wine 97265 nov 13 20:08 /home/wine/loader/wine-glibc -rwxr-xr-x 1 syl wine 156037 nov 13 20:08 /home/wine/loader/wine-kthread -rwxr-xr-x 1 syl wine 109482 nov 13 20:08 /home/wine/loader/wine-pthread -rwxr-xr-x 1 root root 97265 nov 13 20:29 /usr/local/bin/wine
With plain binary, not working : [syl@wine c]$ which wine /usr/local/bin/wine [syl@wine c]$ wine arakas.exe err:virtual:map_image Standard load address for a Win32 program (0x00400000) not available - security-patched kernel ? wine: could not load L"C:\arakas.exe" as Win32 binary
With the symlink : [syl@wine c]$ ls -l /c/wine lrwxrwxrwx 1 syl wine 28 nov 13 20:41 /c/wine -> /home/wine/loader/wine-glibc [syl@wine c]$ ./wine arakas.exe fixme:keyboard:X11DRV_KEYBOARD_DetectLayout Your keyboard layout was not found! Using closest match instead (French keyboard layout) for scancode mapping. Please define your layout in dlls/x11drv/keyboard.c and submit them to us for inclusion into future Wine releases. See the Wine User Guide, chapter "Keyboard" for more information.
Any thoughts ?
===== Sylvain Petreolle (spetreolle_at_users_dot_sourceforge_dot_net) ICQ #170597259 Say NO to software patents Dites NON aux brevets logiciels
"What if tomorrow the War could be over ?" Morpheus, in "Reloaded".
___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
On Thu, 13 Nov 2003 19:54:20 +0100, Sir Sylvain Petreolle scribed thus:
Using the RedHat rpm Yarrow kernel, I get :
err:virtual:map_image Standard load address for a Win32 program (0x00400000) not available - security-patched kernel ? wine: could not load L"C:\arakas.exe" as Win32 binary
Well, are you sure you have disabled exec-shield for the actual wine binaries being used?
--- Mike Hearn mike@theoretic.com a écrit : > On Thu, 13 Nov 2003 19:54:20 +0100, Sir Sylvain Petreolle scribed
thus:
Using the RedHat rpm Yarrow kernel, I get :
err:virtual:map_image Standard load address for a Win32 program (0x00400000) not available - security-patched kernel ? wine: could not load L"C:\arakas.exe" as Win32 binary
Well, are you sure you have disabled exec-shield for the actual wine binaries being used?
I never activated it, and wine worked one week ago. And look at the symlink case.
===== Sylvain Petreolle (spetreolle_at_users_dot_sourceforge_dot_net) ICQ #170597259 Say NO to software patents Dites NON aux brevets logiciels
"What if tomorrow the War could be over ?" Morpheus, in "Reloaded".
___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
Le jeu 13/11/2003 à 17:59, Sylvain Petreolle a écrit :
--- Mike Hearn mike@theoretic.com a écrit : > On Thu, 13 Nov 2003 19:54:20 +0100, Sir Sylvain Petreolle scribed
thus:
Using the RedHat rpm Yarrow kernel, I get :
err:virtual:map_image Standard load address for a Win32 program (0x00400000) not available - security-patched kernel ? wine: could not load L"C:\arakas.exe" as Win32 binary
Well, are you sure you have disabled exec-shield for the actual wine binaries being used?
I never activated it, and wine worked one week ago. And look at the symlink case.
Exec-shield is activated by default, as well as prelinking. Read the release notes of Yarrow if you want to disable them.
What probably happened is you were lucky the first week, in that the random addresses assigned to the various libraries left 0x400000 (the default loading address for Win32 binaries) available, and with enough place to load what you loaded.
The loading addresses for system libraries are changed once per week (or 2 weeks, don't remember). System libraries added after the last complete assignation are assigned a random address at each load, so is you try to execute 10 times in a row the same program, it'll fail some of the time and succeed the remaining times.
I haven't been able to see that message with winelib applications (probably not in a codepath used for winelib apps, didn't checked yet). But it's pretty easy to hit if using Win32 apps.
Disabling exec-shield (either via setarch i386 or with the proc thing) works sometimes, depending on the loading addresses assigned to libraries. If something (libc, libm, libdl, etc.) uses that address, nothing Win32 will be usable. When exec-shield is disabled, new libraries will be assigned loading addresses starting at the lower value possible, but already assigned ones (via prelinking) will still keep theirs, hence possibly blocking execution.
I'll test tomorrow disabling prelinking.
Vincent
On Fri, 2003-11-14 at 04:24, Vincent Béron wrote:
Disabling exec-shield (either via setarch i386 or with the proc thing) works sometimes, depending on the loading addresses assigned to libraries. If something (libc, libm, libdl, etc.) uses that address, nothing Win32 will be usable. When exec-shield is disabled, new libraries will be assigned loading addresses starting at the lower value possible, but already assigned ones (via prelinking) will still keep theirs, hence possibly blocking execution.
I'll test tomorrow disabling prelinking.
Are you saying prelinking can break wine? If so then this is rather bad, prelink is being rolled out on every distro.
Le sam 15/11/2003 à 08:07, Mike Hearn a écrit :
On Fri, 2003-11-14 at 04:24, Vincent Béron wrote:
Disabling exec-shield (either via setarch i386 or with the proc thing) works sometimes, depending on the loading addresses assigned to libraries. If something (libc, libm, libdl, etc.) uses that address, nothing Win32 will be usable. When exec-shield is disabled, new libraries will be assigned loading addresses starting at the lower value possible, but already assigned ones (via prelinking) will still keep theirs, hence possibly blocking execution.
I'll test tomorrow disabling prelinking.
Are you saying prelinking can break wine? If so then this is rather bad, prelink is being rolled out on every distro.
Sorry, forgot to come back to say how testing went.
The best workaround I found (from http://www.codeweavers.com/site/support/tickets/browse/?ticket_id=34072) is to change the default prelinking options, so that the required address is still free for Win32 apps.
If you're hit by this, in file /etc/sysconfig/prelink, change PRELINK_OPTS=-mR to PRELINK_OPTS="-mR --no-exec-shield" The loading addresses chosen will be from 0x40000000, the default value on Linux systems, rather than trying to put the maximum of libraries before 0x01000000 (so that the first byte is always 0x00, rendering string buffer overflows mor difficult to exploit), hence crowding the area we want to keep free (0x00400000).
So far (little testing only, but still), I haven't had a problem with those settings, either running Wine or Linux apps.
Further reading in the referenced page shows Alexandre is in contact with some RedHat people, so hopefully they can come to a solution. RHEL 3 is affected as well, not only Fedora.
Vincent
Can this be applied to all Linux systems ? A Google search on PRELINK_OPTS gives only 4 results and a locate on my Yarrow system doesnt find any 'prelink' file.
The best workaround I found (from
http://www.codeweavers.com/site/support/tickets/browse/?ticket_id=34072)
is to change the default prelinking options, so that the required address is still free for Win32 apps.
If you're hit by this, in file /etc/sysconfig/prelink, change PRELINK_OPTS=-mR to PRELINK_OPTS="-mR --no-exec-shield"
===== Sylvain Petreolle (spetreolle_at_users_dot_sourceforge_dot_net) ICQ #170597259 Say NO to software patents Dites NON aux brevets logiciels
"What if tomorrow the War could be over ?" Morpheus, in "Reloaded".
___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
Le mer 19/11/2003 à 02:39, Sylvain Petreolle a écrit :
Can this be applied to all Linux systems ? A Google search on PRELINK_OPTS gives only 4 results and a locate on my Yarrow system doesnt find any 'prelink' file.
What's the output of rpm -q prelink? Did you installed through an upgrade, or from scratch? What's the output of ldd /usr/bin/wine (or anything dynamically linked to libc)?
Vincent
All,
I am able to use prelinking and wine on my fedora system. Here is how I did it
first I undid all the prelinking with
prelink -a -u
Then I editted /etc/sysconfig/prelink to have these options
PRELINK_OPTS="-m --no-exec-shield"
then I ran prelink with the following options
prelink -a -m --no-exec-shield
And wine has ran fine for me ever since.
kdekorte@localhost bin]$ ldd wine libwine.so.1 => /usr/local/lib/libwine.so.1 (0x40017000) libpthread.so.0 => /lib/tls/libpthread.so.0 (0x412a2000) libc.so.6 => /lib/tls/libc.so.6 (0x41018000) libdl.so.2 => /lib/libdl.so.2 (0x41177000) libm.so.6 => /lib/tls/libm.so.6 (0x41153000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x41000000) [kdekorte@localhost bin]$
Kevin
On Wednesday 19 November 2003 8:04 am, Vincent Béron wrote:
Le mer 19/11/2003 à 02:39, Sylvain Petreolle a écrit :
Can this be applied to all Linux systems ? A Google search on PRELINK_OPTS gives only 4 results and a locate on my Yarrow system doesnt find any 'prelink' file.
What's the output of rpm -q prelink? Did you installed through an upgrade, or from scratch? What's the output of ldd /usr/bin/wine (or anything dynamically linked to libc)?
Vincent
--- Vincent Béron vberon@mecano.gme.usherb.ca a écrit :
What's the output of rpm -q prelink? What's the output of ldd /usr/bin/wine (or anything dynamically linked to libc)?
[syl@wine wine]$ rpm -q prelink package prelink is not installed [syl@wine wine]$ ldd /usr/local/bin/wine libwine.so.1 => /usr/local/lib/libwine.so.1 (0x00111000) libpthread.so.0 => /lib/tls/libpthread.so.0 (0x00c45000) libc.so.6 => /lib/tls/libc.so.6 (0x004e9000) libdl.so.2 => /lib/libdl.so.2 (0x0090d000) libm.so.6 => /lib/tls/libm.so.6 (0x00def000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00ef9000)
Did you installed through an upgrade, or from scratch?
It was an upgrade from RH 9 Shrike (athlon) to Fedora beta3 and upgrade via up2date.
===== Sylvain Petreolle (spetreolle_at_users_dot_sourceforge_dot_net) ICQ #170597259 Say NO to software patents Dites NON aux brevets logiciels
"What if tomorrow the War could be over ?" Morpheus, in "Reloaded".
___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
Le mer 19/11/2003 à 15:24, Sylvain Petreolle a écrit :
--- Vincent Béron vberon@mecano.gme.usherb.ca a écrit :
What's the output of rpm -q prelink? What's the output of ldd /usr/bin/wine (or anything dynamically linked to libc)?
[syl@wine wine]$ rpm -q prelink package prelink is not installed [syl@wine wine]$ ldd /usr/local/bin/wine libwine.so.1 => /usr/local/lib/libwine.so.1 (0x00111000) libpthread.so.0 => /lib/tls/libpthread.so.0 (0x00c45000) libc.so.6 => /lib/tls/libc.so.6 (0x004e9000) libdl.so.2 => /lib/libdl.so.2 (0x0090d000) libm.so.6 => /lib/tls/libm.so.6 (0x00def000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00ef9000)
If prelink is not installed, what you see here is very much probably the result of exec-shield. Does repeating ldd on the same file yields the same results, or do they differ each time?
Did you installed through an upgrade, or from scratch?
It was an upgrade from RH 9 Shrike (athlon) to Fedora beta3 and upgrade via up2date.
So you somehow ended up without prelink (which I thought was part of the base install). Maybe that's a Fedora bug, but maybe not.
Vincent
On Wed, 2003-11-19 at 21:29, Vincent Béron wrote:
Le mer 19/11/2003 à 15:24, Sylvain Petreolle a écrit :
--- Vincent Béron vberon@mecano.gme.usherb.ca a écrit :
What's the output of rpm -q prelink? What's the output of ldd /usr/bin/wine (or anything dynamically linked to libc)?
[syl@wine wine]$ rpm -q prelink package prelink is not installed [syl@wine wine]$ ldd /usr/local/bin/wine libwine.so.1 => /usr/local/lib/libwine.so.1 (0x00111000) libpthread.so.0 => /lib/tls/libpthread.so.0 (0x00c45000) libc.so.6 => /lib/tls/libc.so.6 (0x004e9000) libdl.so.2 => /lib/libdl.so.2 (0x0090d000) libm.so.6 => /lib/tls/libm.so.6 (0x00def000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00ef9000)
If prelink is not installed, what you see here is very much probably the result of exec-shield. Does repeating ldd on the same file yields the same results, or do they differ each time?
I have the same configuration as Sylvain (RH9 -> Fedora Core 1) and I have the same behavior. When I do a ldd wine I have always the same result.
Did you installed through an upgrade, or from scratch?
It was an upgrade from RH 9 Shrike (athlon) to Fedora beta3 and upgrade via up2date.
I upgraded from RH9 to FC1 with the iso cds.
So you somehow ended up without prelink (which I thought was part of the base install). Maybe that's a Fedora bug, but maybe not.
I do not have prelink installed too.
Vincent
Vincent, after doing some tests, even with this applied, I must run Wine several times to have a windows program starting, otherwise I have the error message.
Do you thnk that downloading prelink is another workaround ?
If you're hit by this, in file /etc/sysconfig/prelink, change PRELINK_OPTS=-mR to PRELINK_OPTS="-mR --no-exec-shield"
Merci à ton pote et désolé du dérangement ;)
===== Sylvain Petreolle (spetreolle_at_users_dot_sourceforge_dot_net) ICQ #170597259 Say NO to software patents Dites NON aux brevets logiciels
"What if tomorrow the War could be over ?" Morpheus, in "Reloaded".
___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
Le jeu 20/11/2003 à 18:13, Sylvain Petreolle a écrit :
Vincent, after doing some tests, even with this applied, I must run Wine several times to have a windows program starting, otherwise I have the error message.
Do you thnk that downloading prelink is another workaround ?
If you only have exec-shield bothering you, you can try setarch i386 wine ... It'll disable it for this run only.
Or, if you want to disable it in a more complete way, echo 0>/proc/sys/kernel/exec-shield (or exec-shield-random). It'll go away until next reboot.
Still, it's strange that prelink didn't got installed in the first place...
If you're hit by this, in file /etc/sysconfig/prelink, change PRELINK_OPTS=-mR to PRELINK_OPTS="-mR --no-exec-shield"
Merci à ton pote et désolé du dérangement ;)
Pas de problème :)
Vincent
-
Kevin DeKorte -
Maxime Bellengé -
Mike Hearn -
Sylvain Petreolle -
Vincent Béron