safe_malloc error on unchanged map that used to compile ok

(2Bit) #1

===================
Update: Problem resolved - it was a change to the shader (to generate surface models), not the map source that caused the safe_malloc failure.

I’ve encountered a GtkRadiant/q3map2 error that doesn’t make any sense to me. I’ve been creating a map for the last couple of weeks and everything was fine until today.

I had been compiling and testing all morning, when around midday at a compile stage called SetupTraceNodes after about 8 mins of compilation, GtkRadiant 1.4 aborted with this error: safe_malloc failed on allocation of 276824064 bytes.

I thought something was corrupt in the map. I make several separate backups during each day of mapping, so I restored to the last backup which was made last night, and submitted the compile just to make sure I was back on track.

The compile failed again with the same error!

How could the map source compile fine last night but not today? I haven’t changed my PC or GtkRadiant setup in the interim.

Can anyone help please?

Thanks

(carnage) #2

if you have not manually updated your q3map2 to the latest version you could try grab GTKradient1.5.0 and see if you can compile with that since it comes bundled with the latest q3map2

also note that the compiler and editor are two separate things and replacing the editor may not fix the compiler

(2Bit) #3

Thanks for your suggestion carnage, I appreciate your help.

I did try Radiant 1.5.0 but it was unsuccessful - however I have since twigged what the problem is.

I remembered that I had changed a definition in the map’s shader file. I am an amateur when it comes to fiddling with shaders, and I hadn’t realized what a catastrophic effect a small shader change can have on a compilation.

I had added in some surface models, just some bushes/grass etc, and it worked fine in a small test map I use for checking how shaders are looking. Evidently when included in a much larger map the number of automatically generated bushes was blowing some memory limit.

Reduce the density of surface models generated and problem solved :smiley:

Thanks again for trying to help

(callihn) #4

I see you solved your problem, but I’ll add this anyway since it may help someone smart enough to use the search function.

Check your light entities, I once managed to duplicate every light entity I had in my map without my knowledge and then I started getting that error.

If that’s not it and you can’t find out why it’s eating more memory you can also use -lomem in your compile string, but it will make your compiles longer.

It might also be a good time to mention that the Q3Map3 bounce code has a bug in it, which was only recently addressed in Q3Map2 2.5.17, so if your using bounce in your lighting phase then grabbing the latest Q3Map2 should help some also.