@mflatt hmm…it doesn’t seem to segfault when I require the module in many different places.

I am a bit confused by the docs for scheme_add_managed, which says: “Independent of whether strong is zero, the value o is initially weakly held”, right after saying that o will be strongly held (given a non-zero value for strong).

Like, I don’t know when it goes from weakly held to strongly held, but maybe that’s when the GC is getting it?

Yes, the value is weakly held until it would otherwise be GCed, and then it becomes strongly held.

I’m confused about your messages from yesterday. You seem to be saying that “having custodian manage the proc that calls close” looks like it works, except that it seg faults… I don’t think that would work, and maybe you’re now getting to the same conclusion

Oh, I mean the link I sent yesterday doesn’t work, but based on reading the docs, it seems like it should, so I’m probably misunderstanding something.

Because when I run raco setup video, I get a segfault when building the docs. However, if I run either of the files directly, or even have scribble output docs from the scribble file, nothing crashes. So I suspect that something with the way raco setup is calling the files is exposing the error.

If that makes any sense.

@mflatt Also, your explanation of when it goes from weak to strong makes sense. Do you mind if I add that explanation to the docs?

@leif The doc improvement is welcome

@mflatt Okay, PR made. As for the sample I linked to yesterday (https://github.com/LeifAndersen/racket-video/blob/segfault/video/init.rkt), I take it that nothing looks immediately wrong?

(At this point I’m just trying to get a closure reliably to scheme_add_managed_close_on_exit)

I’m not convinced that it works to keep a weak reference to the procedure – even one that becomes strong later, due to interactions among weak references. Was there some reason not to pas the function as the last argument to scheme_add_managed_close_on_exit, instead?

Oh, that didn’t work either, one moment and I’ll get the code for that.

I take it the last argument becomes strong immediately?

@mflatt Okay, I originally had this: (scheme_add_managed_close_on_exit #f free-proc free-proc (_function-ptr free-proc (_fun _racket _pointer -> _void)))

Where I used _function-ptr to give the free-proc as the last argument.

I also tried having the second argument as #f rather than free-proc. At that point I stopped because it became clear to me I was missing something.

Oh, and rather than using _function-ptr, I also tried using cast.

Declare scheme_add_managed_close_on_exit to expect a _racket instead of a _pointer

You don’t want the underly C pointer; you want the Racket-level closure

Ah, okay, that would make sense, I’ll give that a shot.

@mflatt WOW, thanks. That worked. Now to see if I can actually bring that into a bigger example. Thanks again. :smile:

@mflatt Hmmph…still segfaults on the larger example. It wouldn’t surprise me if I have a race condition somewhere, but just in case: https://github.com/LeifAndersen/racket-video/blob/larger-segfault/video/private/init-mlt.rkt#L108

I’m now calling it with: (scheme_add_managed_close_on_exit #f #f free-proc free-proc) And free-proc is using other module-level variables.

@mflatt Okay, I think I have a good working hypothesis, and I want to know what you think:

1. The free proc is defined in GCable memory, and unless otherwise specified the GC will collect it before we call it.
2. So the way we prevent it from being collected is by adding it to custodians.
3. However, the custodians will only protect it as long as they are around. Normally this is okay, except in the last case.
4. Because this procedure also calls the callback on exit (in addition to all of the custodians), the procure will be called after all custodians have been removed, thus the GC could have removed the procedure.

Does that sound remotely correct?

leif: The custodian stays around until the on-exit callbacks are done, so I don’t think that’s it

Ah, rats, okay, thanks anyway. I’ll keep looking around. I do appreciate all the feedback you’ve been giving me, thank you.