Hello, Mathieu Othacehe <m.othac...@gmail.com> skribis:
>> It might be useful to add calls to ‘gc’ here and there in the tests to >> stress-test memory management. > > Inserting gc calls here: > > (test-assert "partition-remove extended" > (with-tmp-device > "device-extended.iso" > (lambda (new-device) > (let* ((device (get-device new-device)) > (disk (disk-new device)) > (partitions (disk-partitions disk)) > (extended-partition (find extended-partition? partitions))) > (gc) ; <-- Try to destroy disk? > (disk-remove-partition* disk extended-partition) > (gc) > (equal? (extended-partition-count disk) 0))))) > > causes a segfault. Is it legal to call GC here? Do you have any clue on > how to investigate what the GC is doing? GC might run at any time, so yes, it’s valid to insert calls to ‘gc’ anywhere. So this is good, this is kind of issue we want to catch. :-) To investigate, I would recommend re-reading how memory management works in Parted. Questions such as: 1. Can Parted free a C object (disk, partition, etc.) behind your back? Is there a way to prevent it? 2. When a Parted object aggregates another object, how’s memory managed? For example, if a “disk” aggregates (refers to) a “partition”, who’s responsible for freeing that partition? 3. Relatedly, if, say, a “disk” aggregates a “partition”, do you make sure on the Scheme side that you do not free the partition while the disk is still alive? You can make sure this doesn’t happen by using a weak-key hash table, as discussed before, where the key is the disk and the value is the list of partitions it aggregates. If you can get a backtrace from the core dump, that might give clues. Setting the environment variable: export GLIBC_TUNABLES=glibc.malloc.check=1 might tell you if it’s a double-free error or something. You can also use Valgrind though libgc creates a lot of noise there. Please share whatever you gather before you get depressed. ;-) HTH! Ludo’.