From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ludovic =?UTF-8?Q?Court=C3=A8s?= Subject: bug#36402: installation error Date: Tue, 03 Sep 2019 11:13:26 +0200 Message-ID: <87woepyc7d.fsf@gnu.org> References: <87lfxmu47j.fsf@gnu.org> <878sr989br.fsf@gmail.com> <87a7bnaj0b.fsf@gnu.org> <87imqbgh71.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:60188) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i54t1-0005tD-2U for bug-guix@gnu.org; Tue, 03 Sep 2019 05:14:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1i54sz-0007Dz-WD for bug-guix@gnu.org; Tue, 03 Sep 2019 05:14:03 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:50487) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1i54sz-0007Dt-SF for bug-guix@gnu.org; Tue, 03 Sep 2019 05:14:01 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1i54sz-0002DO-Kh for bug-guix@gnu.org; Tue, 03 Sep 2019 05:14:01 -0400 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <87imqbgh71.fsf@gmail.com> (Mathieu Othacehe's message of "Mon, 02 Sep 2019 11:50:42 +0200") List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: "bug-Guix" To: Mathieu Othacehe Cc: 36402@debbugs.gnu.org, Juan Hello, Mathieu Othacehe skribis: >> It might be useful to add calls to =E2=80=98gc=E2=80=99 here and there i= n 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=E2=80=99s valid to insert calls to =E2= =80=98gc=E2=80=99 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=E2=80=99s memory managed? For example, if a =E2=80=9Cdisk=E2=80=9D aggregates (refers = to) a =E2=80=9Cpartition=E2=80=9D, who=E2=80=99s responsible for freeing tha= t partition? 3. Relatedly, if, say, a =E2=80=9Cdisk=E2=80=9D aggregates a =E2=80=9Cpar= tition=E2=80=9D, 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=E2=80=99t 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=3Dglibc.malloc.check=3D1 might tell you if it=E2=80=99s 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=E2=80=99.