Page Fault: Accessed Address: 0x0
YusufKhan-gamedev opened this issue · comments
When trying to run bash(and other programs but I cant reproduce them consistently) it returns:
ERROR EXCEPTION: Page Fault ERROR ERROR Accessed Address: 0x0 ERROR Error: USER_MODE | INSTRUCTION_FETCH ERROR ERROR Task Info: TID=6, PID=6 ERROR Stack: InterruptErrorStack { code: 0x14, stack: InterruptStack { preserved: PreservedRegisters { r15: 0x1, r14: 0x1, r13: 0x2d, r12: 0x7fffffffdffb, rbp: 0x7fffffffdcd0, rbx: 0x0, }, scratch: ScratchRegisters { r11: 0x216, r10: 0x9, r9: 0x0, r8: 0x1, rsi: 0x4ccc75, rdi: 0x4cd05c, rdx: 0x62, rcx: 0x469c50, rax: 0x0, }, iret: IretRegisters { rip: 0x0, cs: 0x33, rflags: 0x246, rsp: 0x7fffffffdc58, ss: 0x2b, }, }, } TRACE ---------------------------------- BACKTRACE ----------------------------------- TRACE 0: 0xffffffff8022e07e - __interrupt_page_fault TRACE 1: 0xffffffff80228d12 - page_fault TRACE 2: 0x000000000040643f - <unknown> TRACE 3: 0x0000000000404e69 - <unknown> TRACE 4: 0x0000000041430d67 - <unknown> TRACE 5: 0x0000000000405cc7 - <unknown>
Also maybe a userland process shouldn't cause a kernel panic by accessing kernel memory....
This is because currently we don’t kill the misbehaving process, not because a process is accessing inaccessible memory. That issue will be addressed in very near future.
This is because currently we don’t kill the misbehaving process, not because a process is accessing inaccessible memory. That issue will be addressed in very near future.
Why is a official port misbehaving?
Why is a official port misbehaving?
I don't know, probably because it wasn't made for Aero and needs some patched to be fully working. I assume Andy never fully patched it because there is a lot of system calls missing that still need to be implemented.
Bash is not fully ported yet. I did not fully port it since I was bit more interested in porting llvm and rust first and I personally prefer aero shell. In future surely if I get time I will fully port it.
Also maybe a userland process shouldn't cause a kernel panic by accessing kernel memory....
I am currently implementing signals so this should be fixed soon.
I think this issue was related to implementing signals since you stated Also maybe a userland process shouldn't cause a kernel panic by accessing kernel memory.... and now since signals have been implemented. I will close this issue.