[Bug 1406] 16-BIT VB 3.0 APP -- "NOT ENOUGH SPACE FOR ENVIROMENT"

[Wine Bugs]

http://bugs.winehq.com/show_bug.cgi?id=1406





------- Additional Comments From z_god(a)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.

-- 
Configure bugmail: http://bugs.winehq.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.