Author Topic: Assert: "0"  (Read 827 times)

0 Members and 1 Guest are viewing this topic.

I've been putting together a modpack from various ships, and I figured I'd go through and start fixing the errors they were throwing at me. After a little while I ran into this one:

Code: [Select]
Assert: "0"
File: parselo.cpp
Line: 234

ntdll.dll! ZwWaitForSingleObject + 10 bytes
KERNELBASE.dll! WaitForSingleObjectEx + 156 bytes
fs2_open_3_8_0_x64_AVX-FASTDBG.exe! <no symbol>
fs2_open_3_8_0_x64_AVX-FASTDBG.exe! <no symbol>
fs2_open_3_8_0_x64_AVX-FASTDBG.exe! <no symbol>
fs2_open_3_8_0_x64_AVX-FASTDBG.exe! <no symbol>
fs2_open_3_8_0_x64_AVX-FASTDBG.exe! <no symbol>
fs2_open_3_8_0_x64_AVX-FASTDBG.exe! <no symbol>
fs2_open_3_8_0_x64_AVX-FASTDBG.exe! <no symbol>
fs2_open_3_8_0_x64_AVX-FASTDBG.exe! <no symbol>
fs2_open_3_8_0_x64_AVX-FASTDBG.exe! <no symbol>
fs2_open_3_8_0_x64_AVX-FASTDBG.exe! <no symbol>
fs2_open_3_8_0_x64_AVX-FASTDBG.exe! <no symbol>
fs2_open_3_8_0_x64_AVX-FASTDBG.exe! <no symbol>
fs2_open_3_8_0_x64_AVX-FASTDBG.exe! <no symbol>
fs2_open_3_8_0_x64_AVX-FASTDBG.exe! <no symbol>
fs2_open_3_8_0_x64_AVX-FASTDBG.exe! <no symbol>
fs2_open_3_8_0_x64_AVX-FASTDBG.exe! <no symbol>
fs2_open_3_8_0_x64_AVX-FASTDBG.exe! <no symbol>
fs2_open_3_8_0_x64_AVX-FASTDBG.exe! <no symbol>
fs2_open_3_8_0_x64_AVX-FASTDBG.exe! <no symbol>
fs2_open_3_8_0_x64_AVX-FASTDBG.exe! <no symbol>
kernel32.dll! BaseThreadInitThunk + 13 bytes
ntdll.dll! RtlUserThreadStart + 29 bytes

Now this is a problem, because it seems to force-close the debug build -- there's no "continue" button, only "debug" and "exit", and "debug" just crashes FSO. This means that I can't access any of the errors that come after this one in the list, so I need to deal with this before I can continue.

Judging by my research, parselo.cpp is some component of the source code that I'm not going to be able to access on my own (even if I could figure out what the hell "Assert 0" means), so I needed to come to you guys.

My fs2_open.log is here: https://fsnebula.org/log/5c499c17cb0d330946c29e1d

Thanks for any help!

 

Offline AdmiralRalwood

  • 211
  • The Cthulhu programmer himself!
    • Skype
    • Steam
    • Twitter
Somehow, while parsing test-shp.tbm, FSO encountered an error on a line that's apparently beyond the end of the file. That obviously shouldn't be possible, but might be due to a code error from the fact that 3.8.0 is now somewhat out-of-date (we're hoping for another stable release some time in the next few months). Try running your test mod on a recent nightly build (go to Knossos's settings, expand the "Knossos" section, set "Preferred Engine Stability" to "Nightlies", hit save, then update FSO) and see if you trip the same assertion; if you do, upload this table somewhere so we can see why it's going horribly wrong.
Ph'nglui mglw'nafh Codethulhu GitHub wgah'nagl fhtagn.

schrödinbug (noun) - a bug that manifests itself in running software after a programmer notices that the code should never have worked in the first place.

When you gaze long into BMPMAN, BMPMAN also gazes into you.

"I am one of the best FREDders on Earth" -General Battuta

<Aesaar> literary criticism is vladimir putin

<MageKing17> "There's probably a reason the code is the way it is" is a very dangerous line of thought. :P
<MageKing17> Because the "reason" often turns out to be "nobody noticed it was wrong".
(the very next day)
<MageKing17> this ****ing code did it to me again
<MageKing17> "That doesn't really make sense to me, but I'll assume it was being done for a reason."
<MageKing17> **** ME
<MageKing17> THE REASON IS PEOPLE ARE STUPID
<MageKing17> ESPECIALLY ME

<MageKing17> God damn, I do not understand how this is breaking.
<MageKing17> Everything points to "this should work fine", and yet it's clearly not working.
<MjnMixael> 2 hours later... "God damn, how did this ever work at all?!"
(...)
<MageKing17> so
<MageKing17> more than two hours
<MageKing17> but once again we have reached the inevitable conclusion
<MageKing17> How did this code ever work in the first place!?

<@The_E> Welcome to OpenGL, where standards compliance is optional, and error reporting inconsistent

<MageKing17> It was all working perfectly until I actually tried it on an actual mission.

<IronWorks> I am useful for FSO stuff again. This is a red-letter day!
* z64555 erases "Thursday" and rewrites it in red ink

<MageKing17> TIL the entire homing code is held up by shoestrings and duct tape, basically.

 
This seems to have worked. Thanks!