VRAD: 100% reproducible crash on a very normal map (update: not 100%)

[Shrinker]

Hello BM team,
I have a test case here that I’ve already reduced as much as possible by deleting everything I could without the crash stopping.
It’s a little maze map:

There’s nothing special about the map - no especially big brushes or anything off the grid or something like that.
It’s just that if I remove any brush or add a new brush, and make sure that’s the only difference in the textual VMF file (just a few lines for one brush are changed), vrad stops crashing reliably, and if I use the version with the precise brush count I have, vrad crashes reliably. It looks like I’ve hit some kind of magic value internally with a brush count, or with derived information such as the approximate area of faces or visleafs.

I’m compiling with the default release settings:
BSP Normal, VIS Normal, RAD Final

I have put the archive containing the crashing and a working VMF here:
https://mega.nz/#!PjZQAQwK!z4taZwpKJaWMi0FRNuBwG9hLwMbw295f-LJ2zcyfia8

Regards,
Shrinker/Hai

[sea.level.rises]

I was able to compile your _crash map without error using your compile settings as described, but I may have found a bug in Hammer.

The brush adjacent to the additional brush added to _nocrash is brush #33 (selected in image below), but the number reported by Hammer’s “Show Selected Brush Number” reports that this is brush #32 (see image below); the VMF also lists this as “id” “33”.

In a possibly unrelated matter, there are two (unexposed) brush faces on the map with erroneous texture alignment (select Map -> Check for Problems and look at all sides of the affected brushes).

[Shrinker]

Argh!!
Well on the one hand I am glad it doesn’t crash for you because it means the map could be compiled as it is. On the other hand I am worried because then this turns into a not so easy to reproduce crash error.

But the two faces with misaligned texture vectors you’ve discovered – Those shouldn’t exist! You’ve just found a bug in my level generator or one of the scripts, and that’s a thing I can investigate and fix! \o/
(unfortunately, adjusting the texture projection settings there didn’t have an influence on my crash, but still)

The brush IDs themselves seem to have no effect at all. Face IDs on the other hand could be trageted by entities such as the cubemap probe.

*update a few hours later: This has no impact on the vrad crash, but i’ve found and fixed the bug in my generator. Phew.