From: "Ludovic Courtès" <ludo@gnu.org>
To: Juan <r5jm@protonmail.com>
Cc: Mathieu Othacehe <m.othacehe@gmail.com>, 36402@debbugs.gnu.org
Subject: bug#36402: installation error
Date: Thu, 27 Jun 2019 23:08:00 +0200 [thread overview]
Message-ID: <87lfxmu47j.fsf@gnu.org> (raw)
In-Reply-To: <wWdteTLTUnxVX5pRpeceVgWYy_OZ39lObX0cx9myYTbL9YOVOv3zJ7Mj6kXszbwI5-IxhGglrmg-gIuEtzMGefejvXedlqOLDf04AIW4HB8=@protonmail.com> (Juan's message of "Thu, 27 Jun 2019 01:47:51 +0000")
Hi Juan,
Juan <r5jm@protonmail.com> skribis:
> I ran into some trouble while attempting to install Guix SD (1.0.1.x86_64). It happens when I try to do the guided graphical installation, I'll transcript the whole text here:
[...]
> 755:33 14 (run-partitioning-page)
> In ./gnu/installer/parted.scm:
> 1010:14 13 (auto-partition! #<<disk> bytestructure: #<bytestructure 0x106d840>> #:scheme _)
> 870:21 12 (loop _ _ _)
> 863:17 11 (loop _ 2617712816 1289318400)
> 771:25 10 (mkpart #<<disk> bytestructure: #<bytestructure 0x106d840>> _ #:previous-partition _)
> In parted/structs.scm:
> 552:19 9 (pointer->partition _)
> 132:3 8 (pointer->bytestructure #<pointer 0x0> #<bytestructure-descriptor 0x29f4740>)
> In unknown file:
> 7 (pointer->bytevector #<pointer 0x0> 88 #<undefined> #<undefined>)
> In ice-9/boot.scm:
> 751:25 6 (dispatch-exception 5 null-pointer-error ("pointer->bytevector" "null pointer dereference" () ()))
That looks like what was reported at
<https://issues.guix.gnu.org/issue/35858>, so I’ve merged both. Thanks
for the report, Juan!
Mathieu, in the same spirit as
<https://issues.guix.gnu.org/issue/35783>, I think we have an object
life cycle and memory management issue.
I hadn’t noticed but we’re doing manual memory management by calling
things like ‘disk-destroy’ in the installer. That’s crash-prone and
best avoided.
The usual way to handle it in bindings is by:
1. Adding pointer finalizers. So for example the pointer object
associated with a <disk> record would have a finalizer that calls
‘ped_disk_destroy’.
2. Having a weak-key hash table to track object dependencies when
needed. So, if a <device> aggregates a <disk>, there must be an
entry in the hash table that maps the <device> to the <disk>. That
way, we ensure that the <disk> object remains live as long as the
<device> is live.
We can expose “close” functions that free OS resources such as file
descriptors, but we should not expose deallocation functions like
‘ped_disk_destroy’; instead, we let the GC call them when the objects
become unreachable.
Does that make sense?
I think we should audit and adjust Guile-Parted in that spirit. WDYT?
Thanks,
Ludo’.
next prev parent reply other threads:[~2019-06-27 21:09 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 [this message]
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
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=87lfxmu47j.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).