I'm remembering one thing now...
I had such a crash problem with decals and using level_free(). The terrain with decals attached was removed, but the decal function was still running and then crashed.
Adding a wait(1) before level_free() fixed the issue.

Are you doing anything like this somewhere?

Simple errors, like freeing an already-freed entity, are normally caught by the engine and will not cause a crash. If the error is not obvious, it could be something more sinister, such as something overwriting some internal memory areas.

For finding the reason of such a problem, reduce your application step by step until the crash disappears. First remove all external plugins, then disable all functions that access internal memory structs, then remove all effects. If then the problem still is there, send me that project and I'll look into it. I'm meanwhile sort of an expert in finding hidden bugs in user projects.

Normally not, otherwise we'd named the function not "wait()", but "fixbug()". If a wait(1) changes the behavior of a bug and you don't know why, it can give a hint where to look for the bug. But it's normally not a fix.

problem was that the terrain was removed from memory (level_free!) and the decal routine seems to lag one frame behind. Of course it accessed the non existant terrain then.

That was the only plausible reason I found. it is directly related to a decal on a terrain.

What is a decal routine?

whatever the decal does during its lifespan.

partCursor = ent_decal(NULL, bmapTemp, 40, vTemp + vAngle);
partCursor->lifespan = 0.001; /* only 1 frame */

I'm spamming the terrain with decals in a while loop.

The lifespan only tells the renderer whether this decal must be rendered in the current frame. Unlike particles, decals are not doing something, they are just a passive list of objects.

If you had some function in your project that crashes when a new level is loaded, putting a wait(1) before level_load would obviously not help - it would then only crash 1 frame later. But if you have a while loop that is generating decals, stop that loop 1 frame before level change. Otherwise, placing a decal on an invalid terrain pointer can indeed cause a crash.

So stopping the function in the same frame before level_free() is not enough?
Well this tells then where the wait(1) comes from.

Without level_free() no wait(1) is needed.