Nyaux

[ebon needle]

hello zelensky

[silver yarrow]

Nyaux needs to overthrow the oppressive MOGA government

[surreal path]

[hollow goblet]

nyaux gamin

[surreal path]

nyaux not gaming rn

[hollow goblet]

why

[surreal path]

bash isnt getting the return code

and

i have no idea why nano doesnt work

[hollow goblet]

so everything has to succeed :clueless:

no failures in nyauxland

[surreal path]

yes

[surreal path]

waitpid is clearly to blame for this but waitpid is doing everything correctly

[hollow goblet]

task succeeded failfully

[surreal path]

if i cant figure this out ill ask for help for both issues

[ebon needle]

when nyaux minecraft

[surreal path]

i need help with these 2 issues first, if i solve them (or someone else points out the issue for me to fix) and i manage to port nano and doomgeneric maybe

obviously a minecraft server

not a minecraft client

[ebon needle]

what is 2 issues

[surreal path]

ncurses not happy causing nano to not work and bash not getting return code anymore

[surreal path]

still cannot figure this out

[surreal path]

help

[tender gorge]

nano might/probably needs quite a few more TTY things to work i think?

[surreal path]

no not really, its ncurses failing

[tender gorge]

ah

i uhhhhh

[surreal path]

and waitpid isnt working again

[tender gorge]

am too stoopid to be good at helping

[surreal path]

is oki dw

[surreal path]

@molten grotto do u think you can help with this

[molten grotto]

maybe tomorrow, I need to go sleep

[surreal path]

okay

have a good sleep

[surreal path]

hiii did u have a good sleep

[molten grotto]

yes

[surreal path]

thats good

[surreal path]

are u free to have a look later?

in relation to why bash isnt getting the return code and why nano gives out an error saying error opening terminal, more information on the ncurses issue is that it gave an error in nc_new_term()

ive been stuck

for a while in these 2 issues

[molten grotto]

Ill take a look

[surreal path]

okay

thanks :)

[molten grotto]

you write the error code to the user supplied status argument inside the kernel when you should be returning it in the syscall result's .ret

[surreal path]

no? waitpid expects pid as .ret

[molten grotto]

actually nvm ignore that lol

[surreal path]

all good lol

[molten grotto]

yeah I just realized

the loop inside waitpid seems kinda weird tho, like if there are eg. two died processes and you do waitpid you set the processes state to BLOCKED so then the second call to waitpid will fail if there would be a process after that (and the end check should probably be us == cpu->process_list if its a typical circular list where the last one points to the first and not to itself

also waitpid is supposed to block if there are no exited childs with 0 flags

[surreal path]

its not a circular list

[surreal path]

im not blocking

atm

but that shouldnt be an issue

plus i cant block anyway

in a syscall

[molten grotto]

why

[surreal path]

non preemptable syscall remember

[molten grotto]

well at some point you do want at least allow them to block (which isn't that hard tbh, like I think the only thing that there is possibly preventing it is the per cpu syscall user sp which you could save to a field inside the thread at the start of the syscall and restore at the end (and then use the copy saved inside the thread in eg. the fork code)

[surreal path]

either way it shouldnt be an issue to bash

even if i dont block

[surreal path]

kinda would be

but dont quote me on that my brain isnt braining atm

[surreal path]

@molten grotto anything yet?

guessing not

looks like ill have to do more debugging myself

[molten grotto]

yeah I didn't really find anything other than like the exit status is returned fine from mlibc and after that it does an another waitpid which returns ECHILD (which might be where it gets the zero from because the code checks for that and breaks the waitpid loop with status set to 0)

[surreal path]

can u show me which line of code in bash?

[surreal path]

what am i supposed to return to make it happy

[molten grotto]

https://github.com/bminor/bash/blob/6794b5478f660256a1023712b5fc169196ed0a22/jobs.c#L3830 https://github.com/bminor/bash/blob/6794b5478f660256a1023712b5fc169196ed0a22/jobs.c#L2998 I think

[surreal path]

?

@molten grotto

reading the code doesnt make sense to me a lot

im not used to gnu code

i dont see where it sets the status to 0?

[molten grotto]

in the first link it returns -1 and in the second one WSTATUS (child->status) = 0; (I think that's where it would happen anyway)

[surreal path]

so what exactly do i do

[molten grotto]

I am not completely sure, other than like implement it properly lol

[surreal path]

after setting the stauts

what should i do

im not implementing preemptable syscalls atm

[kind root]

What are you trying to do?

[surreal path]

waitpid()

bash is trolling me chat

[kind root]

What's the issue there

[surreal path]

bash setting status to 0

also theres another issue with ncurses

to which i duno

[kind root]

Yeah idk I never got this far

[surreal path]

lmao

[kind root]

Best I did was doom

[surreal path]

crazy

[kind root]

Very

[surreal path]

if only i can get bash to trace

defining debug in the recipe doesnt help

[molten grotto]

well that line is never even included as its inside #if 0

you have to first comment out the if

also there are some memory leaks somewhere, trying to run nano multiple times causes an oom

[surreal path]

ik

thats to be expected

but nano error opening terminal is not fun

@molten grotto

added a debug statement

printing anything causes an infinite loop with waitpid

yea i have no idea how to solve this

[kind root]

How does your waitpid work

[surreal path]

i dont block but i do this

[kind root]

What does bash get back

[surreal path]

^ @kind root

i cant trace much or it gets into an infinite loop

if i mess with the source too much

clearly giving the error code

[kind root]

Ate you sure it's supposed to return echild if the child blocks

[surreal path]

im not blocking at all

but even if its supposed to i dont know

[surreal path]

i really dont know

[kind root]

Did you read the docs for it

[surreal path]

yes

[kind root]

What do they say

[surreal path]

not much information

but bash treats it as no more children

[kind root]

Why do u return echild at all?

[surreal path]

otherwise bash will spam waitpid

it wont ever stop

vinix also returns echild

[kind root]

Well then implement waitpid so that it actually finishes the wait properly lol

When the child dies

[kind root]

Only if there are no children

[surreal path]

as in block?

[kind root]

No

[surreal path]

then what

[kind root]

Just spin until all children die

[surreal path]

good idea

yeaaaaa

i need to implement preemptable syscalls

this shit not working

no wait

it is executing shit?

so why tf

is it not returning

oh right syscall user rsp thats never saved properly

shit

[surreal path]

how exactly would this work, sorry brain not braining

i need to implement this now

[worldly condor]

can you stop posting this everywhere?

it doesn't get funnier

[rigid fable]

I'm simply reacting to his post.

Sorry it's such an issue for you.

[worldly condor]

I think you're the only one here who understands how they are connected

[worldly condor]

I'm not doing this just because, I'm doing this because I got complaints

[surreal path]

?

[molten grotto]

what part of it

like you copy the tmp user sp from the cpu struct to a field in the current thread struct either in the syscall asm or inside a specific syscall that you know will yield or whatever and then either in the syscall asm or at the end of that syscall before returning store the value you stored inside the thread struct to the syscall sp tmp field inside the cpu struct

[surreal path]

why store at the end of a syscall?

[molten grotto]

so the proper value can be loaded back to rsp by the syscall asm

void my_syscall() {
    cur_thread()->syscall_user_sp = cur_cpu()->syscall_user_tmp;
    // yield or whatever, cur_cpu()->syscall_user_tmp can change

    // store the value saved inside the thread to inside the cpu so it can be used by the syscall asm restoring the user sp
    cur_cpu()->syscall_user_tmp = cur_thread()->syscall_user_sp;
}

[surreal path]

what about the syscall frame

[molten grotto]

if you are talking about the usage of it by fork then it doesn't really matter unless you make syscalls unvoluntary preemptable (interrupted by the timer switching to some other thread)

[surreal path]

i mean in general

[molten grotto]

what about it

[surreal path]

wont i lose it

[molten grotto]

why would you lose it, the threads don't use the same syscall stack hopefully

[ebon needle]

wdym

how you can lose it

[surreal path]

wdym

kernel stack is loaded from thread

[molten grotto]

so why would you lose it then

[surreal path]

idk ur right

[surreal path]

struct __syscall_ret syscall_waitpid(int pid, int *status, int flags) {

  struct per_cpu_data *cpu = arch_get_per_cpu_data();
  sprintf("syscall_waitpid(): wait on pid %d, flags %d\r\n", pid, flags);
  if (pid != -1) {
    return (struct __syscall_ret){.ret = -1, .errno = ENOSYS};
  }
neverstop:

  cpu->cur_thread->syscall_user_sp = cpu->arch_data.syscall_stack_ptr_tmp;
  struct process_t *us = cpu->process_list;
  while (us != NULL) {

    if (us->state == ZOMBIE) {
      sprintf("doing so with error code %lu\r\n", us->exit_code);
      *status = W_EXITCODE(us->exit_code, 0);
      us->cnt = 0;
      us->state = BLOCKED;
      return (struct __syscall_ret){.ret = us->pid, .errno = 0};
    }
    if (us->next == us) {
      break;
    }
    us = us->next;
  }
  // TODO: fix syscall to save user rsp
  sched_yield();
  cpu->arch_data.syscall_stack_ptr_tmp = cpu->cur_thread->syscall_user_sp;
  goto neverstop;
}

doing this causes infinite page fault

only thing that fixes it is moving cpu past the label

and it just hangs instead then after giving the error code

idk whats going on

[surreal path]

i slept for too long

looks fine intially

bro

why is it ab8 now????

wtf

@molten grotto how did i fuck this up so bad

tf is going on

yea sched_yield() is fucking shit up

i dunno how but somehow

[surreal path]

hmmm

[ebon needle]

osdev and cs2

[coral dove]

I do the same shit

[worn rain]

I also do the same

we should all play cs2 once

the osdev cs2 major team

[surreal path]

im stuck

[surreal path]

[coral dove]

Let’s do it

[flat nymph]

Just revert to this https://github.com/rayanmargham/NyauxKC/blob/5e4bb4205e84b6b97ecfb0012e6a077b8d4c1a5c/kernel/src/sched/yield.asm

[surreal path]

bru

no

[flat nymph]

what you have right now is pure insanity

[surreal path]

no its not

the return pointer is getting corrupted somehow

[flat nymph]

you're probably just mangling some saved registers

[surreal path]

i dont know where tho

[flat nymph]

if it gets to printf

[surreal path]

it dies returning here

[surreal path]

u said i only needed to save the syscall user ptr but even doing that im somehow corrupting the return pointer??

[molten grotto]

yeah idk the scheduling code is a huge mess

[flat nymph]

is syscall_ret larger than 16 bytes?

[surreal path]

it is 16 bytes

[flat nymph]

us gets corrupted

if you look at assembly, it's probably going to be in the saved regs

[surreal path]

how

[flat nymph]

what does it compile to?

[surreal path]

us is valid

[flat nymph]

Where it dies?

[surreal path]

returning

it doesnt return to syscall_entry

[flat nymph]

It's in rbx

[flat nymph]

you're probably just mangling some saved registers

[surreal path]

yea but i dont know what

[flat nymph]

shed_yield probably

[surreal path]

rbx

[surreal path]

how

backtracing

[flat nymph]

what does disassembly of this look like?

[flat nymph]

like you're not saving/restoring them properly

[surreal path]

yea but i dont know what im not saving/restoring properly

it returns to this spot instead

@flat nymph

RSP IS BEING DUCKED DOWN BY 10 AFTER EVERY SCHED YIELD @molten grotto @flat nymph

[molten grotto]

0x10?

[surreal path]

yes

[molten grotto]

because if yes then I think it makes sense as you never return from schedd (so all the code after that in yield is unnecessary) and the rsp that you put to the irq frame points to what the rsp was after the first push rax

change lea rax, [rsp + 8] to lea rax, [rsp + 24] so it pushes the original rsp skipping the pushed rax + rip

[surreal path]

ill try hold on

[surreal path]

it solved the issue i think?

let me check

it works

thanks @molten grotto

new problem

bash is repeatably calling waitpid

even tho i return the return code

and it DOES return back to syscall entry

which returns to the libc

which returns to bash

bash calls it again

to which gets stuck in an infinite loop because obvious reasons

[molten grotto]

that sounds like it didn't get the pid it wanted to wait for or smth

[surreal path]

idk

it just called again with -1

flags are 0 still

[molten grotto]

ig you can add some debug prints to the loop in bash (though it's likely very spammy if you print something in the general path)

[surreal path]

wait no

now its not spamming it?

no it is

whoops my bad

[surreal path]

okay

@molten grotto

[molten grotto]

maybe it wants ECHILD when there are no more child

[surreal path]

okay hold on

ok atp i have to make the concept of a child an actual thing in my kernel

instead of some process list garbage

[surreal path]

having not fun page table memes

when trying to destroy a pagemap

[surreal path]

this behavior

or

this behavior

or no memory on the second fork() call

not fun

ive debugged for long enough im gonna go play subnautica below zero and tmrw look at it again

[kind root]

I played it for like 12 hours but then got bored

Even though the first game I couldn't stop playing until I beat it

[surreal path]

yea i hear the second game is hella bad

[surreal path]

idk why the made the pda voice sound different in the second game too

[kind root]

Ywah

I wouldn't say it's bad, just kinda feels more empty and boring

[surreal path]

yea i agree

but its still fun ish

so im playing it

[kind root]

Have fun

[surreal path]

subnautica 2 is coming out soon anyway

thanks!

[kind root]

Hopefully its good

[surreal path]

hopefully

[rigid fable]

Sometimes it's always best to take a break, and come back it

[rare pebble]

alr what this

is there a github somewhere

[surreal path]

yes

https://github.com/rayanmargham/NyauxKC/tree/master

[rare pebble]

ty

is there an iso

[surreal path]

its broken atm

[rare pebble]

ARE YOU OSDEV'ING ON WINDOWS???

ah

[surreal path]

via wsl

[rare pebble]

heretic

[surreal path]

but u can run bash

and execute OTHER commands

[spice yarrow]

What's wrong with wsl?

[surreal path]

yea

[rare pebble]

winblows 11

😡

commie architectures

[surreal path]

i dont have support for them

yet lol

[rare pebble]

where x86

[spice yarrow]

Unfortunately there's a lot of stuff that doesn't work well/at all on Linux yet

[surreal path]

nyaux.iso

build it urself lol

or ill build it for u hold on

[rare pebble]

building rn

[surreal path]

dont

[rare pebble]

:3

[surreal path]

ur gonna build the gcc toolchain

[rare pebble]

why 😦

how build iso

[surreal path]

make sure u run it with -M q35

-serial stdio

so u can interface with bash

[rare pebble]

ty

[surreal path]

i dont support keyboard ps2 yet

thats a whole can of worms to deal with later

after i have those 5 bugs in the kernel fixed evneutally

doomgeneric is installed but u cant run it since i have no /dev/fb0 device (YET)

i do have /dev/tty

so have fun with that

[rare pebble]

I added those now how do that?

edit: nvm figure out

[rare pebble]

erm

[surreal path]

yea

its a known bug

run it again

[rare pebble]

i cant

[surreal path]

control C

[rare pebble]

it died and no longer accepts input

[surreal path]

i meant restart the vm

[rare pebble]

ohh

[tardy hull]

silly

i still didnt figure out how to build it -w-

[surreal path]

waking up to debug some more ig

[surreal path]

IVE MANAGED TO MAKE ONE OF THE ISSUES CONSISENT

THANK GOD

one of the issues is now consisent

still an issue but

its coonsisent now

[tender gorge]

that is good

makes it easier to debug at least

[surreal path]

yes

could be a race condition considering i rearranged the shit in waitpid

found the reason for the page fault in waitpid at least

one bug fixed

2 more to go

or 3

but we will get to the ncurses memes when we get there

it was a use after free the waitpid shit

now i triple fault only on kvm

wtf

@molten grotto how tf do i debug a triple fault on only kvm wtf

[thorn bramble]

kvm tracing

[surreal path]

how

[thorn bramble]

idk

google

lol

i didnt know how either

and i forgot

but it's somewhere in my bash history

i just ^R and type "trace" whenever i need it

[molten grotto]

https://www.linux-kvm.org/page/Tracing (though you can usually install trace-cmd from whatever package manager)

[thorn bramble]

i usually just poke at the /sys/kernel fs

[surreal path]

how to delete all lines after the cursor in vscode again

i have a 500mb kvm log file now

i found the triple fault log but i need to make it cleaner cause wtf

qemu-system-x86-187072 [011] d.... 54378.570696: kvm_exit: vcpu 0 reason TRIPLE_FAULT rip 0x41614201 info1 0x0000000000000000 info2 0x0000000000000000 intr_info 0x000000f6 error_code 0x00000000

[thorn bramble]

i don't think you can do that?

[surreal path]

okay

[thorn bramble]

you can select from cursor to the end manually

[surreal path]

yea no way im doing that

this log file is too huge

[molten grotto]

does it say anything before the triple fault line

like other exceptions

[surreal path]

 qemu-system-x86-187072  [011] d.... 54378.570690: kvm_exit: vcpu 0 reason INTERRUPT_WINDOW rip 0x41614201 info1 0x0000000000000000 info2 0x0000000000000000 intr_info 0x000000f6 error_code 0x00000000
 qemu-system-x86-187072  [011] ..... 54378.570691: kvm_inj_virq: irq 32
 qemu-system-x86-187072  [011] d.... 54378.570692: kvm_entry: vcpu 0, rip 0x41614201
 qemu-system-x86-187072  [011] d.... 54378.570696: kvm_exit: vcpu 0 reason TRIPLE_FAULT rip 0x41614201 info1 0x0000000000000000 info2 0x0000000000000000 intr_info 0x000000f6 error_code 0x00000000

[thorn bramble]

dont worry my log files (multiple) we also in the couple hundred MB range when i was doing VMX on managarm

[surreal path]

thats all it gave me

[thorn bramble]

it should have stuff before it

[surreal path]

theres nothing before

[thorn bramble]

you don't just triple fault

there has to be a double fault before that

and before that something else

[thorn bramble]

oh, no, you won't find it like that

[surreal path]

how

??

@thorn bramble

[thorn bramble]

good question

no idea man

[surreal path]

[thorn bramble]

i have never done that

kvm was helpful enough to produce very easy to search entries for what i needed

(entry failure)

it's probably not that in your case

[surreal path]

yea theres nothing about exceptions in the log file

other then triple fault

im fucked

[molten grotto]

what about the exception irq numbers

[surreal path]

yea ur not finding that

[molten grotto]

I mean it would probably be somewhere close to the triple fault line

[surreal path]

wait ept violation

[surreal path]

no its not

[molten grotto]

ept violations can be normal for like mmio and whatever

[surreal path]

yea nothing other then ept violations for mmio

cant find anything related to why it triple faults

yea so what tf do i do....

[molten grotto]

when does it fault

[surreal path]

somewhere in userspace

[molten grotto]

just when you try to boot into bash?

[surreal path]

no

when running nano

[molten grotto]

can you put the updated code to git

[surreal path]

yea

its on git

without the log file ofc

that thing is 500mb

find anything yet @molten grotto ?

[molten grotto]

at some point the rsp that's stored in the tss's rsp0 is not properly mapped so then when you get an interrupt it can't push stuff to the stack

(and as for how I got the double fault to show I added an ist for it so it always has a valid stack to push stuff to)

[surreal path]

when???

[molten grotto]

my bet is that it would be the reaper killing the thread that unmaps it but I haven't verified that

because like its not going to immediately show if its invalid, only after you get an interrupt in usermode

[surreal path]

how doesnt every thread get a seperate rsp0

[molten grotto]

yeah they should

[surreal path]

weird

[molten grotto]

yeah its freed from the reaper

wait I think I might know why, you only change rsp0 if the current thread's frame indicates that it came from usermode, what if you yielded in kernel mode inside a syscall, then the frame doesn't indicate usermode so you don't change rsp0 and then from the syscall you eventually return back to usermode still having not changed rsp0

[surreal path]

remove the check

see if it fixes it

[molten grotto]

yes moving the rsp change line outside the if fixes it

the return code is still broken but at least it doesn't die anymore

[surreal path]

thats with free pagemap COMMENTED out btw

new issue now

when uncommenting free pagemap

this shit happens on running nano again

[surreal path]

@molten grotto gdb gave me no where about this

this is when free_pagemap is uncommented out

im unsure whats going on

[surreal path]

gotcha

im printiung every free

theres no 0x2

so why is head.next becoming 0x2

?????

[brisk zenith]

try setting a watchpoint in gdb

[surreal path]

at 0x2?

[brisk zenith]

at head.next

[surreal path]

okay

[surreal path]

wtf

???

[brisk zenith]

watchpoints highlight the line after the one that triggered it, usually

[surreal path]

wait no hold on

him

yea i dont know whats causing it @brisk zenith

[brisk zenith]

id just continue walking through watchpoints until the new value is 2

unless the address causing the fault is inconsistent?

[surreal path]

it is inconsisent

[brisk zenith]

oh that's incredibly annoying to debug

[surreal path]

yea

[brisk zenith]

i believe there are some qemu flags that make it 100% deterministic which might help

don't remember what they are though

[surreal path]

[brisk zenith]

there's also the record/replay stuff but i've never used that so idk how well it works

[surreal path]

yeaaaaa i dont know what to do now

im stuck

(again for the third time ™️)

[snow wolf]

smells like UAF.

[surreal path]

uaf?

[snow wolf]

use after free

[surreal path]

how

why is it happening at pmm alloc of all places

[snow wolf]

so the thing with this type of bug is that the bug may be in component X, but its symptoms appear in component Y.

[coral dove]

I love UB

[surreal path]

arch destroy pagemap is the issue

dont know why tho

static void destroy_page_table(uint64_t *table, int level) {
  uint64_t *vtable =
      (uint64_t *)((uint64_t)table + hhdm_request.response->offset);
  for (int i = 0; i < 256; i++) {
    if (vtable[i] & PRESENT) {
      if (level < 3 && !(vtable[i] & PAGE2MB)) {
        uint64_t *next_table =
            (uint64_t *)(((uint64_t)(pte_to_phys(vtable[i]))));
        destroy_page_table(next_table, level + 1);
      }
    }
  }
  pmm_dealloc((void *)((uint64_t)pte_to_phys((uint64_t)table) +
                       hhdm_request.response->offset));
}

doing vtable[0] solved it interestingly?

whick kinda makes sense

it still ooms tho after u try to execute nano

so memory leaks somewhere

why tf is nano mmmaping have the memory on the vm tf

and why arent my pagetables getting properly deallocated?

[broken depot]

Just leak every page table like BadgerOS does

[marble surge]

I know I'm late but I think you could do [Shift+Ctrl+End], [Delete]

[surreal path]

yea got no idea whats going on

[surreal path]

nvm we have another bug

'

wtf

[flat nymph]

You don't zero rbp on kernel entry?

(or on thread creation)

[surreal path]

should it be zero on entry?

[flat nymph]

No, like how do you create threads?

[surreal path]

void create_kthread(uint64_t entry, struct process_t *proc, uint64_t tid) {
  struct per_cpu_data *cpu = arch_get_per_cpu_data();
  struct thread_t *newthread = create_thread();
  newthread->proc = proc;
  newthread->tid = tid;
  refcount_inc(&proc->cnt);
  uint64_t kstack = (uint64_t)(kmalloc(KSTACKSIZE) + KSTACKSIZE);
  struct StackFrame hh = arch_create_frame(false, entry, kstack - 8);
  newthread->kernel_stack_base = kstack;
  newthread->kernel_stack_ptr = kstack;
  newthread->arch_data.frame = hh;
  refcount_inc(&newthread->count);
  refcount_inc(&newthread->count);
  ThreadReady(newthread);
}

how i create kernel threads

[median goblet]

ideally you should, that would let the debugger know where the stack trace ends

[surreal path]

rbp is zero?

???????????????????

@flat nymph

wtf is going on

static void destroy_page_table(uint64_t *table, int level) {
  // we are already in a differnt page table so this should be fine
  uint64_t *vtable =
      (uint64_t *)((uint64_t)table + hhdm_request.response->offset);
  for (int i = 0; i < 256; i++) {
    if (vtable[i] & PRESENT) {
      if (level < 3 && !(vtable[i] & PAGE2MB)) {
        uint64_t *next_table =
            (uint64_t *)(((uint64_t)(pte_to_phys(vtable[i]))));
        destroy_page_table(next_table, level + 1);
      }
    }
  }
  pmm_dealloc((void *)((uint64_t)pte_to_phys((vtable[0]) +
                                             hhdm_request.response->offset)));
}

this function is kinda corrupting my stack huh??

[flat nymph]

you're leaking memory

256 should only be for top page table

[surreal path]

the top 256 is for the hhdm which i copy

[flat nymph]

what

userspace is entries 0 - 255 in pml4

[surreal path]

these are all the kernel page tables

which i copy

and i dont get rid of ever

256-512

[flat nymph]

you mean 256-511?

[surreal path]

yes

[flat nymph]

but then you call this function recursively

and it still only frees 256 out of 512 entries

which are now all userspace

[surreal path]

okay good point

static void destroy_page_table(uint64_t *table, int level) {
  // we are already in a differnt page table so this should be fine
  uint64_t *vtable =
      (uint64_t *)((uint64_t)table + hhdm_request.response->offset);
  if (level != 0) {
    for (int i = 0; i < 512; i++) {
      if (vtable[i] & PRESENT) {
        if (level < 3 && !(vtable[i] & PAGE2MB)) {
          uint64_t *next_table =
              (uint64_t *)(((uint64_t)(pte_to_phys(vtable[i]))));
          destroy_page_table(next_table, level + 1);
          pmm_dealloc(vtable);
        }
      }
    }
  } else {
    for (int i = 0; i < 256; i++) {
      if (vtable[i] & PRESENT) {
        if (level < 3 && !(vtable[i] & PAGE2MB)) {
          uint64_t *next_table =
              (uint64_t *)(((uint64_t)(pte_to_phys(vtable[i]))));
          destroy_page_table(next_table, level + 1);
          pmm_dealloc(vtable);
        }
      }
    }
  }
  pmm_dealloc(
      (void *)(pte_to_phys((uint64_t)table) + hhdm_request.response->offset));
}

still fucking ides

man that is fun

[surreal path]

what the function looks like currently

[surreal path]

still stuck

[tender gorge]

🥺 🫂

[surreal path]

been debugging i still dont understand whats wrong exactly

this is so fucking weird

[surreal path]

is there anything inheritably wrong with this function @molten grotto ? this somehow corrupts my stack and causes weird shit

commenting the function out removes all broken behaviorf

so its def osmethinw with this function

??

[molten grotto]

you free vtable multiple times

[surreal path]

how so??

oh wait

[molten grotto]

also you use it after freeing it

[surreal path]

yea

[molten grotto]

you do it inside the loop

[surreal path]

ur right

but

even if i dont free vtabe

it dies still

[molten grotto]

did you remove it from both of the loops

[surreal path]

yes

manages to corrupt the pmm somehow

[surreal path]

idfk how it manages to corrupt the pmm even

cant even watch *0x2

wtf

yea no idea whats going on

even wrote a scan for garabge function after destroying page tables to check for 0x2

it found nothing @molten grotto

all im thinking about is probs memory corruption of some form

[surreal path]

only thing left to try is gdb pt dump

other then that out of ideas lol

before destroy page tables

page tables after destroying it

yea they look normal idfk whats going on

commenting this out doesnt cause much issues

last resort

gonna try this

all the addresses

yea i need help

[molten grotto]

you free take->root twice

at the end of destroy_page_table and in x86_64_destroy_pagemap

[surreal path]

that solved it?

wtf

im still running out of memory tho

so some memory leakage

i think i know why @molten grotto , its because i only free the deepest entry in a page table. is this correct? or wrong?

wait no thats wrong

yea i dont know where im leaking memory now

[molten grotto]

you never actually free the mapped pages

[surreal path]

hoe

how*

[molten grotto]

actually wait

[surreal path]

i pmm dealloc them

[surreal path]

yea i dont know whats going on either lol 😭

bug after bug qwinci

we arent getting a break

[molten grotto]

you do slabfree on the vmm region structs but I don't see you freeing the pages

[surreal path]

because we destroy the page table no? shouldnt that nuke all allocations on the vmm regions anyway?

[molten grotto]

I don't think it destroys the pages themself currently

only the maps

[surreal path]

how so

[molten grotto]

because level is 0 for pml4, 1 for pdp, 2 for pd, 3 for p

I think what would work is removing the level checks from the inner if's and just special casing level 4 to only to pmm_dealloc

[surreal path]

it solved the memory leasks

leaks*\

but why

static void destroy_page_table(uint64_t *table, int level) {
  // we are already in a differnt page table so this should be fine
  uint64_t *vtable =
      (uint64_t *)((uint64_t)table + hhdm_request.response->offset);
  if (level == 4) {
    goto bro;
  }
  if (level != 0) {
    for (int i = 0; i < 512; i++) {
      if (vtable[i] & PRESENT) {
        if (!(vtable[i] & PAGE2MB)) {
          uint64_t *next_table =
              (uint64_t *)(((uint64_t)(pte_to_phys(vtable[i]))));
          destroy_page_table(next_table, level + 1);
        }
      }
    }
  } else {
    for (int i = 0; i < 256; i++) {
      if (vtable[i] & PRESENT) {
        if (!(vtable[i] & PAGE2MB)) {
          uint64_t *next_table =
              (uint64_t *)(((uint64_t)(pte_to_phys(vtable[i]))));
          destroy_page_table(next_table, level + 1);
        }
      }
    }
  }
bro:
  pmm_dealloc(
      (void *)(pte_to_phys((uint64_t)table) + hhdm_request.response->offset));
}

[surreal path]

why does 4 work

[molten grotto]

level 0 entries point to pdp (level1) tables, level 1 point to pd (level 2) tables, level 2 point to p (level 3) tables and the entries in level 3 are the page addresses itself (so level will be 4 for those)

[surreal path]

makes sense

thank you SO MUCH qwinci

liuke actually

so many bugs are fixed lets fucking go

now i can debug ncurses!

dont u love ncurses too qwinic

@molten grotto ?

[molten grotto]

idk lol

[surreal path]

lmao

[surreal path]

need to figure out why bash isnt happy with waitpid

unconditally returning 3 causes bash to accept the return code

??????????????????

that makes sense

🤦

[surreal path]

nano wants a whole gigabyte

thats crazy

gave nano 5G and page fault

:c

[flat nymph]

why do people ignore me all the time?

[surreal path]

im going to cry in a corner :c

ncurses hates me and i hate ncurses

also i have no fucking idea how fbdev works yet i made the device file for doom

which isnt happy cause no keyboard0

[flat nymph]

could it be normal that it allocated a bunch of memory and doesn't use it in the end?

[surreal path]

/dev/keyboard0

[surreal path]

i dont know

i really dont, it allocate huges amounts of memory

and if i gave the vm the memory it need

needs*

it just page faults eventually

so like

:(

at least we have working bash error codes

[flat nymph]

like just error on mmap and see what happens

[surreal path]

i cant just error on mmap for everything

[flat nymph]

when you run out of memory

[surreal path]

ill just error out if it tries to allocate an abirtury size

like idk

a gigabyte

this check isnt working for some reason

wait nvm

hold on

@flat nymph yea i cannot tell it to fuck off

[flat nymph]

[surreal path]

I HATE NCURSES I HATE NCURSES I HATE NCURSES

[flat nymph]

I think this is mlibc memes

[surreal path]

https://tenor.com/view/wah-gif-2764573323952388777

[flat nymph]

can you make it print stack traces on panics?

[surreal path]

i mean sure but ur not getting any symbols

[flat nymph]

you can just addr2line

[surreal path]

no cause it would be userspace shit

ok at this point

we need demend paging

[flat nymph]

What's the problem with it?

[surreal path]

its all loaded dynamically

[flat nymph]

You just load userspace binary into GDB

[surreal path]

im just gonna implement demend paging

cause im SICK of userspace programs asking for gigabytes of ram

sir u dont need that much ram

it may fix some weirdo issues with nano

anyway since i KNOW the nano devs assumes its all gonna be demend paged anyway

[rigid fable]

The fact any of these programs are questing such a size is nuts.

[surreal path]

thats userspace for you

letsgoo

progress on nano after adding demend paging

seems like free is doing a lot of shit

causes it to be HELLA slow

[rigid fable]

Well.... at least for now it's something till you're able to get something else working

[surreal path]

no now i have new issues

[rigid fable]

Oh jeez..

[surreal path]

its open buffer in nano now

[rigid fable]

Certanily some progress!

[surreal path]

bool has_valid_path(const char *filename)

its infinitely allocating in here

it is realpath()

[coral dove]

The Variable named fein is golden

[rigid fable]

How do you even use Jinx anyways? I didn't even really see instructions for it.

[surreal path]

found

lets fucking go

[coral dove]

LETS FUCKING GO BROOOO

[surreal path]

no input working atm but tbf to be expected considering i dont rlly implement tty very well lol

idk how nano reads its input

[coral dove]

read() ioctl() and tcgetattr() and tcsetattr()

[surreal path]

weirdly its not accepting my serial input

eh its fine ill debug that later

im tire

tired

we got nano working lets fucking go

[coral dove]

Nah bro you got nano working good job

You’re the fucking goat

Good night bro I hope you sleep well

Proud of you

[surreal path]

thanks bro

if i can get nano fully working next up will be getting fbdev working for doom

[coral dove]

Shittt that’s awesome

[coral dove]

I couldn’t tell you why

Your read() syscall should handle that

[surreal path]

it does

weirdly nano isnt happy with it

[coral dove]

Hmm, test read() by itself

See what you get

[surreal path]

no read works fine with bash

[coral dove]

Oh damn

[surreal path]

its just nano isnt happy

[coral dove]

No clue then

[surreal path]

its fine ill debug it later

[coral dove]

Yeah go sleep bro

Wait quick question

[surreal path]

?

[coral dove]

Does your read() only work in line buffered mode?

[surreal path]

line buffered mode?

whats that

i have a ringbuffer in the tty

i pop off one char and give it on read

[coral dove]

Do you know what canonical vs canonical mode means

[surreal path]

no

i couldnt understand it quite well

[coral dove]

This helped me a lot to understand it: https://stackoverflow.com/questions/358342/canonical-vs-non-canonical-terminal-input

Basically bash recieves input line by line, but nano needs input for each character

It’s some
Bullshit i just remember running into it when I ported vim to an old kernel I made

There was some paper I found about it

Let me try to find it

[surreal path]

okay

[surreal path]

me after updating mlibc and getting this shit

[coral dove]

Rip

Didn’t you alr implement sys_getuid?

[surreal path]

no

[coral dove]

Well that makes sense then lol

[surreal path]

how

why would it be unknown opcoding??

@coral dove ??

[coral dove]

Wait that’s actually fucking weird

I have no clue😭😭

[surreal path]

yea

i have no clue

[coral dove]

Gdb that I guess

[surreal path]

i tried

[coral dove]

Well

[surreal path]

nothing really

[coral dove]

No trace back to anything?

[surreal path]

nope

[coral dove]

That’s cursed

I would recommend trying to see what mlibc updated

Like see exactly what changed

And then go from there

Because if you can’t get a trace back then you have to work backwards

[surreal path]

yea i have NO idea

[coral dove]

I would recommend looking at the changes mlibc added

[surreal path]

i did

[coral dove]

And what was the thing it changed

[surreal path]

its just netlink shit

and new includes

[coral dove]

Probably in the new includes or something

Did you try looking for the exact sys functions it needs that it’s saying it’s a stub in your error

[surreal path]

what

they are a stub cause they are in my sysdeps

[coral dove]

Oh yeah mb

Yeah I have no clue then

[surreal path]

yeah me too

i cannot track down the rip

:c

[coral dove]

What

How

Show gdb

[surreal path]

k

this isnt even valid assembly according to gdb

its jumping to fucking nowhereland

bro

i have no idea

whats going on

its nearly 5am

i cannot

im gonna make mlibc log everything cause

yea

didnt change garbage

it just hangs after sys_getegid is a stub for like 2 seconds

then dies

same issue

[coral dove]

That’s so cursed

Wtf

[surreal path]

yea i need help

[coral dove]

I would try but you can’t even track down rip

[surreal path]

yea no fucking clue

[coral dove]

Honestly just

[surreal path]

i love when bugs randomly appear as soon as i solve them

[coral dove]

Yeah

Osdev ™️

[surreal path]

™️

[coral dove]

If it makes you feel better

I tried running my os on vmware

And this happened

[surreal path]

damn

well im going sleep, ill ask dennis or whoever when i wake up if they changed anything with the rtld or smt

maybe they can help\

[coral dove]

Alright bro good night. Sorry I couldn’t help more but this is just cursed lol

[surreal path]

it is

dw its fine

gn

[surreal path]

im lost

its failing in bash somewhere idfk its being really annoying to debug

im so fucking lost

[surreal path]

still stuck

@molten grotto did they change anything recently in mlibc?

that couldve caused this

[brisk zenith]

what instruction is faulting there?

could be something like not enabling sse

since it's an illegal instruction exception with what looks like a sane address

[surreal path]

its very inconsisent

and no it sometimes jumps somewhere completely NOT sane

[surreal path]

idk how this would be an issue after updating mlibc

sse is enabled ofc

[surreal path]

i cant find the address either way

its so inconsisnet

@brisk zenith itsfucking garbage

[brisk zenith]

yeah nvm then

[surreal path]

idfk how it got here

[flat nymph]

do you have anything in rbp?

[surreal path]

no

its 0x0

[flat nymph]

(and do you have stack frames enabled?)

[surreal path]

yes ofc

in my kernel at least

[flat nymph]

you can also place a watch point on it

no, you need it for userspace

[surreal path]

whats the flag again

[flat nymph]

-fno-omit-frame-pointer iirc

[surreal path]

thats enabled for userspace

[flat nymph]

and mlibc?

[surreal path]

yes its enabled

[flat nymph]

if it is, something is really messed up

[surreal path]

its in my jinx config

it is

[flat nymph]

could you be jumping there from kernel?

[brisk zenith]

I'm guessing the actual incorrect jump happened earlier, but the data there happened to be valid machine code that zeroes the stack before eventually faulting

[flat nymph]

like if you corrupt stack

[surreal path]

case "$ARCHITECTURE" in
    x86_64)
        TARGET_CFLAGS="$TARGET_CFLAGS -march=x86-64 -mtune=generic -fcf-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -g"
        TARGET_CXXFLAGS="$TARGET_CXXFLAGS -march=x86-64 -mtune=generic -fcf-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer"
        TARGET_LDFLAGS="$TARGET_LDFLAGS -Wl,-z,pack-relative-relocs"
        ;;
esac

thats the full compile options

[surreal path]

i dont know

how its even getting here

seems frmo userspace

[brisk zenith]

what mlibc commit are you on?

[flat nymph]

does it get to the same address?

[surreal path]

latest

[flat nymph]

like maybe you're getting there in ring 0

(idk)

like does the kernel distinguish user vs kernel faults?

[surreal path]

no

if i fault

i fault

[thorn bramble]

not a valid commit hash

[surreal path]

also we are in userspace

[flat nymph]

what is the state of the other registers?

[flat nymph]

could kernel be saving/restoring registers incorrectly?

[surreal path]

not really

it was working before

™️

[flat nymph]

like i don't even know what to suggest

[surreal path]

theres some more things on the stack ™️

[flat nymph]

you could play with watch points

[surreal path]

yea i dont even know what to watch bro

😭

[flat nymph]

i would look at the kernel though

[surreal path]

i mean its obviously something wrong with my kernel

but i dont know what

i dont even know where to begin on debugging this

[brisk zenith]

updated my bootloader to latest mlibc and bash works fine, so i don't think it's that

[surreal path]

obviously wouldnt be that

afterall its always my kernel ™️

theres this one address on the stack

[flat nymph]

just add printfs on all interrupts and faults (and syscall) to see if there's a pattern

[surreal path]

looks promising but idk

[surreal path]

i lit do on all syscalls

idfk wheres its dying

[flat nymph]

what about timer interrupt

[surreal path]

why would i print the timer

[flat nymph]

maybe you're corrupting it there

[brisk zenith]

is the instruction right before what's shown here a call?

[surreal path]

no

[surreal path]

if i was i wouldnt be executing userspace code

[flat nymph]

your kernel doesn't move executables, right?

[surreal path]

it does

[brisk zenith]

wtf why is there a (bad) in the middle of what otherwise looks like completely valid code

[surreal path]

no fucking idea

[brisk zenith]

I think this is probably memory corruption

[surreal path]

just letting you know i demend page all mmaps

i can disable that to see if that changes anything

[flat nymph]

But wtf is 0xe6683 and so on

[surreal path]

no fucking idea

[molten grotto]

bash seems to work just fine for me after a rebuild

[surreal path]

i disabled demend paging for mmap

[surreal path]

huh??

what commit

[surreal path]

didnt change shit

[surreal path]

what did u do

[molten grotto]

the latest one where the bash from the old commit is broken

[brisk zenith]

oh is it just an abi break?

[surreal path]

you mean the commit "help"

[molten grotto]

yes

[surreal path]

idfk

[molten grotto]

I tried to look through mlibc history and I didn't really see anything that would be an issue though so idk

[surreal path]

can u rm jinx cache and try

ill do the same

[molten grotto]

eh

just delete the bash directories from sources, builds and pkgs

[surreal path]

ok hold on

ok its rebuilding bash

@molten grotto still dies with 0x6

[molten grotto]

try doing it for readline too

[surreal path]

i did it for all of them now

[molten grotto]

ncurses I couldn't get to compile on the new version, it says that configure: error: Shared libraries are not supported in this version

[surreal path]

i got the same

fucking weird

idk what this means

do u know @molten grotto ?

[brisk zenith]

oh that's what happens if the one ncurses patch is missing

[surreal path]

which is?

[molten grotto]

ah yeah you deleted the patch

[surreal path]

fuck

[brisk zenith]

This one

[molten grotto]

also you deleted the bash patch too

[surreal path]

yea lemme steal one from vinix holdon

[molten grotto]

you could just restore it from the old commit

[surreal path]

or ill steal from andromeda

i dont know how to use git for shit lol

[molten grotto]

or wget https://raw.githubusercontent.com/rayanmargham/NyauxKC/55fb1b4498610b69257849f00df529ca6ab275b2/patches/ncurses/jinx-working-patch.patch

[surreal path]

my patch isnt working

[molten grotto]

?

[surreal path]

for me it isnt

im apply the patch

applying*

its refusing to work

ill try and rm the sources folder

that solved it nvm

man i love jinx sometimes

okay now itll do readline then bash

then we will see