http://bugs.winehq.com/show_bug.cgi?id=1406
------- Additional Comments From z_god@wanadoo.nl 2003-28-06 10:54 ------- Bug comments restored from Gmane.org:
I have been hoping to see this working with baseline WINE releases for about 2 years now. It's not a high priority but it's a curious problem. One particular application I have errors out with a "NOT ENOUGH SPACE FOR ENVIRONMENT" message on startup. I do not have the source code for this application.
The application itself is a 16-bit VB 3.0 application used to access an online database. The header indicates it's an MZ type executable and the imports show it's based on VBRUN300. There's an NE marker in the header as well. Another application with exactly the same header (but a different app nonetheless) works just fine.
The WINE trace shows the following as the cause:
err:local:LOCAL_GetBlock not enough space in local heap 0dc7 for 140 bytes
Now, all that said, if I uncomment the FIXMEs int memory/local.c and prevent the call from returning 0 in LOCAL_GetBlock, it works fine (for a while at least). So, I guess the question is, why are the FIXME's in that function still FIXME's after all this time. I'm sure there is a reason for not uncommenting this code but if anybody could shed light on this, or get the FIXME's accepted it would be really appreciated.
------- Additional Comments From marc_lavergne <at> yahoo.com 2003-04-22 21:40 ------- I did some more digging, it appears that the local heap is hitting the 64K barrier on an attempt to grow it. The application actually fails in GrowHeap around line 500 where the check to see if oldheap > 0xfff0 eval to true and a FALSE gets returned. The error just bubbles up from the call to GrowHeap in GetBlock. All the heap pointers and size values seem normal, so it's really running out of space. Fair enough, so the question becomes WHY is the heap NOT being exceeded in native Win98 but IS being exceeded in WINE. It only makes sense that some cleanup of the heap happens under native Win that is not happening under WINE. I'm a little at a loss from that point though. I assume a heap walker like program would be helpful.
------- Additional Comments From bon <at> elektron.ikp.physik.tu-darmstadt.de 2003-04-23 02:37 ------- Probably we put things on the local heap that don't belong there. Try to find out what items there take up the most space.
------- Additional Comments From marc_lavergne <at> yahoo.com 2003-04-23 07:26 ------- Makes sense. Can you recommend a program that will let me see calls to the local heap under Win9x and I will try to track it down. The error occurs early during startup so accounting for the allocations by hand is a possibility. I'll compare it to the calls I see under WINE and post back.
On another note, there's a an application that starts with the problem VB program auto-magically under Win98, WSASRV.EXE (Windows Sockets Asynchronous Request Server). It appears it is being launched by one of the VBXs. This program does not start with the "working" VB 3.0 16-bit prog.
Also, I took a look at the heap using HEAPWALK.EXE but it didn't show anything of value besides a rough count of 1.8M for the total heap size when running under Win98.
------- Additional Comments From marc_lavergne <at> yahoo.com 2003-05-15 22:56 ------- Since there's a workaround, moving this to a normal severity. I haven't had a chance to revisit it but I will get the heap alloc trace done shortly. Workaround: modify LOCAL_GetBlock in memory/local.c to prevent arena==0 exits. Not a permanent fix since it introduces an unhandled condition and is "the wrong way to do things" anyhow.
-
Wine Bugs