Not posted to guile-dev as I am banned from posting there. Feel free to forward any of it yourself, particular when you find some new information to report.
David Pirotte <[email protected]> writes: > Hello, > > I worked on and pushed the following patches on the devel branch: > > aac9ebf * fix make distcheck - manual review final touches > 8445aed * deleting doc/.gitignore - updating .gitignore > 65c9d6a * fixing all Makefile.am - use $(GUILE), not guile > > and merged the following from master: > > 99b08dd * auto merging with master - appying 2 patches from andy > -> 7f13e15 * No free/mark on WCT objects, and remove use of scm_gc_free > -> d7af62a * Require Guile 2.0; allow Guile 2.2 > > See here for details: > > http://git.savannah.gnu.org/cgit/g-wrap.git/?h=devel > > Within the next few days, unless someone tells me it's not a good > idea, and why of > course :), I will prepare for 1.9.15, merge to master, tag, update the > webpages and > release. I'd be interested in * guile/g-wrap/guile-wct.c (do_free_wcp, gw_wcp_set_dependencies): Don't scm_gc_free, as this was causing corruption. (wct_data_free, wct_data_mark): Remove. WCT objects don't need these. To me this sounds suspiciously like an occurence of <URL:http://debbugs.gnu.org/cgi/bugreport.cgi?bug=19883>. Could you use -- C Macro: scm_t_bits SCM_SMOB_FLAGS (SCM obj) Return the 16 extra bits of the smob OBJ. No meaning is predefined for these bits, you can use them freely. -- C Macro: scm_t_bits SCM_SET_SMOB_FLAGS (SCM obj, scm_t_bits flags) Set the 16 extra bits of the smob OBJ to FLAGS. No meaning is predefined for these bits, you can use them freely. in order to put a flag on a smob when it has been freed, and let your mark routine check for this flag and return without action when this is the case? The core SMOB itself is likely still in working order even though everything you allocated yourself is already gone. The reported bug shows itself by calling the "mark" hook even after the "free" hook has been called. Activity on the bug report indicates that even reporting this upstream is not much of a priority. If your corruption can be fixed by this sort of flag action, it would mean that GUILE could at least use a similar strategy internally for avoiding to trigger this bug (likely clearing out the type field of the SMOB when freeing it in order to detach it from the type-specific tables). Data corruption when using documented interfaces is a pretty serious drawback, so if you could provide another data point, it might lead to actual measures getting taken for the sake of other application, even if you have been able to work around the problem in a different way yourself. Thanks -- David Kastrup _______________________________________________ g-wrap-dev mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/g-wrap-dev
