halflife majorly crashes on me: err:local:LOCAL_GetBlock not enough space in GDI heap 01ff for 112 bytes for thousands of lines, until it eventually pukes and wants to debug. then it tells me: Couldn't start process '148738992 0x84 ' (twice) Why? I don't know. I remember installing it under wine, but it always puked on me like that afterwards. I have 128MB of RAM so that shouldn't be a problem.
Not sure. I think some people have got half life to work.
It sounds like the program is getting stuck in a loop trying to allocate GDI resources, which are presumably limited. I don't know if Wine simulates the Win9x resource limitations or not (i hope not!). Try doing a relay trace and looking at what happens just before it starts to die.
On Thu, 2003-01-30 at 22:29, Scott Jackson wrote:
halflife majorly crashes on me: err:local:LOCAL_GetBlock not enough space in GDI heap 01ff for 112 bytes for thousands of lines, until it eventually pukes and wants to debug. then it tells me: Couldn't start process '148738992 0x84 ' (twice) Why? I don't know. I remember installing it under wine, but it always puked on me like that afterwards. I have 128MB of RAM so that shouldn't be a problem.
On Fri, Jan 31, 2003 at 09:05:17AM +0000, Mike Hearn wrote:
Not sure. I think some people have got half life to work.
It sounds like the program is getting stuck in a loop trying to allocate GDI resources, which are presumably limited. I don't know if Wine simulates the Win9x resource limitations or not (i hope not!). Try doing a relay trace and looking at what happens just before it starts to die.
Well, in some cases the objects are allocated on a pretty limited heap. The palette object was moved to a larger heap because of this.
A relay trace is done by executing wine with which debug flags?? I've seen traces done on wine, but I also know there are damn near 50 ways to trace... I'm guessing it's NOT "wine -debug trace+relay" :-) if it is please tell me to kick myself
On 31 Jan 2003 09:05:17 +0000 Mike Hearn m.hearn@signal.qinetiq.com wrote:
Not sure. I think some people have got half life to work.
It sounds like the program is getting stuck in a loop trying to allocate GDI resources, which are presumably limited. I don't know if Wine simulates the Win9x resource limitations or not (i hope not!). Try doing a relay trace and looking at what happens just before it starts to die.
Mike Hearn m.hearn@signal.qinetiq.com QinetiQ - Malvern Technology Center
Scott Jackson wrote:
A relay trace is done by executing wine with which debug flags?? I've seen traces done on wine, but I also know there are damn near 50 ways to trace... I'm guessing it's NOT "wine -debug trace+relay" :-) if it is please tell me to kick myself
Thats some pretty old documentation your looking at. No the following should work
wine -debugmsg +relay "C:\where ever\the\program\is"
ok, did the relay trace, but I came up with about 700,000 lines of error... I could give you the bottom or attach it (but it's 48 MEGS)... is there any way I can relay trace to where it won't send me 700,000 lines?? thanks
On Fri, 31 Jan 2003 21:45:23 -0700 Tony Lambregts tony_lambregts@telusplanet.net wrote:
Thats some pretty old documentation your looking at. No the following should work
wine -debugmsg +relay "C:\where ever\the\program\is"
--
Tony Lambregts
Those lines aren't errors, they're logging each API call.
If you know a bit about programming, you can probably examine the end of the trace and see what happened just before it went wrong. That's when you start debugging :)
On Sat, 2003-02-01 at 17:42, Scott Jackson wrote:
ok, did the relay trace, but I came up with about 700,000 lines of error... I could give you the bottom or attach it (but it's 48 MEGS)... is there any way I can relay trace to where it won't send me 700,000 lines?? thanks
On Fri, 31 Jan 2003 21:45:23 -0700 Tony Lambregts tony_lambregts@telusplanet.net wrote:
Thats some pretty old documentation your looking at. No the following should work
wine -debugmsg +relay "C:\where ever\the\program\is"
--
Tony Lambregts
Alright, now that I know what's up, we might be able to get down to business. I ran it with -debugmsg +err,+relay so that I would be able to pick out what happened at each of these: err:local:LOCAL_GetBlock not enough space in GDI heap 01ff for 112 bytes since I'm only 16 :-) I don't know much 'bout programming, so I might need some help with making this out. 080787e0:Call kernel32.LOCAL_Alloc(000001ff,00000002,00000068) ret=409cfbf8 may be the offender in this case (this is the line right before err:local) It seems that other "kernel32.LOCAL_Alloc" instances were able to get off the hook, so I think it may actualy *be* limited GDI resources. the question is, why are there so few GDI resources? I'm also wondering about the presence of the damn ntdll lines, they might be fscking with my heap, and that's not good, is it? PS: What is GDI? :-P Thanks
----------- OUTPUT (highly cropped :-) ) -------- 080787e0:Call kernel32.CreateFileA(40758c28 "C:\Program Files\Half-Life\valve\gfx\shell\cb_disabled.bmp",80000000,00000003,40758b80,00000003,00000080,00000000) ret=0048e4ee 080787e0:Ret kernel32.CreateFileA() retval=ffffffff ret=0048e4ee 080787e0:Call kernel32.GetLastError() ret=0048e4fa 080787e0:Ret kernel32.GetLastError() retval=00000002 ret=0048e4fa 080787e0:Call kernel32.GetLastError() ret=00487e0b 080787e0:Ret kernel32.GetLastError() retval=00000002 ret=00487e0b 080787e0:Call kernel32.TlsGetValue(00000007) ret=00487e19 080787e0:Ret kernel32.TlsGetValue() retval=42880f80 ret=00487e19 080787e0:Call kernel32.SetLastError(00000002) ret=00487e65 080787e0:Ret kernel32.SetLastError() retval=00000002 ret=00487e65 080787e0:Call kernel32.GetLastError() ret=00487e0b 080787e0:Ret kernel32.GetLastError() retval=00000002 ret=00487e0b 080787e0:Call kernel32.TlsGetValue(00000007) ret=00487e19 080787e0:Ret kernel32.TlsGetValue() retval=42880f80 ret=00487e19 080787e0:Call kernel32.SetLastError(00000002) ret=00487e65 080787e0:Ret kernel32.SetLastError() retval=00000002 ret=00487e65 080787e0:Call ntdll.RtlLeaveCriticalSection(4277444c) ret=004871ad 080787e0:Ret ntdll.RtlLeaveCriticalSection() retval=00000000 ret=004871ad 080787e0:Call ntdll.RtlLeaveCriticalSection(42880010) ret=004874a5 080787e0:Ret ntdll.RtlLeaveCriticalSection() retval=00000000 ret=004874a5 080787e0:Call kernel32.GetLastError() ret=00487e0b 080787e0:Ret kernel32.GetLastError() retval=00000002 ret=00487e0b 080787e0:Call kernel32.TlsGetValue(00000007) ret=00487e19 080787e0:Ret kernel32.TlsGetValue() retval=42880f80 ret=00487e19 080787e0:Call kernel32.SetLastError(00000002) ret=00487e65 080787e0:Ret kernel32.SetLastError() retval=00000002 ret=00487e65 080787e0:Call user32.LoadStringA(17000000,0000003b,40758648,00000400) ret=004664b5 080787e0:Call ntdll.RtlAllocateHeap(40250000,00000000,00000800) ret=409208c9 080787e0:Ret ntdll.RtlAllocateHeap() retval=454d2de8 ret=409208c9 080787e0:Call kernel32.FindResourceW(17000000,00000004,00000006) ret=40920749 080787e0:Ret kernel32.FindResourceW() retval=17001518 ret=40920749 080787e0:Call kernel32.LoadResource(17000000,17001518) ret=4092075e 080787e0:Ret kernel32.LoadResource() retval=170027d8 ret=4092075e 080787e0:Call kernel32.LockResource(170027d8) ret=4092076e 080787e0:Ret kernel32.LockResource() retval=170027d8 ret=4092076e 080787e0:Call kernel32.WideCharToMultiByte(00000000,00000000,454d2de8 L"Could not open bitmap file '%s'.",00000020,40758648,000003ff,00000000,00000000) ret=40920913 080787e0:Ret kernel32.WideCharToMultiByte() retval=00000020 ret=40920913 080787e0:Call ntdll.RtlFreeHeap(40250000,00000000,454d2de8) ret=4092096d 080787e0:Ret ntdll.RtlFreeHeap() retval=00000001 ret=4092096d 080787e0:Ret user32.LoadStringA() retval=00000020 ret=004664b5 080787e0:Call gdi32.CreateFontA(fffffff5,00000000,00000000,00000000,00000190,00000000,00000000,00000000,00000000,00000004,00000000,00000002,00000002,004cd7d4 "Arial") ret=0043edb9 080787e0:Call kernel32.lstrcpynA(4075821c,004cd7d4 "Arial",00000020) ret=409cab09 080787e0:Ret kernel32.lstrcpynA() retval=4075821c ret=409cab09 080787e0:Call kernel32.MultiByteToWideChar(00000000,00000000,4075821c "Arial",ffffffff,4075818c,00000020) ret=409ca593 080787e0:Ret kernel32.MultiByteToWideChar() retval=00000006 ret=409ca593 080787e0:Call kernel32._EnterSysLevel(409f5c44) ret=409cfbb2 080787e0:Ret kernel32._EnterSysLevel() retval=0000000c ret=409cfbb2 080787e0:Call kernel32.LOCAL_Alloc(000001ff,00000002,00000068) ret=409cfbf8 err:local:LOCAL_GetBlock not enough space in GDI heap 01ff for 112 bytes 080787e0:Ret kernel32.LOCAL_Alloc() retval=00000000 ret=409cfbf8 080787e0:Call kernel32._LeaveSysLevel(409f5c44) ret=409cfd60 080787e0:Ret kernel32._LeaveSysLevel() retval=00000000 ret=409cfd60 -------------- (FIN) ----------------
On 01 Feb 2003 17:54:10 +0000 Mike Hearn mike@theoretic.com wrote:
Those lines aren't errors, they're logging each API call.
If you know a bit about programming, you can probably examine the end of the trace and see what happened just before it went wrong. That's when you start debugging :)
------ "De-fault! The two sweetest words in the English language." -- Homer Simpson
Get Gaim for unix or win32 systems! gaim.sourceforge.net Scott "Action" Jackson - scott_j@ajackson.org
080787e0:Call kernel32.LOCAL_Alloc(000001ff,00000002,00000068) ret=409cfbf8 may be the offender in this case (this is the line right before err:local)
Hmmm. Maybe. I think here though this call is what is wrong:
080787e0:Call kernel32.CreateFileA(40758c28 "C:\Program Files\Half-Life\valve\gfx\shell\cb_disabled.bmp",80000000,00000003,40758b80,00000003,00000080,00000000) ret=0048e4ee 080787e0:Ret kernel32.CreateFileA() retval=ffffffff ret=0048e4ee
The very first ones you pasted in fact. MSDN says that CreateFile should return a handle to a file, but if it goes wrong it'll return INVALID_HANDLE_VALUE. The calls to GetLastError immediately afterwards strongly suggest that's what's happening, and in fact the retval section is what you're interested in here: ffffffffff is -1 in hex (using twos compliment, thanks francois!).
So basically it looks like it can't open cb_disabled.bmp, and that leads to a cascade failure. Remember that often apps will try to recover from an error but fail so you need to look quite a bit up the trace to discover what's going on.
080787e0:Call kernel32.GetLastError() ret=0048e4fa 080787e0:Ret kernel32.GetLastError() retval=00000002 ret=0048e4fa
And in fact the app detects it went wrong, and calls GetLastError. The part you are interested in here is retval, which is 2. MSDN tells us that is ERROR_FILE_NOT_FOUND, so it didn't find the file. Have a poke around, make sure it installed correctly would be what I'd do next.
thanks -mike
Isnt there a problem into the path here ? A \ is missing after C:\Program
Hmmm. Maybe. I think here though this call is what is wrong:
080787e0:Call kernel32.CreateFileA(40758c28 "C:\Program
Files\Half-Life\valve\gfx\shell\cb_disabled.bmp",80000000,00000003,40758b80,00000003,00000080,00000000)
ret=0048e4ee
080787e0:Ret kernel32.CreateFileA() retval=ffffffff ret=0048e4ee
The very first ones you pasted in fact. MSDN says that CreateFile should return a handle to a file, but if it goes wrong it'll return INVALID_HANDLE_VALUE. The calls to GetLastError immediately afterwards strongly suggest that's what's happening, and in fact the retval section is what you're interested in here: ffffffffff is -1 in hex (using twos compliment, thanks francois!).
So basically it looks like it can't open cb_disabled.bmp, and that leads to a cascade failure. Remember that often apps will try to recover from an error but fail so you need to look quite a bit up the trace to discover what's going on.
080787e0:Call kernel32.GetLastError() ret=0048e4fa 080787e0:Ret kernel32.GetLastError() retval=00000002 ret=0048e4fa
And in fact the app detects it went wrong, and calls GetLastError. The part you are interested in here is retval, which is 2. MSDN tells us that is ERROR_FILE_NOT_FOUND, so it didn't find the file. Have a poke around, make sure it installed correctly would be what I'd do next.
thanks -mike
===== Sylvain Petreolle spetreolle@users.sourceforge.net Fight against Spam ! http://www.euro.cauce.org/en/index.html ICQ #170597259
"Don't think you are. Know you are." Morpheus, in "Matrix".
___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
-
Johan Gill -
Mike Hearn -
Mike Hearn -
Scott Jackson -
Sylvain Petreolle -
Tony Lambregts