miscemu/wine gets into the way in map_image

[Uwe Bonnes]

Hallo,

the full installer for XILINX Webpack 5.1 is a 160 MByte executable.
It doesn't start with wine:
> ~/tmp/wine/compile/wine/wine WebPACK_51_fcfull_i.exe
> err:virtual:map_image Standard load address for a Win32 program (0x00400000)
> not available - security-patched kernel ?
> Clearly my kernel isn't "security-patched".

Printing out /proc/maps/self in this situation shows:
08048000-0805c000 r-xp 00000000 03:08 195157 /home/bon/tmp/wine/compile/wine-realclean/wine/miscemu/wine
0805c000-0805d000 rw-p 00013000 03:08 195157 /home/bon/tmp/wine/compile/wine-realclean/wine/miscemu/wine

An strace on wine shows the mmap call in map_image:
23236 mmap2(0x400000, 161087488, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x404c2000

Adding 0x400000 and 161087488 gives someting in the 0x09d0000 range. This
overlaps with the wine executable itself and mmap2 can't satisfiy the request
in place.

Any ideas what to do about that?

Thanks
-- 
Uwe Bonnes                bon(a)elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. [phone] -------- Fax. [phone] ----------

[Ove Kaaven]

On Thu, 3 Oct 2002, Uwe Bonnes wrote:
> Hallo,
>
> the full installer for XILINX Webpack 5.1 is a 160 MByte executable.
> It doesn't start with wine:
> > ~/tmp/wine/compile/wine/wine WebPACK_51_fcfull_i.exe
> > err:virtual:map_image Standard load address for a Win32 program (0x00400000)
> > not available - security-patched kernel ?
> > Clearly my kernel isn't "security-patched".
>
> Printing out /proc/maps/self in this situation shows:
> 08048000-0805c000 r-xp 00000000 03:08 195157 /home/bon/tmp/wine/compile/wine-realclean/wine/miscemu/wine
> 0805c000-0805d000 rw-p 00013000 03:08 195157 /home/bon/tmp/wine/compile/wine-realclean/wine/miscemu/wine
>
> An strace on wine shows the mmap call in map_image:
> 23236 mmap2(0x400000, 161087488, PROT_READ|PROT_WRITE|PROT_EXEC,
> MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x404c2000
>
> Adding 0x400000 and 161087488 gives someting in the 0x09d0000 range. This
> overlaps with the wine executable itself and mmap2 can't satisfiy the request
> in place.

Looks like the same issue that Dungeon Siege's installer has. My idea so
far has been to move all of the important stuff in the main wine loader
into libwine (so that the wine loader is just a call into libwine), then
libwine's main routine could somehow munmap the loader. Haven't got around
to doing this yet though.

[Alexandre Julliard]

Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes:
> Adding 0x400000 and 161087488 gives someting in the 0x09d0000 range. This
> overlaps with the wine executable itself and mmap2 can't satisfiy the request
> in place.

Here's an ugly non-portable hack that might work if you are lucky:

Index: miscemu/Makefile.in
===================================================================
RCS file: /opt/cvs-commit/wine/miscemu/Makefile.in,v
retrieving revision 1.10
diff -u -r1.10 Makefile.in
--- miscemu/Makefile.in	12 Sep 2002 00:52:16 -0000	1.10
+++ miscemu/Makefile.in	3 Oct 2002 17:10:43 -0000
@@ -19,7 +19,7 @@
 ALL_OBJS = $(SPEC_SRCS:.spec=.spec.o) $(OBJS)
 
 $(MODULE): $(ALL_OBJS)
-	$(CC) -o $@ $(ALL_OBJS) -L$(DLLDIR) $(LDIMPORTS:%=-l%) $(LIBWINE) $(LIBUNICODE) $(LIBS) $(LDFLAGS)
+	$(CC) -o $@ -Wl,--section-start,.interp=0x3ff00100 $(ALL_OBJS) -L$(DLLDIR) $(LDIMPORTS:%=-l%) $(LIBWINE) $(LIBUNICODE) $(LIBS) $(LDFLAGS)
 
 wine.spec.c: wine.spec
 	$(LDPATH) $(WINEBUILD) $(DEFS) -o $@ -spec $(SRCDIR)/wine.spec -mgui -L$(DLLDIR) $(IMPORTS:%=-l%)


-- 
Alexandre Julliard
julliard(a)winehq.com

[Uwe Bonnes]

> > > > > "Alexandre" == Alexandre Julliard <julliard(a)winehq.com> writes:

Alexandre> Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes:
    >> Adding 0x400000 and 161087488 gives someting in the 0x09d0000
    >> range. This overlaps with the wine executable itself and mmap2 can't
    >> satisfiy the request in place.

    Alexandre> Here's an ugly non-portable hack that might work if you are
    Alexandre> lucky:

Thanks, that helps.

However when unzip has unpacked the 160 MByte file and the Setup should
start, a crash happens, and the debugger startup stops with "Memory
exhausted". The same happens when I run in winedbg:
Loaded debug information from ELF
'/home/bon/tmp/wine/compile/wine/miscemu/wine' (0x00000000)
Breakpoint 2 at 0x4000c714 (_end+0xf7fec)
Memory exhausted.

Now I am trying to run with relay enabled...

Bye

-- 
Uwe Bonnes                bon(a)elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. [phone] -------- Fax. [phone] ----------

[Alexandre Julliard]

Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes:
> However when unzip has unpacked the 160 MByte file and the Setup should
> start, a crash happens, and the debugger startup stops with "Memory
> exhausted". The same happens when I run in winedbg:
> Loaded debug information from ELF
> '/home/bon/tmp/wine/compile/wine/miscemu/wine' (0x00000000)
> Breakpoint 2 at 0x4000c714 (_end+0xf7fec)
> Memory exhausted.

You probably need reduce the base address a bit to leave more space
for malloc(). Try changing the 0x3ff to 0x3f0. Now of course we
shouldn't be using malloc, so that hack would be a good way to enforce
that <g>

-- 
Alexandre Julliard
julliard(a)winehq.com

[Uwe Bonnes]

> > > > > "Alexandre" == Alexandre Julliard <julliard(a)winehq.com> writes:

Alexandre> Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes:
    >> However when unzip has unpacked the 160 MByte file and the Setup
    >> should start, a crash happens, and the debugger startup stops with
    >> "Memory exhausted". The same happens when I run in winedbg: Loaded
    >> debug information from ELF
    >> '/home/bon/tmp/wine/compile/wine/miscemu/wine' (0x00000000)
    >> Breakpoint 2 at 0x4000c714 (_end+0xf7fec) Memory exhausted.

    Alexandre> You probably need reduce the base address a bit to leave more
    Alexandre> space for malloc(). Try changing the 0x3ff to 0x3f0. Now of
    Alexandre> course we shouldn't be using malloc, so that hack would be a
    Alexandre> good way to enforce that <g>

Yes, with 0x3f000000 the debugger start.
About the problem I will report in separate mail.

Bye

-- 
Uwe Bonnes                bon(a)elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. [phone] -------- Fax. [phone] ----------