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