Re: g-wrap: devel branch - 6 patches

[David Kastrup]

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 <address@hidden> 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