[packagefs] page fault during mount

[anevilyak]

While asking haikuporter to download and enter the chroot for gcc 4.8.2 (on a gcc4 primary Haiku), I encountered the following panic:

PANIC: vm_page_fault: unhandled page fault in kernel space at 0x4, ip 0x800f24fe

Welcome to kernel debugging land...
Thread 2015 "mount" running on CPU 5
stack trace for thread 2015 "mount"
kernel stack: 0x9cf01000 to 0x9cf05000
user stack: 0x71789000 to 0x72789000

[... int_bottom -> panic lines snipped]
kernel iframe at 0x9cf04ae4 (end = 0x9cf04b3f)
eax 0x9baf96c0 ebx 0x9baf96c0 ecx 0x0        edx 0x0
esi 0x0        edi 0x9c62c488 ebp 0x9cf04b34 esp 0x9cf04b18
eip 0x800f24fe eflags 0x13282
vector: 0xe, error code: 0x2
10 9cf04ae4 (+   80) 800f2f4e   <kernel_x86> list_remove_link + 0x0b
11 9cf04b34 (+   32) 80124840   <kernel_x86> unload_driver_settings + 0xb0
12 9cf04b54 (+   32) 80124dc4	<kernel_x86> delete_driver_settings + 0x0e
13 9cf04b74 (+  176) 81998aef	<packagefs> Volume<0x9c62c488>::Mount(char const*: 0xb085fdb0 "type system") + 0x929
14 9cf04c24 (+   48) 81982b5e	<packagefs> packagefs_mount(fs_volume*: 0xdd455a98, char const*: 0x0 "<NULL>", uint32: 0x0 (0), char const*: 0xb085fdb0 "type system", long long*: 0x9cf04cdc) + 0x4c
15 9cf04c54 (+  416) 800d6ea8	<kernel_x86> fs_mount(char*: NULL, char const*: 0xb085fdb0 "type system", char const*: 0x0 "<NULL>", uint32: 0x8193cca6, char const*: 0x9bc13000 "boot", false) + 0x789
16 9cf04df4 (+  336) 800db12d	<kernel_x86> _user_mount + 0x1ed
17 9cf04f44 (+  100) 8011136f	<kernel_x86> handle_syscall + 0xdc
user iframe at 09xcf04fa8 (end = 0xx9cf05000)
eax 0x60       ebx 0x1716dcc  ecx 0x7278896c edx 0x61dae114
esi 0x0        edi 0x727895a2 ebp 0x72788998 esp 0x9cf04fdc
eip 0x6adae114 eflags 0x3202            user esp 0x7278896c
vector: 0x63, error code: 0x0
18 9cf04fa8 (+    0) 6adae114	<commpage> commpage_syscall + 0x04
19 72788998 (+  208) 01d38b35	<_APP_> main + 0x2bd
20 72788a68 (+   56) 01d3876c	<_APP_> _start + 0x50
21 72788aa0 (+   48) 0187c918   </boot/system/runtime_loader@0x0186f000> <unknown> + 0xd918
22 72788ad0 (+    0) 6adae250	<commpage> commpage_thread_exit + 0x00

I haven't encountered this one previously, and wasn't certain as to what information would be useful to additionally grab out of KDL at this point. In any case, this was the first invocation of porter from a first boot of a new build (hrev46798), with no other apps running other than the services started at boot. Please advise what additional information would be of use if encountered again. If helpful, the invocation of haikuporter was simply haikuporter --no-dependencies -E gcc.

[bonefish]

This looks an issue with the driver settings implementation. The packagefs code is pretty straight forward: It gets a driver settings handle via ​parse_driver_settings_string() and uses an ​auto deleter to destroy it. The implementation of ​unload_driver_settings() doesn't look right. settings_handle::ref_count isn't initialized by parse_driver_settings_string() and the two alternatives of either removing the settings from the list (which should only contain actual driver settings) or not freeing them at all doesn't seem right anyway.

[anevilyak]

Will try to look into this sometime in the next week, hit it several times while building packages over the weekend.

[waddlesplash]

Rene: any update? Did you investigate it?

[pulkomandy]

Fixed in hrev48676.