Quoting bulia byak <buliabyak@...400...>:
When I open fill&stroke without loading any document (no crash), ~SPDocument is not called. When I do it after loading something, then _after_ I press ctrl+shift+f but before the crash, it destroys the empty document (uri == NULL, base == NULL, name == "New document 1") that was created on launch and then replaced by the loaded one.
Ahh, ok. This makes sense to me now. I was worried it was something exotic.
I don't know why this destroying happens not when the empty document is really killed, but when I run fill&stroke after that.
It's because SPDocument is now managed by the collector, and there object destruction happens non-deterministically[1]. It just happens that running fill and stroke usually triggers a garbage collection pass (and therefore destruction of the lingering SPDocument) for you.
Now, that doesn't explain why SPDocument's destructor crashes, which is the real problem. Probably I screwed up SPDocument's initialization/finalization logic when I re-munged it into the new framework, or it's possible that the code getting called in a different context has exposed an existing bug. I'll look into it more tonight as I have time.
Long-term, we do still want to minimize the use of automatic finalizers as much as possible[2].
-mental
[1] From the point of view of an application programmer, anyway. This isn't special to libgc, but a behavior common to most automatic garbage collectors. A Java programmer (hi Jon!) will be familiar with this kind of thing.
[2] This is also considered best practice in languages like Java; there are well-developed techniques for doing this.