Latest GZDoom builds crash when loading with placed Dynamic Lights

Bugs that have been resolved.

Moderator: Graf Zahl

Locked
User avatar
SanyaWaffles
Ice Sanya Charges Extra
Posts: 4
Joined: Sat Sep 24, 2016 10:09
Location: An Icebox in Eastern Ohio
Contact:

Latest GZDoom builds crash when loading with placed Dynamic Lights

Post by SanyaWaffles » Sat Sep 24, 2016 10:47

While I know the development builds have not been compiled for 32 or 64 bit windows, I noticed compiling the latest GZDoom codebase crashes upon loading maps with Dynamic Lights placed on the level itself (rather than attached to specific objects in the map, like armor bonuses and candelabras, etc).

I thought at first this was just my 'fork' of sorts. Except I decided just to compile the GZDoom straight up and load my total conversion from there - none of my minor changes (icon-wise) - just straight from Graf's git repo and the master branch.

There is a minor typo in 561edd3 @ line 639 in src/gl/scene/gl_sprite.cpp

Code: Select all

if (thing == nullptr || thing->sprite == 0 || !thing->IsVisibleToPlayer() || !thing->IsInsideVisibleAngle())
should be

Code: Select all

if (thing == nullptr || thing->sprite == 0 || !thing->IsVisibleToPlayer() || !thing->IsInsideVisibleAngles())
after that correction it compiles fine. It will also load and save even with lights.pk3 loaded just fine, but when a map with Dynamic Light objects (like Classes:PointLight) is 'saved' and then loaded in GZDoom, it crashes.

I decided to remove all doubt and just load Doom II straight up with a very minimalist map, with three dynamic lights placed on the map. Dragged it onto gzdoom.exe, loaded Doom2.wad, started a new game.

It loads the map fine, but if you save a savefile and load that savefile, it will crash - first crash seems to be at the line:

Code: Select all

assert(val->IsArray());
at line 505 of serializer.cpp when it reads some of the properties (radius/m_Radius being one of them I saw).

Here is some values copied and pasted from the 'auto' tab

Code: Select all

+		name	0x01238e78 "radius"	const char *
+		r	0x04ad3730 {mObjects={Array=0x0d80ade8 {mObject=0x04ad3740 {data_={s={length=35 hashcode=35 str=0x0d8a74c0 "checksum" } ...} } ...} ...} ...}	FReader *
+		this	0x01efede0 {w=0x00000000 <NULL> r=0x04ad3730 {mObjects={Array=0x0d80ade8 {mObject=0x04ad3740 {data_=...} ...} ...} ...} ...}	FSerializer *
+		val	0x0d8a70f0 {data_={s={length=0 hashcode=1080033280 str=0x00000000 <NULL> } ss={str=0x0d8a70f0 "" } n=...} }	rapidjson::GenericValue<rapidjson::UTF8<char>,rapidjson::MemoryPoolAllocator<rapidjson::CrtAllocator> > *
and the Locals tab:

Code: Select all

+		this	0x01efede0 {w=0x00000000 <NULL> r=0x04ad3730 {mObjects={Array=0x0d80ade8 {mObject=0x04ad3740 {data_=...} ...} ...} ...} ...}	FSerializer *
+		name	0x01238e78 "radius"	const char *
+		val	0x0d8a70f0 {data_={s={length=0 hashcode=1080033280 str=0x00000000 <NULL> } ss={str=0x0d8a70f0 "" } n=...} }	rapidjson::GenericValue<rapidjson::UTF8<char>,rapidjson::MemoryPoolAllocator<rapidjson::CrtAllocator> > *
and the Call Stack:

Code: Select all

 	gzdoom.exe!common_assert_to_message_box<wchar_t>(const wchar_t * const expression, const wchar_t * const file_name, const unsigned int line_number, void * const return_address) Line 351	C++
 	gzdoom.exe!common_assert<wchar_t>(const wchar_t * const expression, const wchar_t * const file_name, const unsigned int line_number, void * const return_address) Line 386	C++
 	gzdoom.exe!_wassert(const wchar_t * expression, const wchar_t * file_name, unsigned int line_number) Line 404	C++
>	gzdoom.exe!FSerializer::BeginArray(const char * name) Line 505	C++
 	gzdoom.exe!FSerializer::Array<int>(const char * key, int * obj, int * def, int count, bool fullcompare) Line 147	C++
 	gzdoom.exe!ADynamicLight::Serialize(FSerializer & arc) Line 168	C++
 	gzdoom.exe!FSerializer::ReadObjects(bool hubtravel) Line 893	C++
 	gzdoom.exe!G_SerializeLevel(FSerializer & arc, bool hubload) Line 900	C++
 	gzdoom.exe!G_UnSnapshotLevel(bool hubLoad) Line 1520	C++
 	gzdoom.exe!G_DoLoadLevel(int position, bool autosave) Line 1013	C++
 	gzdoom.exe!G_InitNew(const char * mapname, bool bTitleLevel) Line 509	C++
 	gzdoom.exe!G_DoLoadGame() Line 1976	C++
 	gzdoom.exe!G_Ticker() Line 1077	C++
 	gzdoom.exe!TryRunTics() Line 1946	C++
 	gzdoom.exe!D_DoomLoop() Line 1014	C++
 	gzdoom.exe!D_DoomMain() Line 2651	C++
 	gzdoom.exe!DoMain(HINSTANCE__ * hInstance) Line 1003	C++
 	gzdoom.exe!WinMain(HINSTANCE__ * hInstance, HINSTANCE__ * nothing, char * cmdline, int nCmdShow) Line 1300	C++
I am using Visual Studio 2015 with all the latest updates on Windows 10. I am targeting 32-bit Windows and using CMake.

I used the full debug build, but it also crashes in all Release modes as well - provides no crash dumps or anything. If I keep continuing/ignoring the errors in debug mode it indicates a possible memory overrun.

Here is the map I tested:

https://dl.dropboxusercontent.com/u/758 ... estmap.zip

and the save file:

https://dl.dropboxusercontent.com/u/758 ... /save0.zds

and here's the debug build (I have no idea if it will be of any use but just thought I'd be thorough)

https://dl.dropboxusercontent.com/u/758 ... And_ZDS.7z

User avatar
Graf Zahl
GZDoom Developer
GZDoom Developer
Posts: 7148
Joined: Wed Jul 20, 2005 9:48
Location: Germany
Contact:

Re: Latest GZDoom builds crash when loading with placed Dynamic Lights

Post by Graf Zahl » Sat Sep 24, 2016 11:12

fixed. BTW. an assert is not a crash, just a debug notification that something was done wrong. I think in a release build this would at worst not have restored that property.

User avatar
SanyaWaffles
Ice Sanya Charges Extra
Posts: 4
Joined: Sat Sep 24, 2016 10:09
Location: An Icebox in Eastern Ohio
Contact:

Re: Latest GZDoom builds crash when loading with placed Dynamic Lights

Post by SanyaWaffles » Sat Sep 24, 2016 21:21

I confirm the fixes related to this have been fixed.
Graf Zahl wrote:fixed. BTW. an assert is not a crash, just a debug notification that something was done wrong.
I figured that was the case before I checked this thread this afternoon. It was a late night. I realized assert's just for debugging purposes. My bad.

Just to clarify - the crash still occured in Release/RelMinSize as well - just no assert dialog box or debugging info. It didn't even display the typical 'a crash has occured' dialog box ZDoom/GZDoom sometimes has.
Graf Zahl wrote:I think in a release build this would at worst not have restored that property.
Actually it crashed upon loading the savefile entirely, but that probably has to do with not restoring those properties.

But it's moot at this point, this specific issue has been fixed - I confirmed by rebuilding GZDoom by fetching the latest fix and fixing another typo fixed in zdoom but not gzdoom.

Thanks for the quick response/fix.
Spoiler: a slight gush

Locked

Return to “Closed Bugs”