[runtime_loader] crashes on double click

[diver]

This is Haiku.PM d20975d.

Terminal output:

~> /boot/system/runtime_loader
runtime_loader: /boot/system/runtime_loader: Could not find .comment section
runtime_loader: /boot/system/runtime_loader: Failed to get gcc version.
Kill Thread

[bonefish]

Doesn't seem to be PM specific.

[bonefish]

The cause of the crash is that the runtime loader looks just like a regular executable -- and thus it can be loaded without problems -- but its entry function expects different parameters than a regular executable. The only solution I can think of is to add an explicit check whether the executable is the runtime loader. Given that there's no harm done by running and crashing the runtime loader, I don't think this is worthwhile.

[vrkosk]

I suspect there's something else going on here. I got the same crash, but it resulted in complete system hang and KDL. Steps to reproduce:

1. Download the hrev48882 VMware disk image and run it in VMware Workstation 10.
2. Compile Haiku from the sources (the usual way, hybrid build).
3. Build the es1370 driver (jam -q es1370).
4. Double click on the es1370 object file (generated.x86gcc2/objects/haiku/x86_gcc2/release/add-ons/kernel/drivers/audio/ac97/es1370/es1370).

This results in the following output in the serial port (luckily I had logging on):

runtime_loader: /Haiku-git/haiku/generated.x86gcc2/objects/haiku/x86_gcc2/release/system/kernel/kernel.so: Could not find .comment section
runtime_loader: /Haiku-git/haiku/generated.x86gcc2/objects/haiku/x86_gcc2/release/system/kernel/kernel.so: Failed to get gcc version.
PANIC: page fault, but interrupts were disabled. Touching address 0x00000000 from ip 0x023dd49e

Welcome to Kernel Debugging Land...
Thread 56488 "es1370" running on CPU 6
stack trace for thread 56488 "es1370"
    kernel stack: 0x81224000 to 0x81228000
      user stack: 0x71835000 to 0x72835000
frame               caller     <image>:function + offset
 0 81227e50 (+  32) 80142d4e   <kernel_x86> arch_debug_stack_trace + 0x12
 1 81227e70 (+  16) 800a32d7   <kernel_x86> stack_trace_trampoline(NULL) + 0x0b
 2 81227e80 (+  12) 80134de6   <kernel_x86> arch_debug_call_with_fault_handler + 0x1b
 3 81227e8c (+  48) 800a4da7   <kernel_x86> debug_call_with_fault_handler + 0x5f
 4 81227ebc (+  64) 800a34eb   <kernel_x86> kernel_debugger_loop(^[[34m0x801868b7^[[0m ^[[36m"PANIC: "^[[0m, ^[[34m0x801abbe0^[[0m ^[[36m"page fault, but interrupts were disabled. Touching address %p from ip %p
"^[[0m, ^[[34m0x81227f68^[[0m ^[[36m""^[[0m, int32: ^[[34m6^[[0m) + 0x20f
 5 81227efc (+  48) 800a388f   <kernel_x86> kernel_debugger_internal(^[[34m0x801868b7^[[0m ^[[36m"PANIC: "^[[0m, ^[[34m0x801abbe0^[[0m ^[[36m"page fault, but interrupts were disabled. Touching address %p from ip %p
"^[[0m, ^[[34m0x81227f68^[[0m ^[[36m""^[[0m, int32: ^[[34m6^[[0m) + 0x77
 6 81227f2c (+  48) 800a511a   <kernel_x86> panic + 0x3a
 7 81227f5c (+  64) 801444b9   <kernel_x86> x86_page_fault_exception + 0x121
 8 81227f9c (+  12) 8013774e   <kernel_x86> int_bottom_user + 0x73
user iframe at 0x81227fa8 (end = 0x81228000)
 eax 0x1           ebx 0x3202         ecx 0x0         edx 0x24f7220
 esi 0x72834ce4    edi 0x24f7220      ebp 0x72834cd8  esp 0x81227fdc
 eip 0x23dd49e  eflags 0x13002   user esp 0x72834cc0
 vector: 0xe, error code: 0x4
 9 81227fa8 (+   0) 023dd49e   <kernel.so> panic + 0x0e
10 72834cd8 (+  32) 02449a73   <kernel.so> abort + 0x13
11 72834cf8 (+  32) 0249473a   <kernel.so> __deregister_frame_info + 0xae
12 72834d18 (+  48) 0129d3fa   <es1370@0x0129c000> <unknown> + 0x13fa
13 72834d48 (+  64) 02654acc   </boot/system/runtime_loader@0x02645000> <unknown> + 0xfacc
14 72834d88 (+   0) 60397250   <commpage> commpage_thread_exit + 0x00
kdebug>

I actually did step 4 by accident; I was trying to copy the driver to /boot/system/non-packaged to see if it works. Getting KDL when trying to execute something unsupported should be fixed.

[bonefish]

vrkosk, unless your issue matches exactly the situation of a closed ticket, please always open a new one. The source of the issue described in this ticket -- runtime_loader crashing when executed like a program -- was explained in comment:2. In your case the runtime loader loads the driver and also the kernel image it was linked against. Apparently the driver and/or its userland kernel execute (initialization) code that confuses the state of the actual kernel (disabling interrupts?). That certainly shouldn't happen. At any rate, it isn't a runtime loader issue.

[vrkosk]

Sorry! Created as ticket 11901.

[diver]

Replying to bonefish:

The cause of the crash is that the runtime loader looks just like a regular executable -- and thus it can be loaded without problems -- but its entry function expects different parameters than a regular executable. The only solution I can think of is to add an explicit check whether the executable is the runtime loader.

Serenity does exactly this ​https://github.com/SerenityOS/serenity/commit/146fac2