Help! Corrupted gunk in demo header and footer

TM, I don't know how you do it, but your demo is corrupted. The header has P_GetNodesVersion: using normal BSP nodes. before the demo version marker (0x6D hex, m ANSI) and the end of the demo is similarly munged: there's I_ShutdownSound: . before the demo end marker (0x80 hex, ANSI) and right after it instead of the demo footer there's G_CheckDemoStatus: Demo recorded. This is really bizarre! How d'you do that? ;)

Editing the junk out allows the demo to play, and it's a nice one. There's definitely plenty of DOOM in you still, you only need to sort the bad voodoo out. :P

Edit: spelling.

Share this post


Link to post
Never_Again said:

TM, I don't know how you do it, but your demo is corrupted. The header has P_GetNodesVersion: using normal BSP nodes. before the demo version marker (0x6D hex, m ANSI) and the end of the demo is similarly munged: there's I_ShutdownSound: . before the demo end marker (0x80 hex, ANSI) and right after it instead of the demo footer there's G_CheckDemoStatus: Demo recorded. This is really bizarre! How d'you do that? ;)

Editing the junk out allows the demo to play, and it's a nice one. There's definitely plenty of DOOM in you still, you only need to sort the bad voodoo out. :P


What in the world is all of that!?

Try this demo to see if it comes out the same way

fa13-228.zip

Share this post


Link to post

Well, I can't tell - prB+ attempts to play back your fa13-228 according to demo_pattern25 (in glboom-plus.cfg) and it promptly desyncs on DOOM2's MAP03. What WAD is it for? Did you turn off the Extended Demo Format to test if that was the cause of corruption? In that case, the demo came out fine (except I have no idea what to play it back with properly). If Extended Format was indeed the culprit, entryway would be interested in learning the exact steps of reproducing this strange behavior, methinks.

Edit: moved the part of the post unrelated to this thread back to Misc Demos.

Share this post


Link to post

Tenda, I got the same problem when looking at your Revro demo in XWE. How exactly did you record your demo?

Share this post


Link to post

You should definitely let entryway know in the prBoom-plus thread or, better yet, submit a bug report on prB+'s sourceforge site. Be sure to detail the steps involved in producing corrupted demos and include the demo and your prboom-plus.cfg (or glboom-plus.cfg if you run the unified executable).

Share this post


Link to post
TendaMonsta said:

-xxx -nomusic


I'm just hazarding a guess here, but I think those two switches might be the problem.

Share this post


Link to post

I just attempted to playback all of my demos I've recorded recently and they all have that "unknown demo format 80" thing...What in the world is going on.

N_A I will definitely tell him about this issue, because everything is just acting weird. I may actually reinstall prboom-plus2.5.0.8 again to see if it fixes anything.

I'm so full of voodoo right now :(

Share this post


Link to post

"-xxx" is part of the demo filename, and I recorded with "-nomusic" for ages.

Just re-downloaded prB+ v2.5.0.8 and CDL and ran it with TM's command line - no problems. The resulting demo has the proper header and footer.

Does this happen on a fresh install of prB+?
BTW, this discussion may need to be split from this thread.

Share this post


Link to post

Try running from the command line, without any launcher. Other people haven't had this problem, and the most obvious thing you are doing different is using the CDL launcher, so that is the first thing to consider. (From what N_A says just above, it doesn't appear to be a fundamental problem with the launcher, but maybe there is something in the settings you are using.)

And don't delete the corrupted demos you have recorded. From what N_A says, it is just a matter of editing them with a Hex editor, and they'll work OK.

Never_Again said:

BTW, this discussion may need to be split from this thread.

Done. Please repost your unrelated demo in the misc demos thread. (Yeah, I could have duplicated the post by splitting it into its own thread, copying and remerging into both threads, but it's a messy process.)

Share this post


Link to post

Thank you, Grazza, that was very quick.
Indeed, all the demos should be salvageable. TM, get HxD and open a corrupted demo with it.

1) Delete everything preceding the demo version marker (0x6D hex, m ANSI) in the demo header:




2) Scroll down to the end of the file and delete 12 bytes preceding the demo end marker (0x80 hex, ANSI):




3) Delete everything after the demo end marker:




You will be warned that each operation changes the file size - that's OK in this case.

Share this post


Link to post

Issue solved! I deleted everything in my doom folder "except wad files" and I reintalled everything I had, but this time everything is in a folder depending on the application or similar file extensions.

This really was a work of voodoo! Thank you guys for your help and the HEX information.

Share this post


Link to post

The issue is not solved. It may be indicative of a file system corruption - I can't think of a scenario where prB+ would write bits and pieces of stdout.txt into the demo header and footer. It also could be faulty RAM. I would thoroughly check both if I were you.

Share this post


Link to post
Never_Again said:

The issue is not solved. It may be indicative of a file system corruption - I can't think of a scenario where prB+ would write bits and pieces of stdout.txt into the demo header and footer. It also could be faulty RAM. I would thoroughly check both if I were you.

Seems exceedingly unlikely to me. It wouldn't happen the exact same way every time if it were a RAM or drive problem because the data would be at different addresses/physical locations and at different alignments relative to other structures.

Seems most likely to me that some file handles are getting jumbled up internally somehow. It could be heap or BSS corruption, for example writing one off the end of an array of file pointers and biting what happens to be the location of stderr or stdout, or a variable which is passed into one of those two via a redirection routine. There are a lot of ways this could happen without involving a machine problem.

Unless Tenda is on Linux, the fact the messages appear with 0A at the end and not 0D0A indicate that they were deliberately written by the system to a stream set to binary output mode.

Share this post


Link to post

Assuming he answers Windows, then based on a cursory examination, I would suggest reviewing the code in SDL_win32_main.c - there is a lot of string handling in this module, which in a C program, is always cause for immediate suspicion.

It is quite likely that, when launched by CDL, there is an unexpected condition with the working directory, argv[], or return values from Win32 API functions. EE has in the past had similar issues when being launched by other programs - though never in our case did we end up redirecting a stream inappropriately - we just wrote files to the wrong disk location.

Share this post


Link to post

glboom-plus -record stdout.txt -complevel 2 ? :)

But in this case I have "P_GetNodesVersion: using no BSP nodes..." at the end of demo.

Share this post


Link to post
entryway said:

glboom-plus -record stdout.txt -complevel 2 ? :)

But in this case I have "P_GetNodesVersion: using no BSP nodes..." at the end of demo.

It would have to be something a lot more subtle than that. I'd suggest starting with trying to recreate the exact conditions he ran the program under, otherwise it probably will never happen. I feel use of the launcher *has* to be a key variable in this. The behavior of some Win32 APIs change in a subtle fashion when programs are executed by other programs. For example the process security policies, working directories, etc. may be inherited from the calling process depending on how CreateProcess was called. This can be unpredictable at best.

Share this post


Link to post

Ok let me explain so I can make things easier for you guys. I use windows 7 Home premium 64bit.

All of my doom files are in one folder and there are no sub-directories. All the files are just jumbled together (probably not a good idea), and I have never had a problem on Windows 7 or XP. Even when using CDL I didn't have a problem until I randomly recorded a demo and it gave me the "unknown demo format 80". Do you think this is a CDL issue because I really don't want to get rid of this application?!

The issue was solved (it still isn't solved) when I reorganized all of my doom files and put them in sub directories (that way the dll files won't interfere with one another like they used to). I then reinstalled every application, executable, and source port I had into the sub directories with the corresponding names and all my demos have been recording properly since...Before reorganizing I also hid some of the files...I don't know if that would be the problem, but this voodoo issue happened very recently after I hid the files. I don't think that hiding the files will have an effect on the applications though. I hope I gave thorough and understanding information so that this issue can be solved.

Share this post


Link to post
TendaMonsta said:

The issue was solved (it still isn't solved) when I reorganized all of my doom files and put them in sub directories (that way the dll files won't interfere with one another like they used to). I then reinstalled every application, executable, and source port I had into the sub directories with the corresponding names and all my demos have been recording properly since...Before reorganizing I also hid some of the files...I don't know if that would be the problem, but this voodoo issue happened very recently after I hid the files. I don't think that hiding the files will have an effect on the applications though. I hope I gave thorough and understanding information so that this issue can be solved.

What files did you move? We'll probably never know what was really causing it if it was a DLL-hell problem.

Share this post


Link to post

I only moved my wad files and deleted all of the other files, executables, and source ports. I think mixing the DLL files of a source port with another isn't recommended.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now