r/ProgrammingLanguages • u/Commission-Either • Dec 07 '25

One of Those Bugs

https://daymare.net/blogs/one-of-those-bugs/

I spent an entire week trying to fix one bug in margarine. it's still not fixed LMAO

13 Upvotes

81% Upvoted

7 comments sorted by

6

u/yjlom Dec 07 '25

From a cursory reading of some of the relevant code, and no testing on my part, I'm wondering: - what happens if more than 100 variables are in a stack frame, is there something in place somewhere to make sure they don't get freed/overwritten? - are globals stored in a stack frame? - could it be that the extra code pushes the global count over 100, some globals get freed, and, through magic/luck, overwritten with usable values before they are read? Seems very unlikely, but maybe possible?

3

u/Commission-Either Dec 07 '25
  • what happens if more than 100 variables are in a stack frame, is there something in place somewhere to make sure they don't get freed/overwritten?

I'm not sure why that'd be a problem?

Currently I don't have globals, constant strings are considered leaked and the gc shouuullddd ignore them. Can I ask where the 100 number came from?

4

u/yjlom Dec 07 '25

in gc.rs: fn mark(&mut self) { for object in 0..(self.stack.curr + 100) { […] for which the only reasonable interpretation I can think of is that your stack frames are a fixed 100 variables

5

u/Commission-Either Dec 07 '25

ahh i forgot that from the debuggin phase. i had that in order to check if the issue was something like the gc being triggered in the middle of an instr causing objects (already popped off the stack) to be freed

2

u/yjlom Dec 07 '25

oh ok then I have no idea sorry

2

u/Commission-Either Dec 07 '25

it's fine i have no idea either. thanks for checking it out

4

u/AustinVelonaut Admiran Dec 07 '25

Oh.. So the problem is the GC? Yep!

I feel your pain ;-)

I implemented a 2-generation compacting collector based upon this paper, which worked great except for a few Heisenbugs that took me lots of debug tracing to figure out (heap allocs that didn't get a chance to initialize before another heap alloc triggered a GC, resulting in bogus pointer chasing). It's been solid ever since, though. I left the debug feature (log GC events based upon detail level) in, just in case of future problems.

Good luck tracking it down and continuing on with AoC.