bug#19883: Correction for backtrace

[Ludovic Courtès]

David Kastrup <address@hidden> skribis:

> address@hidden (Ludovic Courtès) writes:
>
>> David Kastrup <address@hidden> skribis:

[...]

>>> It would not help since many of the references are stored in STL
>>> containers (like std::vector <Grob *>) which have their data
>>> allocated/deallocated separately from the memory area of the
>>> structure itself.
>>
>> Oh, OK.  Still, I don’t think this is a problem because each C++
>> object has a corresponding SMOB, and said SMOB is GC-protected; thus
>> the C++ object itself is also GC-protected until the SMOB is
>> unprotected.
>
> The code given in test.cc is representative for LilyPond: most of the
> C++ objects refer to other C++ objects via pointers, and the protection
> of SMOB and C++ objects is managed through the mark callbacks.  Complex
> C++ objects contain their own SCM value as part of the Smob base class.
> Simple C++ objects (derived from Simple_smob) don't and are only
> optionally managed by GUILE.

I don’t think this contradicts what I wrote above, does it?

>> Here’s the patch I’ve ended up with:
>>
>> diff --git a/smobs.hh b/smobs.hh
>> index 3701280..a41a645 100644
>> --- a/smobs.hh
>> +++ b/smobs.hh
>> @@ -263,6 +263,20 @@ private:
>>  protected:
>>    Smob () : self_scm_ (SCM_UNDEFINED), protection_cons_ (SCM_EOL) { };
>>  public:
>> +  static void *operator new (std::size_t size)
>> +  {
>> +    /* This C++ object is referred to by the corresponding SMOB, which is
>> +       itself GC-protected.  Thus, no need to protect the C++ object.  */
>> +    return scm_gc_malloc (size, "lily-smob");
>> +  }
>> +
>> +  static void operator delete (void *thing)
>> +  {
>> +    /* Nothing to do: the GC will reclaim memory for THING when it deems
>> +       appropriate.  */
>> +    // printf ("delete %p\n", thing);
>> +  }
>> +
>
> As I stated: this will not help with STL containers which are
> extensively used in pretty much every data structure of LilyPond.

Sorry, I don’t understand how it doesn’t help.

It would be a problem is ‘Smob’ objects could be copied, thus ending up
in non-GC-scanned storage, but IIUC they cannot be copied because their
copy constructor is private.

What am I missing?

At any rate, I don’t see any failure with the test program.

>> I think it would help to get everyone involved on both sides.  Thus,
>> could you Cc: this bug report to the LilyPond developer list, or the
>> corresponding LilyPond bug report?  This is really important to me.
>
> Shrug.  I'll put a link to this bug report to a suitable LilyPond issue.

Thank you.  Though I want other LilyPond developers to get involved, and
I’m afraid it would be easy for them to just ignore a side bug report.

It’s a vital task for LilyPond, it cannot be a one-person side-project
on the LilyPond side.

Thanks in advance,
Ludo’.