unofficial mirror of bug-guix@gnu.org 
 help / color / mirror / code / Atom feed
From: "Ludovic Courtès" <ludo@gnu.org>
To: Mathieu Othacehe <m.othacehe@gmail.com>
Cc: 36402@debbugs.gnu.org, Juan <r5jm@protonmail.com>
Subject: bug#36402: installation error
Date: Tue, 03 Sep 2019 11:13:26 +0200	[thread overview]
Message-ID: <87woepyc7d.fsf@gnu.org> (raw)
In-Reply-To: <87imqbgh71.fsf@gmail.com> (Mathieu Othacehe's message of "Mon, 02 Sep 2019 11:50:42 +0200")

Hello,

Mathieu Othacehe <m.othacehe@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’.

  reply	other threads:[~2019-09-03  9:14 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-27  1:47 bug#36402: installation error Juan
2019-06-27 21:08 ` Ludovic Courtès
2019-06-29 15:47   ` Mathieu Othacehe
2019-07-02 13:25     ` Ludovic Courtès
2019-08-31 18:43   ` Mathieu Othacehe
2019-09-01 19:55     ` Ludovic Courtès
2019-09-02  9:50       ` Mathieu Othacehe
2019-09-03  9:13         ` Ludovic Courtès [this message]
2019-09-04 12:31           ` Mathieu Othacehe
2019-09-05  8:32             ` Ludovic Courtès
2019-09-05 13:53               ` Mathieu Othacehe
2019-09-08 19:35                 ` Ludovic Courtès
2020-03-18 17:56                   ` Mathieu Othacehe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87woepyc7d.fsf@gnu.org \
    --to=ludo@gnu.org \
    --cc=36402@debbugs.gnu.org \
    --cc=m.othacehe@gmail.com \
    --cc=r5jm@protonmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).