[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#36402: installation error
From: |
Ludovic Courtès |
Subject: |
bug#36402: installation error |
Date: |
Thu, 27 Jun 2019 23:08:00 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) |
Hi Juan,
Juan <address@hidden> 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’.