Hello, i compiled wine cvs on my amd64 without many problem (i had to set PATH to point to a directory with wrappers for gcc,ld and as that would call respectively "gcc -m32","ld -melf_i386","as --32", it would be nice if wine would support natively this or would support LDFLAGS=-melf_i368.., but this is not the point). When i started wine i got: wine: failed to create the process heap The same wine executable was running ok on my 32bits distro. I read that this happens on fedora2 too because of nx stack, and i think that, even if i do not have SeLinux installed, the stack is not executable by default on amd64... Do you have any idea of how this could be fixed/hacked? Thanx Maurizio I am not subscribed to wine-devel, so please CC monge(at)sns(dot)it
On Sat, 15 May 2004 08:19:26 +0200, Maurizio Monge wrote: Hello, i compiled wine cvs on my amd64 without many problem (i had
to set PATH to point to a directory with wrappers for gcc,ld and as that would call respectively "gcc -m32","ld -melf_i386","as --32", it would be nice if wine would support natively this or would support LDFLAGS=-melf_i368.., but this is not the point). When i started wine i got:
wine: failed to create the process heap
The same wine executable was running ok on my 32bits distro. I read that this happens on fedora2 too because of nx stack, and i think that, even if i do not have SeLinux installed, the stack is not executable by default on amd64...
Do you have any idea of how this could be fixed/hacked?
Probably something is being loaded at the address we need to create the heap at - check that you don't have things like execshield/prelink active - it's not the NX stack that breaks Wine, it's the DSO load address randomization.
..]
wine: failed to create the process heap
The same wine executable was running ok on my 32bits distro. I read that this happens on fedora2 too because of nx stack, and i think that, even if i do not have SeLinux installed, the stack is not executable by default on amd64...
Do you have any idea of how this could be fixed/hacked?
Probably something is being loaded at the address we need to create the heap at - check that you don't have things like execshield/prelink active - it's not the NX stack that breaks Wine, it's the DSO load address randomization.
Mh, i'm not convinced :-) I do not have execshield (kernel 2.6.4-rc2 with only supermount and reiser4 patches) or prelink. The strange thing is that it MUST be a kernel problem because: [root(a)fucklandia maurizio]# wine wine: failed to create the process heap [root(a)fucklandia maurizio]# chroot /partitions/mandrake32/ [root(a)fucklandia /]# wine wine: failed to create the process heap /partitions/mandrake32/ is a 32bits only install, and wine (the same executable) runs on mandrake32 (with its 32bits kernel). Thanx Maurizio I am not subscribed to wine-devel, so please CC monge(at)sns(dot)it
On Sun, 2004-05-16 at 15:40 +0200, Maurizio Monge wrote:
Mh, i'm not convinced :-) I do not have execshield (kernel 2.6.4-rc2 with only supermount and reiser4 patches) or prelink. The strange thing is that it MUST be a kernel problem because:
Put code which dumps the maps list when the process heap can't be created, ie something like: { char buffer[100]; sprintf(buffer, "cat /proc/%d/maps", getpid(); system(buffer); } and see what is sitting at the place we're trying to create the heap. -mike
Mike Hearn <mh(a)codeweavers.com> writes:
Put code which dumps the maps list when the process heap can't be created, ie something like:
{ char buffer[100]; sprintf(buffer, "cat /proc/%d/maps", getpid(); system(buffer); }
and see what is sitting at the place we're trying to create the heap.
The process heap can be placed anywhere, this isn't the cause of the problem. You are confusing it with the shared heap. -- Alexandre Julliard julliard(a)winehq.org
On Sun, 2004-05-16 at 11:25 -0700, Alexandre Julliard wrote:
The process heap can be placed anywhere, this isn't the cause of the problem. You are confusing it with the shared heap.
Oops, so I am :( Maurizio, try a +heap trace - that section of code doesn't have much tracing in so you may need to add some TRACEs to dlls/ntdll/heap.c to find out why HEAP_CreateSubHeap is returning null.
On Mon, 17 May 2004 04:25 am, Alexandre Julliard wrote:
Mike Hearn <mh(a)codeweavers.com> writes:
Put code which dumps the maps list when the process heap can't be created, ie something like:
{ char buffer[100]; sprintf(buffer, "cat /proc/%d/maps", getpid(); system(buffer); }
and see what is sitting at the place we're trying to create the heap.
The process heap can be placed anywhere, this isn't the cause of the problem. You are confusing it with the shared heap.
Isn't this likely to be just the fact that the heap is being mapped above 0xC0000000 same as under solaris. Sounds like it to me ! Bob
Alle Monday 17 May 2004 13:00, Robert Lunnon ha scritto:
On Mon, 17 May 2004 04:25 am, Alexandre Julliard wrote:
Mike Hearn <mh(a)codeweavers.com> writes:
Put code which dumps the maps list when the process heap can't be created, ie something like:
{ char buffer[100]; sprintf(buffer, "cat /proc/%d/maps", getpid(); system(buffer); }
and see what is sitting at the place we're trying to create the heap.
The process heap can be placed anywhere, this isn't the cause of the problem. You are confusing it with the shared heap.
Isn't this likely to be just the fact that the heap is being mapped above 0xC0000000 same as under solaris. Sounds like it to me !
Bob
Arg! You're right! failure in NtAllocateVirtualMemory, line 1054 of virtual.c, if ( [conditions not met] ... || (ADDRESS_SPACE_LIMIT && ((char *)base + size > (char *)ADDRESS_SPACE_LIMIT)) return STATUS_INVALID_PARAMETER; where STATUS_INVALID_PARAMETER is #defined 0xC0000000 Maurizio PS:plase CC monge(at)sns(dot)it
participants (4)
-
Alexandre Julliard -
Maurizio Monge -
Mike Hearn -
Robert Lunnon