[r1249] Release compile of zdoom doesn't run

Forum rules
Please don't bump threads here if you have a problem - it will often be forgotten about if you do. Instead, make a new thread here.

Post a reply

Smilies
:D :) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :geek: :ugeek: :!: :?: :idea: :arrow: :| :mrgreen: :3: :wub: >:( :blergh:
View more smilies
BBCode is OFF
Smilies are ON
Topic review
   

Expand view Topic review: [r1249] Release compile of zdoom doesn't run

Re: [r1249] Release compile of zdoom doesn't run

by sniperchance » Mon Oct 06, 2008 2:23 am

Even better, I was actually on Mac OS X.

Re: [r1249] Release compile of zdoom doesn't run

by Graf Zahl » Mon Oct 06, 2008 1:41 am

Ok, then the gibbing problem has nothing to do with my state code changes. My dump is exactly the same, too.

Closing this thread.

Re: [r1249] Release compile of zdoom doesn't run

by Chris » Mon Oct 06, 2008 1:11 am

I'm on Linux, and the log is the same as mine (diff shows no differences besides the start time of the log itself). So either he's on Linux/Unix, or there's no difference with Windows.

Re: [r1249] Release compile of zdoom doesn't run

by Graf Zahl » Mon Oct 06, 2008 12:59 am

Was that on Windows or Linux?

Re: [r1249] Release compile of zdoom doesn't run

by sniperchance » Sun Oct 05, 2008 6:10 pm

Alright, I tried out the dumpstates command, and here's what I got.
zdoom-states.txt
(230.22 KiB) Downloaded 43 times

Re: [r1249] Release compile of zdoom doesn't run

by Graf Zahl » Sun Oct 05, 2008 2:40 pm

Ok. I'll add a state dump command to ZDoom. As soon as the next revision is up please run it, enable the log and type 'dumpstates'. Hopefully that will yield some information.

Re: [r1249] Release compile of zdoom doesn't run

by Chris » Sun Oct 05, 2008 1:14 pm

Those valgrind warnings are gone. :) Just this one remaining that ZDoom seems to be responsible for

Code: Select all

==17488== Use of uninitialised value of size 4
==17488==    at 0x826DC9E: R_InitSpriteDefs() (r_things.cpp:371)
==17488==    by 0x826DF8D: R_InitSprites() (r_things.cpp:889)
==17488==    by 0x82159B7: P_Init() (p_setup.cpp:3605)
==17488==    by 0x815D1AB: D_DoomMain() (d_main.cpp:2587)
==17488==    by 0x812C992: main (i_main.cpp:272)
Gibbing still doesn't work, though (I was about to post in that topic that it affects 32-bit Gentoo, too, before I started with Valgrind here).

Re: [r1249] Release compile of zdoom doesn't run

by Graf Zahl » Sun Oct 05, 2008 12:44 pm

Can you retry with the latest SVN revision?

Re: [r1249] Release compile of zdoom doesn't run

by Graf Zahl » Sun Oct 05, 2008 12:26 pm

Looks a bit random... :?

Re: [r1249] Release compile of zdoom doesn't run

by Chris » Sun Oct 05, 2008 11:57 am

They're printed when they occur, yes. The following ones seem to produce errors (still including the function change from earlier)..

Code: Select all

Finishing states for Inventory
==10731==
==10731== Thread 1:
==10731== Conditional jump or move depends on uninitialised value(s)
==10731==    at 0x8229C98: FStateDefinitions::FixStatePointers(FActorInfo*, TArray<FStateDefine, FStateDefine>&) (p_states.cpp:724)
==10731==    by 0x822AEDB: FStateDefinitions::FinishStates(FActorInfo*, AActor*, TArray<FState, FState>&) (p_states.cpp:781)
==10731==    by 0x839CED7: FinishActor(FScanner&, FActorInfo*, Baggage&) (thingdef_parse.cpp:532)
==10731==    by 0x8391305: ParseActor(FScanner&) (thingdef.cpp:579)
==10731==    by 0x839CD99: ParseDecorate(FScanner&) (thingdef_main.cpp:117)
==10731==    by 0x839CC7E: ParseDecorate(FScanner&) (thingdef_main.cpp:80)
==10731==    by 0x839CE1C: LoadDecorations() (thingdef_main.cpp:148)
==10731==    by 0x8192255: FActorInfo::StaticInit() (info.cpp:107)
==10731==    by 0x815CD19: D_DoomMain() (d_main.cpp:2503)
==10731==    by 0x812C8F2: main (i_main.cpp:272)
==10731==
==10731== Conditional jump or move depends on uninitialised value(s)
==10731==    at 0x822AD40: FStateDefinitions::ResolveGotoLabels(FActorInfo*, AActor*, TArray<FStateDefine, FStateDefine>&) (p_states.cpp:746)
==10731==    by 0x822B061: FStateDefinitions::FinishStates(FActorInfo*, AActor*, TArray<FState, FState>&) (p_states.cpp:812)
==10731==    by 0x839CED7: FinishActor(FScanner&, FActorInfo*, Baggage&) (thingdef_parse.cpp:532)
==10731==    by 0x8391305: ParseActor(FScanner&) (thingdef.cpp:579)
==10731==    by 0x839CD99: ParseDecorate(FScanner&) (thingdef_main.cpp:117)
==10731==    by 0x839CC7E: ParseDecorate(FScanner&) (thingdef_main.cpp:80)
==10731==    by 0x839CE1C: LoadDecorations() (thingdef_main.cpp:148)
==10731==    by 0x8192255: FActorInfo::StaticInit() (info.cpp:107)
==10731==    by 0x815CD19: D_DoomMain() (d_main.cpp:2503)
==10731==    by 0x812C8F2: main (i_main.cpp:272)
...
Finishing states for StealthChaingunGuy
==10731==
==10731== Conditional jump or move depends on uninitialised value(s)
==10731==    at 0x822AD40: FStateDefinitions::ResolveGotoLabels(FActorInfo*, AActor*, TArray<FStateDefine, FStateDefine>&) (p_states.cpp:746)
==10731==    by 0x822AE0E: FStateDefinitions::ResolveGotoLabels(FActorInfo*, AActor*, TArray<FStateDefine, FStateDefine>&) (p_states.cpp:751)
==10731==    by 0x822B061: FStateDefinitions::FinishStates(FActorInfo*, AActor*, TArray<FState, FState>&) (p_states.cpp:812)
==10731==    by 0x839CED7: FinishActor(FScanner&, FActorInfo*, Baggage&) (thingdef_parse.cpp:532)
==10731==    by 0x8391305: ParseActor(FScanner&) (thingdef.cpp:579)
==10731==    by 0x839CD99: ParseDecorate(FScanner&) (thingdef_main.cpp:117)
==10731==    by 0x839CC7E: ParseDecorate(FScanner&) (thingdef_main.cpp:80)
==10731==    by 0x839CE1C: LoadDecorations() (thingdef_main.cpp:148)
==10731==    by 0x8192255: FActorInfo::StaticInit() (info.cpp:107)
==10731==    by 0x815CD19: D_DoomMain() (d_main.cpp:2503)
==10731==    by 0x812C8F2: main (i_main.cpp:272)
...
Finishing states for HereticImpLeader
==10731==
==10731== Conditional jump or move depends on uninitialised value(s)
==10731==    at 0x8229C98: FStateDefinitions::FixStatePointers(FActorInfo*, TArray<FStateDefine, FStateDefine>&) (p_states.cpp:724)
==10731==    by 0x8229D41: FStateDefinitions::FixStatePointers(FActorInfo*, TArray<FStateDefine, FStateDefine>&) (p_states.cpp:730)
==10731==    by 0x822AEDB: FStateDefinitions::FinishStates(FActorInfo*, AActor*, TArray<FState, FState>&) (p_states.cpp:781)
==10731==    by 0x839CED7: FinishActor(FScanner&, FActorInfo*, Baggage&) (thingdef_parse.cpp:532)
==10731==    by 0x8391305: ParseActor(FScanner&) (thingdef.cpp:579)
==10731==    by 0x839CD99: ParseDecorate(FScanner&) (thingdef_main.cpp:117)
==10731==    by 0x839CC7E: ParseDecorate(FScanner&) (thingdef_main.cpp:80)
==10731==    by 0x839CE1C: LoadDecorations() (thingdef_main.cpp:148)
==10731==    by 0x8192255: FActorInfo::StaticInit() (info.cpp:107)
==10731==    by 0x815CD19: D_DoomMain() (d_main.cpp:2503)
==10731==    by 0x812C8F2: main (i_main.cpp:272)
...
Finishing states for ChexMineCart
==10731==
==10731== Conditional jump or move depends on uninitialised value(s)
==10731==    at 0x40236E3: strcpy (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==10731==    by 0x8192305: GetSpriteIndex(char const*) (info.cpp:77)
==10731==    by 0x839FC9D: Handler_crouchsprite_S_PlayerPawn(APlayerPawn*, Baggage&, FPropParam*) (thingdef_properties.cpp:1978)
==10731==    by 0x839D712: ParsePropertyParams(FScanner&, FPropertyInfo*, AActor*, Baggage&) (thingdef_parse.cpp:452)
==10731==    by 0x839DA32: ParseActorProperty(FScanner&, Baggage&) (thingdef_parse.cpp:496)
==10731==    by 0x839127E: ParseActor(FScanner&) (thingdef.cpp:566)
==10731==    by 0x839CD99: ParseDecorate(FScanner&) (thingdef_main.cpp:117)
==10731==    by 0x839CC7E: ParseDecorate(FScanner&) (thingdef_main.cpp:80)
==10731==    by 0x839CE1C: LoadDecorations() (thingdef_main.cpp:148)
==10731==    by 0x8192255: FActorInfo::StaticInit() (info.cpp:107)
==10731==    by 0x815CD19: D_DoomMain() (d_main.cpp:2503)
==10731==    by 0x812C8F2: main (i_main.cpp:272)
All the others finish without triggering a valgrind error.

Re: [r1249] Release compile of zdoom doesn't run

by Graf Zahl » Sun Oct 05, 2008 11:31 am

Are these messages printed when the uninitialized data is accessed or are they collected? If they are immediately printed, please add the following line at the beginning of FStateDefinitions::FinishStates. Hopefully that brings me closer to the real problem.

Code: Select all

	Printf("Finishing states for %s\n", actor->Class->TypeName.GetChars());

Re: [r1249] Release compile of zdoom doesn't run

by Chris » Sun Oct 05, 2008 11:08 am

With that change to the function, I get a couple more valgrind errors:

Code: Select all

==9418== Conditional jump or move depends on uninitialised value(s)
==9418==    at 0x8229C98: FStateDefinitions::FixStatePointers(FActorInfo*, TArray<FStateDefine, FStateDefine>&) (p_states.cpp:724)
==9418==    by 0x822ACC6: FStateDefinitions::FinishStates(FActorInfo*, AActor*, TArray<FState, FState>&) (p_states.cpp:780)
==9418==    by 0x839CEB7: FinishActor(FScanner&, FActorInfo*, Baggage&) (thingdef_parse.cpp:532)
==9418==    by 0x83912E5: ParseActor(FScanner&) (thingdef.cpp:579)
==9418==    by 0x839CD79: ParseDecorate(FScanner&) (thingdef_main.cpp:117)
==9418==    by 0x839CC5E: ParseDecorate(FScanner&) (thingdef_main.cpp:80)
==9418==    by 0x839CDFC: LoadDecorations() (thingdef_main.cpp:148)
==9418==    by 0x8192255: FActorInfo::StaticInit() (info.cpp:107)
==9418==    by 0x815CD19: D_DoomMain() (d_main.cpp:2503)
==9418==    by 0x812C8F2: main (i_main.cpp:272)
..and..
==9418== Conditional jump or move depends on uninitialised value(s)
==9418==    at 0x8229C98: FStateDefinitions::FixStatePointers(FActorInfo*, TArray<FStateDefine, FStateDefine>&) (p_states.cpp:724)
==9418==    by 0x8229D41: FStateDefinitions::FixStatePointers(FActorInfo*, TArray<FStateDefine, FStateDefine>&) (p_states.cpp:730)
==9418==    by 0x822ACC6: FStateDefinitions::FinishStates(FActorInfo*, AActor*, TArray<FState, FState>&) (p_states.cpp:780)
==9418==    by 0x839CEB7: FinishActor(FScanner&, FActorInfo*, Baggage&) (thingdef_parse.cpp:532)
==9418==    by 0x83912E5: ParseActor(FScanner&) (thingdef.cpp:579)
==9418==    by 0x839CD79: ParseDecorate(FScanner&) (thingdef_main.cpp:117)
==9418==    by 0x839CC5E: ParseDecorate(FScanner&) (thingdef_main.cpp:80)
==9418==    by 0x839CDFC: LoadDecorations() (thingdef_main.cpp:148)
==9418==    by 0x8192255: FActorInfo::StaticInit() (info.cpp:107)
==9418==    by 0x815CD19: D_DoomMain() (d_main.cpp:2503)
==9418==    by 0x812C8F2: main (i_main.cpp:272)
So it definitely appears list.DefineFlags isn't getting initialized sometimes.

Re: [r1249] Release compile of zdoom doesn't run

by Chris » Sun Oct 05, 2008 11:03 am

It gives me line numbers this time

Code: Select all

LoadDecorations: Load external actors.
==9241==
==9241== Thread 1:
==9241== Conditional jump or move depends on uninitialised value(s)
==9241==    at 0x822AB22: FStateDefinitions::ResolveGotoLabels(FActorInfo*, AActor*, TArray<FStateDefine, FStateDefine>&) (p_states.cpp:745)
==9241==    by 0x822AE26: FStateDefinitions::FinishStates(FActorInfo*, AActor*, TArray<FState, FState>&) (p_states.cpp:810)
==9241==    by 0x839CE93: FinishActor(FScanner&, FActorInfo*, Baggage&) (thingdef_parse.cpp:532)
==9241==    by 0x83912C1: ParseActor(FScanner&) (thingdef.cpp:579)
==9241==    by 0x839CD55: ParseDecorate(FScanner&) (thingdef_main.cpp:117)
==9241==    by 0x839CC3A: ParseDecorate(FScanner&) (thingdef_main.cpp:80)
==9241==    by 0x839CDD8: LoadDecorations() (thingdef_main.cpp:148)
==9241==    by 0x8192255: FActorInfo::StaticInit() (info.cpp:107)
==9241==    by 0x815CD19: D_DoomMain() (d_main.cpp:2503)
==9241==    by 0x812C8F2: main (i_main.cpp:272)
==9241==
==9241== Conditional jump or move depends on uninitialised value(s)
==9241==    at 0x822AB22: FStateDefinitions::ResolveGotoLabels(FActorInfo*, AActor*, TArray<FStateDefine, FStateDefine>&) (p_states.cpp:745)
==9241==    by 0x822ABF0: FStateDefinitions::ResolveGotoLabels(FActorInfo*, AActor*, TArray<FStateDefine, FStateDefine>&) (p_states.cpp:750)
==9241==    by 0x822AE26: FStateDefinitions::FinishStates(FActorInfo*, AActor*, TArray<FState, FState>&) (p_states.cpp:810)
==9241==    by 0x839CE93: FinishActor(FScanner&, FActorInfo*, Baggage&) (thingdef_parse.cpp:532)
==9241==    by 0x83912C1: ParseActor(FScanner&) (thingdef.cpp:579)
==9241==    by 0x839CD55: ParseDecorate(FScanner&) (thingdef_main.cpp:117)
==9241==    by 0x839CC3A: ParseDecorate(FScanner&) (thingdef_main.cpp:80)
==9241==    by 0x839CDD8: LoadDecorations() (thingdef_main.cpp:148)
==9241==    by 0x8192255: FActorInfo::StaticInit() (info.cpp:107)
==9241==    by 0x815CD19: D_DoomMain() (d_main.cpp:2503)
==9241==    by 0x812C8F2: main (i_main.cpp:272)
==9241==
==9241== Conditional jump or move depends on uninitialised value(s)
==9241==    at 0x40236E3: strcpy (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==9241==    by 0x8192305: GetSpriteIndex(char const*) (info.cpp:77)
==9241==    by 0x839FC59: Handler_crouchsprite_S_PlayerPawn(APlayerPawn*, Baggage&, FPropParam*) (thingdef_properties.cpp:1978)
==9241==    by 0x839D6CE: ParsePropertyParams(FScanner&, FPropertyInfo*, AActor*, Baggage&) (thingdef_parse.cpp:452)
==9241==    by 0x839D9EE: ParseActorProperty(FScanner&, Baggage&) (thingdef_parse.cpp:496)
==9241==    by 0x839123A: ParseActor(FScanner&) (thingdef.cpp:566)
==9241==    by 0x839CD55: ParseDecorate(FScanner&) (thingdef_main.cpp:117)
==9241==    by 0x839CC3A: ParseDecorate(FScanner&) (thingdef_main.cpp:80)
==9241==    by 0x839CDD8: LoadDecorations() (thingdef_main.cpp:148)
==9241==    by 0x8192255: FActorInfo::StaticInit() (info.cpp:107)
==9241==    by 0x815CD19: D_DoomMain() (d_main.cpp:2503)
==9241==    by 0x812C8F2: main (i_main.cpp:272)
R_Init: Init Doom refresh subsystem.
DecalLibrary: Load decals.
M_Init: Init miscellaneous info.
P_Init: Init Playloop state.
==9241==
==9241== Use of uninitialised value of size 4
==9241==    at 0x826DA9E: R_InitSpriteDefs() (r_things.cpp:371)
==9241==    by 0x826DD8D: R_InitSprites() (r_things.cpp:889)
==9241==    by 0x8215833: P_Init() (p_setup.cpp:3605)
==9241==    by 0x815D09F: D_DoomMain() (d_main.cpp:2586)
==9241==    by 0x812C8F2: main (i_main.cpp:272)
So it seems list.State and/or list.DefineFlags aren't being initialized in some circumstances.

Re: [r1249] Release compile of zdoom doesn't run

by Graf Zahl » Sun Oct 05, 2008 11:01 am

Can you test what happens if you replace this function:

Code: Select all

void FStateDefinitions::FixStatePointers (FActorInfo *actor, TArray<FStateDefine> & list)
{
	for(unsigned i=0;i<list.Size(); i++)
	{
		if (list[i].DefineFlags == SDF_INDEX)
		{
			size_t v=(size_t)list[i].State;
			list[i].State = actor->OwnedStates + v - 1;
			list[i].DefineFlags = SDF_STATE;
		}
		if (list[i].Children.Size() > 0) FixStatePointers(actor, list[i].Children);
	}
}
It sure was wrong but for me it doesn't make any difference.

Re: [r1249] Release compile of zdoom doesn't run

by Chris » Sun Oct 05, 2008 10:49 am

32-bit. I'll try to see if I can rebuild zdoom with more debug info..

Top