Another crash on exit with gcc (MinGW)

Discuss anything ZDoom-related that doesn't fall into one of the other categories.
Post Reply
User avatar
drfrag
Vintage GZDoom Developer
Posts: 3141
Joined: Fri Apr 23, 2004 3:51 am
Location: Spain
Contact:
Contact drfrag

Another crash on exit with gcc (MinGW)

Post by drfrag »

I've been investigating the crash on exit in Blzut3's builds, i don't know how to fix this (not surprising since i think he couldn't either). I've compiled GZDoom 2.4 (but it's the same code in the latest version). I think he used tdm-gcc 5.1 as well, i wonder if this happens with MSYS2.
This comes from: viewtopic.php?f=4&t=54983&start=45#p975669

It's a crash in vmframe.cpp (PopFrame).

Code: Select all

VMFrame *VMFrameStack::PopFrame()
{
	if (Blocks == NULL)
	{
		return NULL;
	}
	VMFrame *frame = Blocks->LastFrame;
	if (frame == NULL)
	{
		return NULL;
	}
	auto Func = static_cast<VMScriptFunction *>(frame->Func);
	if (Func->SpecialInits.Size())
	{
		Func->DestroyExtra(frame->GetExtra());
	}
...
Line 376 is auto Func = static_cast<VMScriptFunction *>(frame->Func);
Changing the line for if (frame->Func != NULL) still crashes there. So frame->Func is not NULL but can't be accesed after exiting (after pressing 'Y' in the exit menu). May be LastFrame should be set to NULL somewhere else. I could add an ugly hack but there has to be a better solution.

Stack trace:

Code: Select all

Program received signal SIGSEGV, Segmentation fault.
0x00806fc7 in VMFrameStack::PopFrame (this=this@entry=0x7ffde000) at C:\DEV\gzdoom\src\scripting\vm\vmframe.cpp:376
SUB SUB C:\DEV\gzdoom\src\scripting\vm\vmframe.cpp:376:9209:beg:0x806fc7
>>>>>>cb_gdb:frame = 0x75b67220 <msvcrt!_local_unwind4+464>
regs = <optimized out>
param = <optimized out>
parent = <optimized out>
>>>>>>cb_gdb:this = 0x7ffde000
>>>>>>cb_gdb:#0  0x00806fc7 in VMFrameStack::PopFrame (this=this@entry=0x7ffde000) at C:\DEV\gzdoom\src\scripting\vm\vmframe.cpp:376
#1  0x00807163 in VMFrameStack::~VMFrameStack (this=0x7ffde000, __in_chrg=<optimized out>) at C:\DEV\gzdoom\src\scripting\vm\vmframe.cpp:241
#2  0x008e75c8 in (anonymous namespace)::run(void*) ()
#3  0x77c5a54a in ntdll!ZwQueryInformationProcess () from C:\Windows\SYSTEM32\ntdll.dll
#4  0x0b55de88 in ?? ()
#5  0x75b540e1 in msvcrt!exit () from C:\Windows\system32\msvcrt.dll
#6  0x00427342 in ST_Endoom () at C:\DEV\gzdoom\src\win32\st_start.cpp:1132
#7  0x004affdc in operator() (__closure=0x0) at C:\DEV\gzdoom\src\menu\messagebox.cpp:113
#8  <lambda()>::_FUN(void) () at C:\DEV\gzdoom\src\menu\messagebox.cpp:114
#9  0x004afe79 in AF_DMessageBoxMenu_CallHandler (param=0xaddeb60, defaultparam=..., numparam=1, ret=0x23f210, numret=0) at C:\DEV\gzdoom\src\menu\messagebox.cpp:56
#10 0x0097007d in VMExec_Unchecked::Exec (stack=0xaf56f5c, pc=0xacc3ce0, ret=0x23f370, numret=0) at C:/DEV/gzdoom/src/scripting/vm/vmexec.h:681
#11 0x00970684 in VMExec_Unchecked::Exec (stack=0xaf56f5c, pc=0xacc3e9c, ret=0x23f4d0, numret=1) at C:/DEV/gzdoom/src/scripting/vm/vmexec.h:700
#12 0x008072a5 in VMFrameStack::Call (this=0xaf56f5c, func=0xb2de0c8, params=params@entry=0x23f4f0, numparams=2, results=0x23f4d0, numresults=1, trap=0x0) at C:\DEV\gzdoom\src\scripting\vm\vmframe.cpp:469
#13 0x004a38ac in DMenu::CallResponder (this=<optimized out>, ev=ev@entry=0x1c77590 <events+48>) at C:\DEV\gzdoom\src\menu\menu.cpp:185
#14 0x004a4b1e in M_Responder (ev=ev@entry=0x1c77590 <events+48>) at C:\DEV\gzdoom\src\menu\menu.cpp:595
#15 0x005ed828 in D_ProcessEvents () at C:\DEV\gzdoom\src\d_main.cpp:288
#16 0x005f671b in NetUpdate () at C:\DEV\gzdoom\src\d_net.cpp:981
#17 0x005f7386 in TryRunTics () at C:\DEV\gzdoom\src\d_net.cpp:1836
#18 0x005ef4a0 in D_DoomLoop () at C:\DEV\gzdoom\src\d_main.cpp:1029
#19 0x005f29d6 in D_DoomMain () at C:\DEV\gzdoom\src\d_main.cpp:2700
#20 0x0042064c in DoMain (hInstance=hInstance@entry=0x400000) at C:\DEV\gzdoom\src\win32\i_main.cpp:1035
#21 0x00420cb6 in WinMain@16 (hInstance=0x400000, nothing=0x0, cmdline=0x725214a "", nCmdShow=10) at C:\DEV\gzdoom\src\win32\i_main.cpp:1348
#22 0x00a380eb in main ()
>>>>>>cb_gdb:Continuing.
@_mental: any idea? Thanks.

Also the new dpJudas' software renderer from the multithreaded rendering PR (Move swrenderer into a namespace, add multithreading framework, and move drawers to commands) is very slow with MinGW and i dunno why, also looks different but that was fixed later.
Top
_mental_
 
 
Posts: 3812
Joined: Sun Aug 07, 2011 4:32 am

Re: Another crash on exit with gcc (MinGW)

Post by _mental_ »

Does it crash using Debug configuration? Was it Release or RelWithDebInfo?

In general, I have very low interest in working with old codebase. I would rather try GZDoom's master branch.
Top
User avatar
drfrag
Vintage GZDoom Developer
Posts: 3141
Joined: Fri Apr 23, 2004 3:51 am
Location: Spain
Contact:
Contact drfrag

Re: Another crash on exit with gcc (MinGW)

Post by drfrag »

Thanks, it's RelWithDebInfo. I've compiled this one since the most recent version might be harder to compile. But the same code is still there and i'm almost sure it will crash as well. I wonder if someone else is compiling with MinGW.
Top
_mental_
 
 
Posts: 3812
Joined: Sun Aug 07, 2011 4:32 am

Re: Another crash on exit with gcc (MinGW)

Post by _mental_ »

Probably I can setup MinGW locally. Could you please tell me some details about its version/bitness and changes from default in CMake configuration?
Top
User avatar
drfrag
Vintage GZDoom Developer
Posts: 3141
Joined: Fri Apr 23, 2004 3:51 am
Location: Spain
Contact:
Contact drfrag

Re: Another crash on exit with gcc (MinGW)

Post by drfrag »

It's tdm-gcc 5.1 32 bit included with CodeBlocks 17.12 but i had to apply Blzut3's patches. I don't even know if the current master compiles with MinGW, you could try with MSYS2 instead. Or may be i could just provide more info, i'm almost sure that the fix would be applicable to master.

Some patches here:
https://github.com/drfrag666/gzdoom/commits/rzdoom
Top
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49067
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: Another crash on exit with gcc (MinGW)

Post by Graf Zahl »

2.4 is not the same as the current version. These problems have been driving me crazy so I ended up moving the class descriptors and all the VM data out of the DObject hierarchy so that it won't get garbage collected. (I'll never understand why it was put in there in the first place because it rendered the entire VM a house of cards - remove the wrong card at the wrong time and all comes down - happened to be a bit more often than just a few times, especially when all the data was taken down)
I think I fixed these after the 2.4 release so your code would still be vulnerable from the garbage collector striking at the wrong point.
Top
User avatar
drfrag
Vintage GZDoom Developer
Posts: 3141
Joined: Fri Apr 23, 2004 3:51 am
Location: Spain
Contact:
Contact drfrag

Re: Another crash on exit with gcc (MinGW)

Post by drfrag »

No sorry, i tracked changes in vmframe.cpp and that was an earlier commit.

I've also run some tests to measure performance of the new 8 bit renderer vs the old one with ASM on an old P4 2.4 @640:
ZDoom 2.8.1 177 fps ZDoom DEC03 157 fps GZDoom 2.4 150 fps MinGW 2.4 92 fps.
It's pretty fast but slow with MinGW, also looks different (colormaps?).
Top
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49067
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: Another crash on exit with gcc (MinGW)

Post by Graf Zahl »

drfrag wrote:No sorry, i tracked changes in vmframe.cpp and that was an earlier commit.

No, it wasn't. The stuff I am talking about was not in vmframe.cpp but all over the VM type code. The relevant changes were made in mid April 2017 after finally realizing that there was no way for making the VM robust as long as all the data it depends on is under the garbage collector's control. This can easily lead to some code being run when all the backing data has already been collected.
Top
User avatar
drfrag
Vintage GZDoom Developer
Posts: 3141
Joined: Fri Apr 23, 2004 3:51 am
Location: Spain
Contact:
Contact drfrag

Re: Another crash on exit with gcc (MinGW)

Post by drfrag »

I checked vm.h as well. To me it looks like you're talking about this commit:

02/08/17 - took VMFunction out of the DObject hierarchy.

As it stood, just compiling the internal ZScript code created more than 9000 DObjects, none of which really need to be subjected to garbage collection, aside from allowing lazy deallocation.
This puts an incredible drag on the garbage collector which often needs several minutes to finish processing before actual deletion can start.

The VM functions with roughly 1800 of these objects were by far the easiest to refactor so they are now. They also use a memory arena now which significantly reduces their memory footprint.

Or is this one instead?

04/13/17 - moved the VM types into their own file and only include it where really needed.
Top
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49067
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: Another crash on exit with gcc (MinGW)

Post by Graf Zahl »

No. This was only the first step of getting rid of the GC problems. I got rid of the last parts of this stuff - and actually the most problematic (PClass and PType being derived from DObject) in mid April. This dependency meant that it couldn't be guaranteed that during engine deinitialization no object's code could be run whose class descriptor was already gone. I'M not sure if this is related to your problems but that particular relation was a cause of many, many headaches. When refactoring that I also changed allocation to use a memory arena so that all allocated memory in the type system could be freed all at once when it was guaranteed that it wouldn't be needed anymore.
Top
User avatar
drfrag
Vintage GZDoom Developer
Posts: 3141
Joined: Fri Apr 23, 2004 3:51 am
Location: Spain
Contact:
Contact drfrag

Re: Another crash on exit with gcc (MinGW)

Post by drfrag »

Thanks, it should be fixed then. I still don't know if the current master actually compiles with MinGW, i'm afraid not but i thought linux could be affected as well.
Top
User avatar
drfrag
Vintage GZDoom Developer
Posts: 3141
Joined: Fri Apr 23, 2004 3:51 am
Location: Spain
Contact:
Contact drfrag

Re: Another crash on exit with gcc (MinGW)

Post by drfrag »

I've fixed compilation with mingw32 (tdm-gcc 5.1) for GZDoom 3.3.2 and the crash on exit is still there, it's mostly the same.
Line 380 in vmframe.cpp is if (Func->SpecialInits.Size())

Code: Select all

Program received signal SIGSEGV, Segmentation fault.
0x00f89778 in TArray<std::pair<PType const*, unsigned int>, std::pair<PType const*, unsigned int> >::Size (this=0x14760054) at C:/DEV/vsqzdoom/src/tarray.h:426
C:\DEV\vsqzdoom\src\tarray.h:426:10548:beg:0xf89778
>>>>>>cb_gdb:No locals.
>>>>>>cb_gdb:this = 0x14760054
>>>>>>cb_gdb:#0  0x00f89778 in TArray<std::pair<PType const*, unsigned int>, std::pair<PType const*, unsigned int> >::Size (this=0x14760054) at C:/DEV/vsqzdoom/src/tarray.h:426
#1  0x00918997 in VMFrameStack::PopFrame (this=0x7ffdf000) at C:\DEV\vsqzdoom\src\scripting\vm\vmframe.cpp:380
#2  0x009186ad in VMFrameStack::~VMFrameStack (this=0x7ffdf000, __in_chrg=<optimized out>) at C:\DEV\vsqzdoom\src\scripting\vm\vmframe.cpp:246
#3  0x00a806e8 in (anonymous namespace)::run(void*) ()
#4  0x77eea54a in ntdll!ZwQueryInformationProcess () from C:\Windows\SYSTEM32\ntdll.dll
#5  0x0b330330 in ?? ()
#6  0x760840e1 in msvcrt!exit () from C:\Windows\system32\msvcrt.dll
#7  0x0042c921 in ST_Endoom () at C:\DEV\vsqzdoom\src\win32\st_start.cpp:1096
#8  0x0085e186 in <lambda()>::operator()(void) const (__closure=0x0) at C:\DEV\vsqzdoom\src\menu\messagebox.cpp:119
#9  0x0085e19c in <lambda()>::_FUN(void) () at C:\DEV\vsqzdoom\src\menu\messagebox.cpp:120
#10 0x0085ddde in AF_DMessageBoxMenu_CallHandler (param=0xbb238d0, defaultparam=..., numparam=1, ret=0x23ea48, numret=0) at C:\DEV\vsqzdoom\src\menu\messagebox.cpp:57
#11 0x00c331ab in VMExec_Checked::Exec (stack=0xb3303c4, pc=0xaa1eb90, ret=0x23ef38, numret=0) at C:/DEV/vsqzdoom/src/scripting/vm/vmexec.h:702
#12 0x00c33269 in VMExec_Checked::Exec (stack=0xb3303c4, pc=0xaa1ed44, ret=0x23f4ec, numret=1) at C:/DEV/vsqzdoom/src/scripting/vm/vmexec.h:721
#13 0x00918c76 in VMCall (func=0xb75ef88, params=0x23f4a8, numparams=2, results=0x23f4ec, numresults=1) at C:\DEV\vsqzdoom\src\scripting\vm\vmframe.cpp:463
#14 0x0085287c in DMenu::CallResponder (this=0xbef18c0, ev=0x12c3d30 <events+48>) at C:\DEV\vsqzdoom\src\menu\menu.cpp:187
#15 0x008541ad in M_Responder (ev=0x12c3d30 <events+48>) at C:\DEV\vsqzdoom\src\menu\menu.cpp:604
#16 0x005e7edf in D_ProcessEvents () at C:\DEV\vsqzdoom\src\d_main.cpp:304
#17 0x005f2019 in NetUpdate () at C:\DEV\vsqzdoom\src\d_net.cpp:987
#18 0x005f3d25 in TryRunTics () at C:\DEV\vsqzdoom\src\d_net.cpp:1842
#19 0x005e9965 in D_DoomLoop () at C:\DEV\vsqzdoom\src\d_main.cpp:1066
#20 0x005ee362 in D_DoomMain () at C:\DEV\vsqzdoom\src\d_main.cpp:2757
#21 0x00425e73 in DoMain (hInstance=0x400000) at C:\DEV\vsqzdoom\src\win32\i_main.cpp:1042
#22 0x004265d1 in WinMain@16 (hInstance=0x400000, nothing=0x0, cmdline=0x30245d "", nCmdShow=10) at C:\DEV\vsqzdoom\src\win32\i_main.cpp:1357
#23 0x010471db in main ()
>>>>>>cb_gdb:#1  0x00918997 in VMFrameStack::PopFrame (this=0x7ffdf000) at C:\DEV\vsqzdoom\src\scripting\vm\vmframe.cpp:380
C:\DEV\vsqzdoom\src\scripting\vm\vmframe.cpp:380:9227:beg:0x918997
>>>>>>cb_gdb:frame = 0x76097220 <msvcrt!_local_unwind4+464>
Func = 0x1475ffec
regs = 0xc4103d50
parent = 0xaa2373 <_Unwind_SjLj_Register+83>
>>>>>>cb_gdb:this = 0x7ffdf000
>>>>>>cb_gdb:#0  0x00f89778 in TArray<std::pair<PType const*, unsigned int>, std::pair<PType const*, unsigned int> >::Size (this=0x14760054) at C:/DEV/vsqzdoom/src/tarray.h:426
#1  0x00918997 in VMFrameStack::PopFrame (this=0x7ffdf000) at C:\DEV\vsqzdoom\src\scripting\vm\vmframe.cpp:380
#2  0x009186ad in VMFrameStack::~VMFrameStack (this=0x7ffdf000, __in_chrg=<optimized out>) at C:\DEV\vsqzdoom\src\scripting\vm\vmframe.cpp:246
#3  0x00a806e8 in (anonymous namespace)::run(void*) ()
#4  0x77eea54a in ntdll!ZwQueryInformationProcess () from C:\Windows\SYSTEM32\ntdll.dll
#5  0x0b330330 in ?? ()
#6  0x760840e1 in msvcrt!exit () from C:\Windows\system32\msvcrt.dll
#7  0x0042c921 in ST_Endoom () at C:\DEV\vsqzdoom\src\win32\st_start.cpp:1096
#8  0x0085e186 in <lambda()>::operator()(void) const (__closure=0x0) at C:\DEV\vsqzdoom\src\menu\messagebox.cpp:119
#9  0x0085e19c in <lambda()>::_FUN(void) () at C:\DEV\vsqzdoom\src\menu\messagebox.cpp:120
#10 0x0085ddde in AF_DMessageBoxMenu_CallHandler (param=0xbb238d0, defaultparam=..., numparam=1, ret=0x23ea48, numret=0) at C:\DEV\vsqzdoom\src\menu\messagebox.cpp:57
#11 0x00c331ab in VMExec_Checked::Exec (stack=0xb3303c4, pc=0xaa1eb90, ret=0x23ef38, numret=0) at C:/DEV/vsqzdoom/src/scripting/vm/vmexec.h:702
#12 0x00c33269 in VMExec_Checked::Exec (stack=0xb3303c4, pc=0xaa1ed44, ret=0x23f4ec, numret=1) at C:/DEV/vsqzdoom/src/scripting/vm/vmexec.h:721
#13 0x00918c76 in VMCall (func=0xb75ef88, params=0x23f4a8, numparams=2, results=0x23f4ec, numresults=1) at C:\DEV\vsqzdoom\src\scripting\vm\vmframe.cpp:463
#14 0x0085287c in DMenu::CallResponder (this=0xbef18c0, ev=0x12c3d30 <events+48>) at C:\DEV\vsqzdoom\src\menu\menu.cpp:187
#15 0x008541ad in M_Responder (ev=0x12c3d30 <events+48>) at C:\DEV\vsqzdoom\src\menu\menu.cpp:604
#16 0x005e7edf in D_ProcessEvents () at C:\DEV\vsqzdoom\src\d_main.cpp:304
#17 0x005f2019 in NetUpdate () at C:\DEV\vsqzdoom\src\d_net.cpp:987
#18 0x005f3d25 in TryRunTics () at C:\DEV\vsqzdoom\src\d_net.cpp:1842
#19 0x005e9965 in D_DoomLoop () at C:\DEV\vsqzdoom\src\d_main.cpp:1066
#20 0x005ee362 in D_DoomMain () at C:\DEV\vsqzdoom\src\d_main.cpp:2757
#21 0x00425e73 in DoMain (hInstance=0x400000) at C:\DEV\vsqzdoom\src\win32\i_main.cpp:1042
#22 0x004265d1 in WinMain@16 (hInstance=0x400000, nothing=0x0, cmdline=0x30245d "", nCmdShow=10) at C:\DEV\vsqzdoom\src\win32\i_main.cpp:1357
#23 0x010471db in main ()
Edit: when i try to watch Func->SpecialInits i get cannot read address at 0x14760054
Top
User avatar
drfrag
Vintage GZDoom Developer
Posts: 3141
Joined: Fri Apr 23, 2004 3:51 am
Location: Spain
Contact:
Contact drfrag

Re: Another crash on exit with gcc (MinGW)

Post by drfrag »

I've been debugging this for hours without luck, i'm afraid i'm not skilled enough or in other words i'm even dumber than i thought. :(

It crashes in 'VMFrame *VMFrameStack::PopFrame()' on line 'if (Func->SpecialInits.Size())' in vmframe.cpp:380. For Func->SpecialInits i get 'Cannot access memory at address xxx' but Func != NULL. For frame i get 'msvcrt!_local_unwind_', does that mean that the object has been destroyed?
The VMFrameStack destructor first calls PopFrame() so the object should still exist.
I've tried to do several changes but still crashed. Any ideas? :wub:

https://github.com/drfrag666/gzdoom/blo ... e.cpp#L380

Full stack trace:
Spoiler:
Top
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49067
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: Another crash on exit with gcc (MinGW)

Post by Graf Zahl »

This indeed sounds like some stuff is taken down out of order. Since it involves VMFrameStack which is a thread_local variable, maybe you should try removing that attribute. I wouldn't be surprised if that crusty old msvcrt.dll cannot deal with it.
Top
User avatar
drfrag
Vintage GZDoom Developer
Posts: 3141
Joined: Fri Apr 23, 2004 3:51 am
Location: Spain
Contact:
Contact drfrag

Re: Another crash on exit with gcc (MinGW)

Post by drfrag »

Thanks. I've removed thread_local but still crashes. But it already didn't crash exiting from the console.
Now exiting with F10 i get a different stack and crashes at 'for (auto tao : SpecialInits)' in vmframe.cpp:181 instead with more info.
Coming from 'Func->DestroyExtra(frame->GetExtra())' in vmframe.cpp:382
I've noticed that 'void PType::DestroyValue(void *addr) const' is empty but it's overriden in PactorInfo, is that okay?

https://github.com/drfrag666/gzdoom/blo ... e.cpp#L181

Code: Select all

#0  0x009128b3 in VMScriptFunction::DestroyExtra (this=0xb6649b4, addr=0xba29370) at C:\DEV\vsqzdoom\src\scripting\vm\vmframe.cpp:181
#1  0x00912dbd in VMFrameStack::PopFrame (this=0x1576f48 <GlobalVMStack>) at C:\DEV\vsqzdoom\src\scripting\vm\vmframe.cpp:382
#2  0x00912ab1 in VMFrameStack::~VMFrameStack (this=0x1576f48 <GlobalVMStack>, __in_chrg=<optimized out>) at C:\DEV\vsqzdoom\src\scripting\vm\vmframe.cpp:246
#3  0x009122e7 in __tcf_0 () at C:\DEV\vsqzdoom\src\scripting\vm\vmexec.cpp:152
#4  0x76083b53 in msvcrt!_flushall () from C:\Windows\system32\msvcrt.dll
#5  0x8776e571 in ?? ()
#6  0x00000000 in ?? ()
>>>>>>cb_gdb:#0  0x009128b3 in VMScriptFunction::DestroyExtra (this=0xb6649b4, addr=0xba29370) at C:\DEV\vsqzdoom\src\scripting\vm\vmframe.cpp:181
C:\DEV\vsqzdoom\src\scripting\vm\vmframe.cpp:181:4533:beg:0x9128b3
>>>>>>cb_gdb:tao = {first = 0x0, second = 0}
__for_range = @0xb664a1c: {Array = 0xfeeefeee, Count = 4277075694, Most = 4277075694}
__for_begin = {<std::iterator<std::random_access_iterator_tag, std::pair<PType const*, unsigned int>, int, std::pair<PType const*, unsigned int>*, std::pair<PType const*, unsigned int>&>> = {<No data fields>}, m_ptr = 0xfeeefeee}
__for_end = {<std::iterator<std::random_access_iterator_tag, std::pair<PType const*, unsigned int>, int, std::pair<PType const*, unsigned int>*, std::pair<PType const*, unsigned int>&>> = {<No data fields>}, m_ptr = 0xf666f65e}
caddr = 0xba29370 ""
>>>>>>cb_gdb:this = 0xb6649b4
addr = 0xba29370
>>>>>>cb_gdb:No symbol "Func" in current context.
>>>>>>cb_gdb:No symbol "Blocks" in current context.
>>>>>>cb_gdb:#0  0x009128b3 in VMScriptFunction::DestroyExtra (this=0xb6649b4, addr=0xba29370) at C:\DEV\vsqzdoom\src\scripting\vm\vmframe.cpp:181
#1  0x00912dbd in VMFrameStack::PopFrame (this=0x1576f48 <GlobalVMStack>) at C:\DEV\vsqzdoom\src\scripting\vm\vmframe.cpp:382
#2  0x00912ab1 in VMFrameStack::~VMFrameStack (this=0x1576f48 <GlobalVMStack>, __in_chrg=<optimized out>) at C:\DEV\vsqzdoom\src\scripting\vm\vmframe.cpp:246
#3  0x009122e7 in __tcf_0 () at C:\DEV\vsqzdoom\src\scripting\vm\vmexec.cpp:152
#4  0x76083b53 in msvcrt!_flushall () from C:\Windows\system32\msvcrt.dll
#5  0x8776e571 in ?? ()
#6  0x00000000 in ?? ()
>>>>>>cb_gdb:#1  0x00912dbd in VMFrameStack::PopFrame (this=0x1576f48 <GlobalVMStack>) at C:\DEV\vsqzdoom\src\scripting\vm\vmframe.cpp:382
C:\DEV\vsqzdoom\src\scripting\vm\vmframe.cpp:382:9264:beg:0x912dbd
>>>>>>cb_gdb:frame = 0xba29320
Func = 0xb6649b4
regs = 0xd4a69b <TArray<FFunctionBuildList::Item, FFunctionBuildList::Item>::~TArray()+147>
parent = 0xa9c9f3 <_Unwind_SjLj_Register+83>
>>>>>>cb_gdb:this = 0x1576f48 <GlobalVMStack>
>>>>>>cb_gdb:type = TArray<std::pair<PType const*, unsigned int>, std::pair<PType const*, unsigned int> >
>>>>>>cb_gdb:{Array = 0xfeeefeee, Count = 4277075694, Most = 4277075694}>>>>>>cb_gdb:type = VMFrame *
>>>>>>cb_gdb:(VMFrame *) 0xba29320>>>>>>cb_gdb:#0  0x009128b3 in VMScriptFunction::DestroyExtra (this=0xb6649b4, addr=0xba29370) at C:\DEV\vsqzdoom\src\scripting\vm\vmframe.cpp:181
#1  0x00912dbd in VMFrameStack::PopFrame (this=0x1576f48 <GlobalVMStack>) at C:\DEV\vsqzdoom\src\scripting\vm\vmframe.cpp:382
#2  0x00912ab1 in VMFrameStack::~VMFrameStack (this=0x1576f48 <GlobalVMStack>, __in_chrg=<optimized out>) at C:\DEV\vsqzdoom\src\scripting\vm\vmframe.cpp:246
#3  0x009122e7 in __tcf_0 () at C:\DEV\vsqzdoom\src\scripting\vm\vmexec.cpp:152
#4  0x76083b53 in msvcrt!_flushall () from C:\Windows\system32\msvcrt.dll
#5  0x8776e571 in ?? ()
#6  0x00000000 in ?? ()
>>>>>>cb_gdb:#2  0x00912ab1 in VMFrameStack::~VMFrameStack (this=0x1576f48 <GlobalVMStack>, __in_chrg=<optimized out>) at C:\DEV\vsqzdoom\src\scripting\vm\vmframe.cpp:246
C:\DEV\vsqzdoom\src\scripting\vm\vmframe.cpp:246:6092:beg:0x912ab1
>>>>>>cb_gdb:No locals.
>>>>>>cb_gdb:this = 0x1576f48 <GlobalVMStack>
__in_chrg = <optimized out>
>>>>>>cb_gdb:No symbol "Func" in current context.
>>>>>>cb_gdb:type = VMFrame *
>>>>>>cb_gdb:(VMFrame *) 0xba29320>>>>>>cb_gdb:#0  0x009128b3 in VMScriptFunction::DestroyExtra (this=0xb6649b4, addr=0xba29370) at C:\DEV\vsqzdoom\src\scripting\vm\vmframe.cpp:181
#1  0x00912dbd in VMFrameStack::PopFrame (this=0x1576f48 <GlobalVMStack>) at C:\DEV\vsqzdoom\src\scripting\vm\vmframe.cpp:382
#2  0x00912ab1 in VMFrameStack::~VMFrameStack (this=0x1576f48 <GlobalVMStack>, __in_chrg=<optimized out>) at C:\DEV\vsqzdoom\src\scripting\vm\vmframe.cpp:246
#3  0x009122e7 in __tcf_0 () at C:\DEV\vsqzdoom\src\scripting\vm\vmexec.cpp:152
#4  0x76083b53 in msvcrt!_flushall () from C:\Windows\system32\msvcrt.dll
#5  0x8776e571 in ?? ()
#6  0x00000000 in ?? ()
>>>>>>cb_gdb:
Top
Post Reply

Return to “General”