Something changed in the compiler - and I like it!

General
1

This week I decided to get a project up and running that I hadn’t worked on since August of last year. I fired up the Odin compiler and it wouldn’t compile due to init functions now needing "contextless" and some allocations in the global scope not working any more because the global context has been removed.

Additionally, there were a bunch of deprecation warnings that strconv.atoi and atof were deprecated.

I managed to fix the errors and get my program running, but then I started getting segfaults from nil pointer dereferences and other pointer operations failing.

Obviously, this was a total pain and I just wanted to get my code up an running!

I spent a long time debugging, and realised that my memory management was completely broken. Stuff was being accessed / rendered that had been deleted / cleaned up already, and my whole approach to memory management was garbage. I added some print statements and compiled with the earlier compiler version and the bugs were there all along, but the way the compiler handled the cleaned up data was different.

In the old version, the deleted data was still intact but just removed from the list, but it seems that at some point (maybe October) it changed so that it was zeroed out / poisoned. I think it might have been unordered_remove that had changed.

In the end I had to make the following changes to get it working:

  • Completely reworked my memory management so that it wasn’t insane / broken
  • Changed all of the atoi / atof to the new parse_int and parse_f32 functions
  • Removed a lot of @(init) functions and turned them into normal functions, called during startup
  • Removed a bunch of unnecessary makes of empty hash tables etc.

I’m actually really pleased with this. Obviously having memory management that doesn’t suck is great. But also, the new strconv functions are much better and return a boolean to say if they actually worked and have better names so this is a massive improvement. And the global context stuff makes a lot of sense, and I got rid of some very lazy implementations in my program and improved the way it starts up.

Also, in my memory management I started poisoning things when I clean them up (they are statically allocated and still in memory) so I actually learned a really good lesson from this change.

So overall, I just wanted to say I’m very happy with the direction the compiler is going! At first these changes seemed like a total pain, but all of them made my program better and made it easier to find obscure bugs.

So thanks!

8 Likes
2

Same thing happened to me around October. I had a program that on subsequent runs would pick up old memory with corrupted data. I posted about it, then a week or 2 later, that program wouldn’t even run. Turns out the program had many instances of bad memory management of dynamically allocated strings. I’m thankful for the slap in the face. Forced me to learn better habits. Seems a change did happened around that time.

Since then, I started using the the memory tracking utilities in core:mem as part of my testing/debugging to make sure I’m not doing anything overly stupid with memory.

https://zylinski.se/posts/introduction-to-odin/#tracking-memory-leaks

That tracker is a little out of date. To get a list of bad frees, the default to panic on bad free must be overridden with the following:

track.bad_free_callback = mem.tracking_allocator_bad_free_callback_add_to_array
3 Likes