Re: Define operator new/delete for smobs (issue 551390047 by address@hidden)

[hanwenn]

On 2020/01/25 12:50:15, hanwenn wrote:
> On 2020/01/25 12:37:32, dak wrote:
> > That seems weird for me.  The topic states "this provides a way to
run
> LilyPond
> > with Guile 2.2" but garbage collection with Guile 2.2 works out of
the box
> > already.  This patch only causes extra work and will slow down
garbage
> > collection further.
> > 
> > The only way in which it could make sense is if in return some other
GC hooks
> > and/or work would be disabled.
> 
> running against
> 
> $ guile2.2 --version
> guile (GNU Guile) 2.2.4
> 
> I get 
> 
> Import (ice-9 threads) to have access to `call-with-new-thread'.
> Import (ice-9 threads) to have access to `current-thread'.
> Processing `input/regression/mozart-hrn-3.ly'
> Parsing...double free or corruption (!prev)
> 
> Thread 5 "lilypond" received signal SIGABRT, Aborted.
> [Switching to Thread 0x7fffeea92700 (LWP 31206)]
> 0x00007ffff7526e35 in raise () from /lib64/libc.so.6
> Missing separate debuginfos, use: dnf debuginfo-install
> guile22-2.2.4-3.fc30.x86_64 libunistring-0.9.10-5.fc30.x86_64
> (gdb) up
> #1  0x00007ffff7511895 in abort () from /lib64/libc.so.6
> (gdb) 
> #2  0x00007ffff756a08f in __libc_message () from /lib64/libc.so.6
> (gdb) 
> #3  0x00007ffff757140c in malloc_printerr () from /lib64/libc.so.6
> (gdb) 
> #4  0x00007ffff75731bc in _int_free () from /lib64/libc.so.6
> (gdb) 
> #5  0x00000000004dd2c4 in Simple_smob<Input>::free_smob
(obj=<optimized out>) at
> /usr/include/c++/9/bits/basic_string.h:2300
> 2300        c_str() const _GLIBCXX_NOEXCEPT
> (gdb) 
> #6  0x00007ffff7b8b4a5 in GC_invoke_finalizers () at finalize.c:1216
> 1216          (*(curr_fo -> fo_fn))((ptr_t)(curr_fo -> fo_hidden_base),
> (gdb) down
> #5  0x00000000004dd2c4 in Simple_smob<Input>::free_smob
(obj=<optimized out>) at
> /usr/include/c++/9/bits/basic_string.h:2300
> 2300        c_str() const _GLIBCXX_NOEXCEPT
> (gdb) quit

we could make this conditional on GUILEV2 obviously.

Unfortunately, we can't as yet get rid fo the mark functions, because we
need a vector with a custom allocator first (Grob_array!).



https://codereview.appspot.com/551390047/