Hey,
> Looking at device.c in Parted, that’s probably the right thing because
> PedDevice objects are kept in a linked list whose head is stored in the
> ‘devices’ global variable of device.c. So you cannot just free them
> asynchronously from a finalizer thread because they might still be
> ac
Hi,
Mathieu Othacehe skribis:
> I tested it out and I had several SCM pointers encapsulating the same
> libparted C pointer, thus multiple finalizers on the same underlying C
> pointer.
Yes, that’s the idea I tried to convey.
> Anyway, here is a patch that solves the issue by removing the devi
Hey,
I ran further tests and my understanding is that the weak hash-table /
finalizer mechanism is not compatible with a C function that can return
multiple times the same allocated object.
Even if we were to introduce a set-pointer-unique-finalizer! procedure
that calls scm_i_set_finalizer inst
Hola,
> Finalizers are set on pointer objects, so they’re invoked when the
> pointer object goes out of scope. But:
>
> (eq? (make-pointer 123) (make-pointer 123))
> => #f
I agree, but somehow this works:
--8<---cut here---start->8---
scheme@(guile-user)
Hi Mathieu,
Mathieu Othacehe skribis:
> I made some progress on that one. I think, this is what's going on:
>
> 1. Two new PedDevice A and B are malloc'ed by the libparted when opening
> the installer partitioning page.
>
> 2. They are added to the %devices weak hash table by pointer->device!
>
Hey,
I made some progress on that one. I think, this is what's going on:
1. Two new PedDevice A and B are malloc'ed by the libparted when opening
the installer partitioning page.
2. They are added to the %devices weak hash table by pointer->device!
and their respective finalizers are registered
Hey,
Thanks for your help :)
> 1. Bindings create wrappers for C pointers—e.g., with
> ‘pointer->device’. If several C functions return a pointer P, you
> must make sure to return always the same wrapper and not create a
> new one.
Agreed.
>
> ‘pointer->device!’ attempt
Hi!
Mathieu Othacehe skribis:
>> ‘pointer->device!’ attempts to do that but I think it’s bogus: it
>> uses a weak-value hash table, where the value is the wrapper. So
>> if the wrapper disappears before the underlying C object, then the
>> pointer is called and bad things en
Hi,
Mathieu Othacehe skribis:
> null! I guess this has to deal with device pointer finalizers. I'm a bit
> disappointed because I thought we had overcome those mistakes.
There are several things we should audit in Guile-Parted regarding
object lifecycles.
Common issues when writing bindings th
Hello,
I found a segfault in the installer by running those steps:
- Run an automatic partitioning with separate home and no encryption
- In the final configuration page, come back to partitioning
- Remove all partitions but the ESP one, create a new btrfs root
- partition
- Repeat until the cr
10 matches
Mail list logo
