GNU bug report logs - #36402
Installer: null pointer exception during partitioning

Previous Next

Full log

Message #14 received at 36402 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Juan <r5jm <at> protonmail.com>
Cc: Mathieu Othacehe <m.othacehe <at> gmail.com>, 36402 <at> debbugs.gnu.org
Subject: Re: bug#36402: installation error
Date: Thu, 27 Jun 2019 23:08:00 +0200

Hi Juan,

Juan <r5jm <at> 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’.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.