[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: VirtualBox Hangs Pre-Init Due To Ext2FS Fault
From: |
Richard Braun |
Subject: |
Re: VirtualBox Hangs Pre-Init Due To Ext2FS Fault |
Date: |
Sat, 27 Jun 2015 19:34:46 +0000 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
On Sat, Jun 27, 2015 at 03:39:58PM +0100, James Clarke wrote:
> I have been suffering a lot from my Hurd system (running in VirtualBox)
> hanging at startup, just after "Hurd server bootstrap..." but before "INIT:
> version 2.88 booting".
>
> I have been able to trace it back to getblk.c:248 (unsigned long
> addr_per_block = EXT2_ADDR_PER_BLOCK (sblock);) in ext2_getblk. It faults
> because sblock is NULL.
>
> I have traced the execution with debugging statements, and what seems to
> happen is as follows:
>
> 1. diskfs_remount is called (because root is remounted as rw)
> 2. RPCs are inhibited
> 3. diskfs_reload_global_state is called
> 4. sblock is set to NULL
> 5. While this is happening, ext2_getblk is called
>
> If you’re lucky, the superblock is read and sblock is set to point to this
> data before 5 (or at least before it gets to dereferencing sblock). If not,
> sblock is still NULL and thus a page fault is raised, causing the system to
> be stuck.
>
> Does anyone have an idea how this situation could be occurring?
My initial thought would be "how could it not happen ?".
Despite diskfs_remount calling ports_inhibit_class_rpcs, other threads
can very well be running to process previously received messages. There
seems to be no other form of access synchronization such as locks in
diskfs_reload_global_state.
Can you get the call trace leading to ext2_getblk ? I'm not sure about
backtrace(3) in static executables but it might be worth trying.
--
Richard Braun