Crash! With a view entity

Oh man. So this is gonna be a nightmare. Take a deep breath, and we'll be fine.


Alright! So I work on Dungeon Deities, which is a (relatively) big project. It got lots of panels, bitmaps, and view entities, among them this one!



Including that makes acknex crash during compilation. Like so:



... but only sometimes.
If it crashes, the message is always the same:



Which, wise men tell me, means there's a FLT_INVALID_OPERATION, perhaps a division by zero.
The acklog:



(and it ends there)
Yeah, I directly give the path to the file in the filename... But it was never a problem before.

Anyway, if it WORKS, the acklog looks like this:




Sometimes it works fine. Compiles, and the game runs as it should.
But not always! Sometimes, it crashes. Inbetween those, no changes were made.

Since it only happens sporadically, this is difficult to test, so keep that in mind with the following.

Anyway, I've also tried publishing the whole thing. The resulting exe also crashes - sometimes. It used to crash pretty much everytime, but now I can't get it to crash (and on a different computer, it never crashed, but in fairness, I've only tried about three or four times). The error for that told me this:



which, as you will notice, has the same Exception Code (c0000090), and the same entries for "Additional information".

AS you can see from the screenshot, the whole thing crashed before the "xx seconds" message, before the amount of objects are stated, and before my actual script is started. So maybe it's the pre-processor. So I removed that ENTITY*-definition, and replaced it with a corresponding ent_createlayer-call.
If I run that, it crashes (when it crashes) AFTER compilation (there IS a "xx seconds" message, then a black window for a split second, then a crash).
I've now put "waits" in my panel/bitmap/view-entity initializations, and SO FAR it hasn't crashed. But I sure don't feel particulary happy and safe with THAT arrangement.


So maybe it's the model, right? Maybe it's corrupt. I've tried replacing it, and it seems that with some models - used in other view entity definitions that worked fine so far - there are no crashes. But with others (not used in a view definition) that work fine as level entities (and have for a long time before), it crashes again.
Anyway, I have uploaded the model for your consideration here.



I humbly ask for your assistance, because quite frankly, I'm lost.
I unfortunately couldn't create a simple program that also crashes (I mean, I can't even get the main game to reliably crash). I suspect it may have something to do with the amount of objects listed for the pre-processor, but this is really just a wild guess.


Help me, jcl.

Help. : (



Oh, yeah, before I forget. 8.45 also crashes.



I'm using two external, old DLLs from A6 times that I do not wish to replace, as they're quite central to the project. Unless you're pretty certain they're at fault -- and they have been working fine for years in this project (yes, even in A8) -- I'd rather not replace them.

Oh noes!
Have you tried turning it off and on again (read: in which mode do you start the program when it crashes, test or debug run)?

It's a "Test Run". I haven't tried it in Debug Run - as soon as it's crashing again (which, thankfully, it doesn't do right now - why is anyone's guess), I'll check out the Debug run!

Does a #define PRAGMA_ZERO resolve the issue?

Does replacing Models\\lock.mdl with an arbitray dummy model fix the issue?

If you got a model that randomly crashes, the first thing to do is loading it in MED, and saving it again. That can often repair a damaged file.

Crashes that do not happen always, but depend on random memory content, are hard to find. But from what you've written, it seems that you already traced it down pretty well to that particular model.

Thanks for all your replies!

I've tried resaving the model (both in MDL7 and MDL5-formats), with no results. Also, replacing it with a different one sometimes worked, and in other times did not.

Right now, it hasn't crashed in a while, so possibly something I've done magically "fixed" it - perhaps turning the direct view-entity definition into an "ent_createlayer"-call, perhaps distributing the workload in the first frame somewhat. I don't exactly feel super-comfortable with it, but if it doesn't crash, I can't really work on investigating the bug, either.

If it crashes again, I'll make sure to try out PRAGMA_ZERO.

Thanks again for all the help. I'll be back if it stops working again.

So I have been working on my laptop (instead of my desktop computer) for the past few days. And behold, it crashed.

But not a complete super-crash as before - instead, it says...



"LOCK.MDL: Bad file format."

So yeah, I've tried other models, and as I've said, it worked sometimes, but sometimes it didn't.
My current suspicion is that the models that don't work have all been saved on my desktop computer since a recent reinstall of windows.

So perhaps, my MED-installation on this computer is faulty, or for some reason creates faulty files.
jcl, can a faulty model really crash the pre-compiler as shown in the first screenshot in this thread?

I'll investigate a bit more.

Thank you all for your help. Uhrwerk, I'll try the PRAGMA_ZERO as soon as I get it to reliably crash again.

The dots in the compiler window mean two things: At first your script gets compiled and "checked" for syntax errors which probably everyone is aware of. Then however without notice at some point the "..." dots have another meaning, that is the engine is loading and creating engine objects such as SOUND files or apparently view entities.

I don't know but could it be that some other previous file is damaged which then leads to loading errors on subsequent files?

I once had a really weird acknex crash (I think it was of the "acknex.exe has stopped working" type) where indeed the reason was a faulty texture/ bitmap, it's not that uncommon (especially when you consider that MED literally destroys some files on saving if you don't treat it with care - for example on some "unsupported" undo operations the model gets messed up and when you then save it, all hope is lost).

I see.. yeah, that would make sense then. I don't really look forward to going through all models (let's assume that my images that were made in MS Paint or Photoshop are fine - at least for now) that get loaded, but since all this only started after I've added the "lock.mdl", and given that it crashed relatively often since then, it's probably save to assume that this model is indeed at fault.
But in any case, I now have a better idea of where to look.

Reloading the model into MED and just saving it again didn't change it at all - I've checked it byte-for-byte. This is true when done on other computers, as well (so maybe it's not a faulty MED installation).

I've just re-imported the 3ds and saved it new.
I'll be back if it crashes again.


I think it'd be great if, at least in the development version, the point of loading and creating objects would be indicating somehow - maybe with a ; or a _ or whatever. This would have saved me some time.




I also must say, I really was afraid that after posting this, this thread would die a quiet death. It's great to see that you guys are there to help! Thanks again.

Can you elaborate a little more on this? You have indeed mentioned this multiple times but I still don't know what the results are (esp. how and when does it crash/ not work then?).

I wouldn't use the seemingly problematic lock model at all anymore until I'm sure it is the reason.

I haven't touched the script. Instead, I renamed the original "lock.mdl", then copied a different model from the project, renamed the copy to "lock.mdl", then started the script.
Sometimes it crashed, sometimes it didn't.

I believe now, though I don't remember it 100% anymore, that it crashed with two models: The original "lock.mdl", as well as a different MDL5-version of it, and a model of a treasure chest that is in the game. These are the only models I've touched with MED since I've done a reinstall of Windows on this computer.
Other models, both from my projects, as well as a testmodel from the forum, did not trigger a crash*



I'm not sure I understood what you mean - I'm assuming the "lock.mdl"-model is the reason, but I've now replaced it by loading the original 3DS-data (the model was made in Wings3D), and saving that as a MDL. So the original faulty model isn't used at all anymore.



* - I've tried running the thing several times per model, since the crash only appears semi-regulary. However, at the time, it crashed every time with the models mentioned.

It can indeed be a different model that is loaded before the offending lock.mdl. The "bad format" message box appears when loading a model caused a crash. If the crash happened _after_ loading the model, the compiler can not detect it and crashes without message.

A damaged file often does not crash immediately, but leads to subsequent crashes, for instance when it is damaged in a way that loading it overwrites a wrong memory area.

Which should never happen. o.O
A loader has to verify the data or abort if suspicious, instead of pushing it into memory without control.

You're certainly right. At least as long as you don't use real existing software, such as Windows or DirectX.

Well, i suspect, the mdl(7) file is not loaded by directx, right?
So the stage of loading and validating is before pushing it to directx

Maybe such a validation could be implemented for the development version, preferably only when forced through setting a variable to non-zero (so it does not slow the loading down that much)?

YES PLEASE.

A standalone tool that checks all files in a folder would be fine, too.
(I wouldn't mind if it would only check Acknex-formats.)

Also, some kind of parameter that makes it so that Acknex writes the filenames of each file loaded into the acklog would help - if it crashes, at least we know which files to look at, then. I suppose that would be easier to add.


It is a NIGHTMARE to find this bug otherwise in bigger projects, what with its random, sporadic appearances.

Surprisingly today I get the same error ("Bad File Format") in a new project, no 200 lines of code. The message does not appear when I remove the second skin and weirdly when I do the following check:


the engine will not crash which makes zero sense to me.
I can send this project in to the support if wanted.

EDIT: No view entities, just regular ent_created objects.

All engine versions do file validation - it would make not much sense to validate files only in the development version. But as you see, this can not always prevent a crash.

If a model crashes during compiling, you can see the previously loaded models in the code. All object definitions are loaded in the order of appearance.

If you have no object definitions in your code, the crash will happen at runtime, not during compiling.

Let me emphasize this: In my case it's not a problem with a certain model or a texture (at least I'm 99.9% sure) because I just created a new model of 3 primitives, added two skins, made a new texture and it still crashes. There is only one model/ one type of models in this project.
I will now just send it to support, no matter if you want it or not.

We got your models, but they seem to be fine - no crash, file header and validation ok. Maybe the problem has a different reason, unrelated to the model? Crashes can also happen when a piece of code overwrites internal memory.

That's weird to say the least. I've reduced the code and the project now to an absolute minimum, please download it here (not only jcl but some other readers as well, please): http://www.superku.de/mdl_crash.zip

It crashes on both my desktop (newest A8 version) and my laptop computer (8.30.5), all files have been replaced by new ones (even the level which only consists of one "position"/ camera and one object) and the codes has been checked multiple times for mistakes.

However, what makes the problem even weirder, the crash disappears as soon as you change literally anything in the main function code (that includes commenting "video_mode" or removing the lines after "return").

Thanks for the new project - that one indeed produces an error message. It has apparently nothing to do with your code and how you change it - the model just crashes randomly. We'll look into it.

Thanks, I'm interested to now what causes the error!

i think the problem is in (wait) when i add it befor the for loop evrything work great in this exemple .

you need to wait one frame after level loading

which is an odd design

That's the thing, man. Remember what Superku said?




Almost any change stops the thing from crashing, it's a very erratic and random behaviour. So it's difficult to say that you found the cause when you find a change that stops this crash - as a completely different, unrelated change does so, too.




jcl, thanks for investigating and all your help. I'm hopeful that we find out what causes these strange errors.

Just an aside, would you still consider this?



It sounds as this would be something relatively easy to add, but it allow us to narrow things down if we get a crash at that point.

Thank you!

ah yes you're right

Tested and i got the same error message, like Superku mentioned Error E1198 TILE3.MDL: Bad file format.

However i think the problem is the second Texture "Skin2" without Texture checked.

If you just try to check the Texture the issue will gone.

Which is just nonsense. Please stop spreading misinformation like that.

yes you're right, i had something similar in mind, which is really wrong o.O.

Hh ,man , i think if we put every day like this problems, the android plugin not came in this year

@Dico, Superku problem was simple, the second Texture was not "checked" in relation of uv information from Skin2.

@Error014, try without Mipmaps "checked" re-save and let us know if this work.
See how behaves also with bigger resolution.

In my opinion very small Texture (16x16) like lock.mdl do not need mipmaps.

@rojart: This should not lead to an error, though. I have hundreds (!) of models with (multiple) skins and without textures in my side-scroller and it works just fine.

I did not know that uv should work without texture information, some strange technique for me, for what purposes do you need the second uv without textures?

Can you upload the model with second uv Skin2 without Texture checked where it works or pm me, i will make some tests.

A skin with no texture was not the crash reason. In fact we have not found it yet - in the debugger the project behaves normal and does not crash or overwrite memory. We have to check the loading process step by step for all involved files, and manually look for anything unusual. This will take some time.

@rojart: I'm not completely sure that we are talking about the same thing. I'm not using a second uv set but just set some faces to different materials/ skins than others. Most of the time I do not need to assign textures because I just color things dynamically or use a few global bitmaps to give those parts a metal or glass effect and the like. Assigning textures would not have any advantages.

A working example can be found here: http://opserver.de/pwik7/index.php?title=Ent_mtlset

Yes, you're right it works without Texture checked, but i think this happens if you use d3d_antialias function, maybe a bug!

If you try without the d3d_antialias function, your model will work.

Sorry for misleading claims about second Texture not checked.

EDIT: No, it's not d3d_antialias, the same happens if you try with video_mode, sorry!

Ok, starting to check the whole code and here my results:

If i change the "var i,j,k,l,m,t,isteps;" to "int i,j,k,l,m,t,isteps;" should works.

I noticed also, if we uncomment this line "if(you == NULL) error("AAA"); // <- hier" will only works with "var i,j,k,l,m,t,isteps;"
But "int i,j,k,l,m,t,isteps;" will only works with "if(!you) error("AAA"); // <- hier"

Congratulations for getting what the bug is about?
Not trying to be snarky (okay, yes, I do), but that's exactly what the bug report is about.

rojart, I appreciate your help but I fear that does not lead to anything. You can quite literally change every line of code in the main function and sometimes somewhere else and it stops crashing. I think only jcl can isolate the problem with his debugging tools (and his mighty power).

Yes, you're right, but if we stopping to test it where this happens and give no hints like var to int works, we will waiting longer i think.

It's not urgent in my case but I'm curious, have you, Mr. Lotter, found anything yet?

Wladimir traced it down. It's no problem with your models, but apparently a rare bug in the compiler - that's why no one noticed it so far and why it disappears when you change anything in the code. We'll change a part of the compiler and then provide a patch.

Thanks for the heads-up!

Good to hear - thanks again!

Hey, can we get a heads-up on this? How far along is this bugfix?
Can you release it before the next version to avoid another potential long wait?

Wlad is still translating the chinese comments. Might take a while.

Well, the chinese comments are not really to blame here - with "compiler" I meant the VC++ compiler, which did not translate a part of the lite-C compiler correctly under rare circumstances. It's an issue with static variables. We're anyway switching to a new version. But the fix cannot be delivered in a quick patch, it must be a major update.

A9 confirmed?
What's the reason, ABI compatibility with SDK plugins?

Oh. My. God.

No, of course not A9, but the next major A8 update. It's just not possible to quickly upload a patch. The problem has been in the compiler code since 2007, so I suppose that it is not this extremely urgent.

So this means the next A8 update is going to take a longer time?

...but hopefully with a lot of top secret new features...

...like TUSC button.

Has there been any progress regarding that next major update (meaning: that bug getting fixed for us)

Sure, the update is readier, but not fully ready yet.

Has this compiler issue been fixed in the most recent update?

Ah.... that may explain the strange crashes with the latest project... still had them with the latest engine release, though.
Luckily wait(1) fixed it.... ....

It is not really clear if it has been fixed. A suspicious part of the compiler was cleaned up and the problem disappeared. But it could not be traced down to a particular bug. - If the problem were still there, wait(1) would probably not fix it, so that could be a different issue.

I can send in the project if interested.
However there might indeed be other reasons for a problem which I could not identify.

Sure, please send it to Support and we'll check it.

Was the project of any help?

Well, not really yet, but there is still hope. The problem was of course that there was no problem here - no crash on any PC. Well, that's how crashes tend to behave. We plan a more thorough check in a special environment together with some other projects with similar issues. I hope then we'll find out what's happening. But that will take a while.

Did you remove the wait(1) in question AND publish? It does not crash in dev mode.

Yes, sure. The problem is when you do something evil, such as modifying a parameter of a just removed entity, it does not necessarily lead to a crash. That depends on the way the memory is allocated. So it's sometimes a bit difficult to find that problem from the outside, without diving into the script code.

I've changed a few things in my project and now I get the "bad file format" error. But... I've changed a view entity, too (from *.tga with emissive_... acknex material to *.mdl with *.fx effect). Has this issue only appeared in projects with view entities so far? EDIT: No, happens with regular entities and tiny projects, too.

Tiny project sounds good: if it is reproducible even with a tiny tiny project, we could have a good chance to reproduce the problem here.

It's the same demo project I've linked some time ago, see here:
http://www.opserver.de/ubb7/ubbthreads.php?ubb=showflat&Number=438628#Post438628

The model has a secondary skin without texture. Maybe that's the reason for the crash after all? Which would be odd though, half of my models usually don't have textures and it works fine.

The problem with that project was that we could not reproduce a crash here, with or without wait, not even in the debugging environment. But I can say that it has probably nothing to do with the no-texture skin. If you get any other, maybe even tinier project with a mysterious crash, we're always interested in looking into it.

Could it be (a wild guess) that since you are using ent_for_name (where you aren't allowed to change any parameter of that entity if it's static) it's crashing because you're changing it's emask?
Commenting that line out prevents crashing, but as you said, maybe it's not because of that, but another problem.

EDIT: Nevermind, as you said any change will "fix" it.

The crash just wanders somewhere else. Now the newly created bone based player character model throws a "bad file format" when entering some levels.
I have no idea anymore what to do about this, and I really have a bad feeling about releasing my game.

Well I've just realised that my new player model has 2 additional no texture skins (with UV mapping) again which the old one didn't. I'm pretty sure the error only appeared on/ with models which have skins with no textures.

Can you please double and triple check that part in the engine again?
(Btw. the error happens between "LevelReady" and "def_startup started" but I assume you are aware of that.)

EDIT: The mini example from some time ago still crashes on my machine. Is there something I can do with it (except strapping it down a little more) that helps you in finding the cause of the error (including stuff you may send me which I test)?


EDIT2: Made the old example even smaller: http://superku.de/mdl_crashNew.zip
The error does not appear regularly, sometimes on the first try, sometimes it doesn't appear 7-8 starts in a row (with this linked example). - Crashes without the view entity too:

Code:

///////////////////////////////
#include <acknex.h>
#include <default.c>
///////////////////////////////

void main()
{
	fps_max = 60;
	video_mode = 9;
	level_load("test.wmb");
	wait(4);
	ent_create("tile3.mdl",vector(128,0,32),NULL);
	vec_set(sky_color,COLOR_BLACK);
}

And even smaller: http://superku.de/mdl_crashNew2.zip
Now it's only a few lines of code, a NULL level and one entity ("tile3.mdl"). If you remove the empty skin(s) (or load "tile3b.mdl") the crash is gone. Otherwise, after 5-6 starts at the latest the error should appear.

I tried it 20 times in a row, but sadly it won't crash on my machine.

Tried about 20 times with both models ('tile3.mdl' and 'tile3b.mdl'), but it did not crash for me.

Greets

Oh no.
Thanks anyway for testing. I'd post my system config but it used to crash on my laptop too which has completely different components (and Windows version - EDIT: Wait, that's not true. My old laptop had Windows 7, too.).

EDIT: @alibaba: I've now downloaded it again and seen that per default it tries to create "tile3b.mdl", the one that doesn't crash. That's a bad mistake on my part, have you tested that file or "tile3.mdl"? (This has now been fixed and uploaded under the same download link.)

I got the crash now, but only if I press 'Run current script' button in the SED! I used to launch it with F5 before (which is test run as far as I know), and it did not crash at all. Also I found out that it actually crashes only if I press 'Run current script' button in SED, if I press F6 (which is 'Run current' too, according to the hotkeys) it won't crash... I tried to run the script about 20 time with both F5 (Test run) and F6 (Run current) hotkeys and it did not crash at all. This is really weird.

Here is the crash screen:


Best regards!

Oh, that is really strange indeed!
I've clicked both "Run current script" as well as "Test Run" and it crashed on both.
Good that it crashes on someone else's machine now, too.

I just tried to click on 'Test Run' button and it crashed, but it took more tries (about 8-9).
Really weird part is that it doesn't crash with hotkeys (F5 and F6).

I can also reproduce, not a crash, but a wrong content of a variable of the internal model structure. And it is really related to the empty skin!

We'll check this more closely, but it looks like a real random bug of the model loader that can in fact cause a subsequent crash. If so, it will be fixed in the next update. I'll post when I know more. Thanks for that project!

Thanks, good to hear. Looking forward to it!

It was indeed a hard bug, leading to random errors on loading models with mixed empty and non-empty skins. This will be fixed in the next update.

Workaround: Use models either with textured or non textured skins, but not with a mix of both.

Great!
However, could you please release an (interim) update soonish then? Having the game crash on random levels during playtesting is mildly annoying but can be dealt with. My game's release is coming up soonish (in May) though and I want to send it to a few beta testers way before that.

We'll try to make it soonish.

Good, thanks.

The latest engine release seems to fix this problem. I cannot reproduce it anymore on my pc.

and... yes... there was a suspicious model with skin/no skin mixture (wichtel_rot.mdl).