fix some gc rooting

[carnaval]

found those while poking around. One is a staged function issue, the other is related to precompilation so probably not well tested.

[IainNZ]

Curious from someone who doesn't know much about the GC: does a missing "GC root" just lead to memory leaks, or can nastier things happen if something isn't rooted?

[elextr]

A missing root can mean memory can be unexpectedly freed, resulting in dangling pointers and probably comes in your "nastier things" category.

[tkelman]

this should be a semicolon

[timholy]

@IainNZ, a GC root protects a given variable from being garbage collected. If you don't root something, then

x = do_something();      // this allocates a new variable
y = do_something_else(); // also allocates memory
z = combine_x_and_y(x,y);

can cause x to go "poof" before that call to combine. So the pattern is to protect x and y from collection during intermediate computations; once the final result is ready, then JL_GC_POP() removes that protection.

[IainNZ]

Oh wow thats bad, for some reason I thought it was inverse, as you can tell from my wording (i.e. that it'd never be collected). So basically wherever these are missed its basically luck that the GC didn't get called?

[elextr]

So basically wherever these are missed its basically luck that the GC didn't get called?

Yes.

[IainNZ]

Wouldn't it be worth running the GC all the time then to flush out the bugs? Not on commits going forward necessarily, but right now to retroactively fix bugs? (sorry for all the questions!)

[tkelman]

@IainNZ see some discussion on exactly that idea at #11151 (comment)

[elextr]

Running the GC more often may help to find such problems, but it is no guarantee, using the example @timholy gave above, even if the unrooted memory is freed before the combination step, if it hasn't been re-allocated and its value still exists, then combination may give the right answer even though the memory has been freed. But a different scenario may see it re-allocated and its value changed, so combination will give the wrong answer.

Welcome to debugging memory management :)

[yuyichao]

@elextr In this case, would clearing out the memory being freed or fill in some invalid pointer values help exposing/tracking down those problems? It will probably have a even bigger impact on the performance but I guess shouldn't be much worse than an always-full-gc approch...

[JeffBezanson]

We do that with MEMDEBUG enabled. And I have definitely resorted to increasing GC frequency to try to find bugs. In extreme cases, you can do a collection after every allocation.