Nyaux

[surreal path]

this vmm bug is RLLY weird

i still cannot find the issue

[finite summit]

sudo pacman -S gdb

[surreal path]

okay this is the loop thats causing the issues

[finite summit]

It's page faulting right?

[surreal path]

page faulting in the slab cause of this loop yea

i have this loop commented out

and it works fine

checked what address pmm_free_singlep got

it was valid

yea cur_node-> base is valid too

the problem is with deallocating the memory?

commented out pmm_free_singlep and it works fine

void *pmm_free_singlep(void *page)
{
    struct pmm_node *node = page; // ASSUME PAGE IS VIRTUAL
    node->next = head;
    head = page;
}

this is lit the entire function lmao

[finite summit]

gcc generates a ud2 instruction if you don't return a value from a function that should return a value

So it's probably not a page fault and probably a #UD

[surreal path]

☠️

nope

still fault

[finite summit]

sad

[surreal path]

i dont get why its doing this

physicall address looks valid

virtual address looks valid

[finite summit]

"looks"

[surreal path]

it does tho

[finite summit]

but is it?

[surreal path]

well the virtual address is certinally below the hhdm

so it is valid

as a hhdm mapping virtual address

[finite summit]

don't you pass an address offsetted by the hhdm though?

[surreal path]

where?

[finite summit]

here

[surreal path]

thats the for pagemap

pml4

i cant figure it out

why is it that this ONLY happens if i deallocate the page

even tried memsetting it and it didnt NOTHING

wait @kind root could it be that the address is not guaranteed to be page aligned?

cause uacpi

maybe its returning a base that isnt page aligned

or something

idfk

nope

didnt work

[kind root]

What

[surreal path]

im still having some weird ass like bug, in my vmm_region_dealloc function that causes some memory fuckery with the slabs and even if i zero all the pages it doesnt seem to solve anything

if i comment out the freeing of the page

it works fine

which makes zero sense

because the address IS valid

and below the hhdm limit

[rigid fable]

just don’t free

[surreal path]

no

this is like a mini hell

vmm hell

anytime anyone has a vmm issue call it nyaosmaster hell

wait no

call it

hell.

[surreal path]

why cant

i figure this out

this is stinky

[kind root]

Skill issue

[surreal path]

h-h-h-hey shut up

[kind root]

lack of aptitude

[surreal path]

no i can

[surreal path]

does uacpi do use after frees?

it seems like

the pages being requested to be deallocated are still in use

cause if i memset them it also corrupts stuff

[kind root]

No it does not lol

[surreal path]

memsetting cause a page fault in the uacpi interrupter

commenting that ALSO out

it works

[kind root]

Thats a bug on your part unfortunately

[surreal path]

[kind root]

uACPI has been fuzzed to hell

No leaks or use after frees

Also qemu blob has been tested 99999 times by different kernels

[surreal path]

physical address must be invalid then or something

or the virtual address isnt right

how my unmap function looks

[tawdry mirage]

why "b" specifically in the inline asm btw

[surreal path]

stole this from somewhere cause i suck at writing inline asm with C

[tawdry mirage]

also you are not checking for cur_table == NULL in the in-between calls to get_next_table_unmap

[surreal path]

fair

[kind root]

Looks messy but probably correct

[surreal path]

virtual addresses look correct

i dont see an issue with the dealloc function

maybe its somewhere else?

no its not

even this works

HAS to be my vmm

maybe its the alloc function

or something

i dont understand WHATS going on

why is this memory corruption happening

i dont get it

its driving me insane

and i just wanna sleep

but i wont sleep til this is solved

cause i need to finish this before tomorrow

use before free

nvm

this is driving me insane

i might as well just port the vmm to userspace

wait idk how to do that

nvm

i dont know what to do

im going to sleep

maybe tomorrow we will figure it out

pushing what i have done so far onto github

[desert haven]

hell yeah, do it (if you have the time). It's been something I've wanted to do for a bit.

just mmap and a big file on disk to be your secondary storage.

have you tested your pmm's free() function works like you expect?

[surreal path]

It should

[surreal path]

I don’t know how to

[surreal path]

I don’t have swap paging in my vmm ( bro thinks I’m that advanced)

[surreal path]

okay i wake up time for more debugging!

every day i wake up i debug that virtual memory manager

I DONT GET WHY THIS SINGLE LINE OF CODE

CAUSES MEMORY CORRUPTION AND FUCKS THE SLAB ALOOCATIOR

THIS ONE LINE

CAUSES PROBLEMS

WHY???

WHY???????

OKAY ITS EITHER

THE PHYSICAL ADDRESS IS COMPLETELY WRONG

OR MY PMM_FREE_SINGLEP IS BROKEN SOMEHOW

void pmm_free_singlep(void *page)
{
    struct pmm_node *node = page; // ASSUME PAGE IS VIRTUAL
    node->next = head;
    head = page;
}

THIS IS THE ENTIRE FUNCTION??

how is this causing problems

can someone help me i dont understand why this bug is happening

im stuck

these addresses look valid

is my kernel cursed

[kind root]

Yes.

[surreal path]

i swear

it is

its like a second oberrow curse

okay so vmm frees this region with physical address 67D063

Slab Allocator uses this address yes?

dump of some of the addresses

[finite summit]

That ain't the physical address

that's the pte

[surreal path]

how is that the pte??

huh??

[finite summit]

The flags?

The page isn't aligned

[surreal path]

oh.

OH

OHHH

OH MY GOD

IM SO STUPID

IM ACTUALLY

SO STUPID

[finite summit]

You need to mask out the bits

I'll send a bitmask just wait a sec

[surreal path]

IM ACTUALLY SO STUPID OMAR 😭

[finite summit]

we all learn

and make mistakes

[surreal path]

yes we learn

why do you always figure out the problem 😭

bro has a brain bigger then megamind

[finite summit]

Did I not say I am the local guide for fixing dumb allocator bugs

[surreal path]

😭

[surreal path]

alr

[finite summit]

static uintptr_t s_physAddrMask = 0;
size_t GetPhysicalAddressBits()
{
    uint32_t eax = 0, unused = 0;
    __cpuid__(0x80000008, 0, &eax, &unused, &unused, &unused);
    return eax & 0xff;
}
static uintptr_t MaskPhysicalAddressFromEntry(uintptr_t entry)
{
    if (!s_physAddrMask)
        s_physAddrMask = (((uint64_t)1 << GetPhysicalAddressBits()) - 1) << 12;
    return entry & s_physAddrMask;
}```

That's what my kernel does

__cpuid__ is defined as:

void __cpuid__(uint64_t initialEax, uint64_t initialEcx, uint32_t* eax, uint32_t* ebx, uint32_t* ecx, uint32_t* edx);

and is defined here (ignore the mangled names):

https://github.com/oberrow/obos/blob/master/src/oboskrnl/arch/x86_64/asm_helpers.asm

[surreal path]

how big are the physicall address bits usually for 4 level paging on 64 bit

12-57?

[finite summit]

depends on the cpu

which is why I used cpuid

but bits 12-52 max

[surreal path]

can i just assume 12-52

[finite summit]

52-57 are reserved for use in the kernel

[finite summit]

Yeah

That's what my previous kernel

[surreal path]

okay im gonna assume that then

[finite summit]

bits 57-62 are reserved for future use

bit 63 is XD

[surreal path]

yep the no execute bit

[finite summit]

Btw your vmm should have prot flags of some sort

So you can make pages not be able to executed (probably make that the default), make them read-only

etc.

[surreal path]

i have flags for

setting the rw flag

maybe later no execute

rn im just gonna

try to do this funny bitmasking

[surreal path]

okay im a little confused reading this code

[finite summit]

which part

[surreal path]

the eax & 0xff

[finite summit]

Find what cpuid:0x80000008 does in the intel sdm

[surreal path]

okay sec

[finite summit]

bits 0-7 are for max physical address bit size

[surreal path]

which chapter in the sdm

[finite summit]

idk

[surreal path]

oh i see

it will be 57 in decimal if the cpu supports 57 bit addressing @finite summit ?

[finite summit]

that's for the virtual address bits

that lower byte (bits 0-7) is for physical address bits

.!t sdm

[jaunty hinge]

https://www.intel.com/content/www/us/en/developer/articles/technical/intel-sdm.html

[finite summit]

I need to download it

I'll look

[surreal path]

ok

[finite summit]

I don't want to look

Just trust that bits 0-7 of eax when you do that cpuid is for max physical address bits

[surreal path]

will the max physicall address bits be in decimal in the 8 bit field or what

[finite summit]

?

[surreal path]

i dont understand

like

[finite summit]

It's an integer?

[surreal path]

yea okay

okay i understand then

uint8_t addr_bits = 51;

wait probs should be 58

actually wait

51

cause avl can be used by the kernel to store extra flags or smthin

[finite summit]

It can

[surreal path]

yea

im just gonna hard code the value

of the bitmask

@finite summit isnt this cursed

these look valid i think

lemme try giving it to pmm_free

IT WORKS

IT WORKSSSSSS

!!!!!!!!!!!!!!!!!!

[finite summit]

You're welcome

[surreal path]

omar ur so pro 😎

@kind root uacpi now works on NyaOS! are u proud of me

[kind root]

Well u didn't implement any api but its good that u fixed memory bugs

[rigid fable]

he probably was expecting some kinda of congratulations

[surreal path]

yea 😠

[rigid fable]

now it is time to port libc

and then doom

[surreal path]

☠️

[rigid fable]

do you already have system calls? (I do not think so)

[surreal path]

no

lmao

[rigid fable]

well start with that

[surreal path]

i dont even have the ioapic setup

i dont even have

userspace

[rigid fable]

then do it

[rigid fable]

userspace comes right after syscalls

we all want to see doom here

[surreal path]

i dont need to go to userspace rn

i need an interrupt controller rn

cause currently

i DONT

have a timer

at all

[rigid fable]

you could use the old pic for now

[surreal path]

no

[rigid fable]

it is very easy to implement, and besides the less time you spend on platform dependent code the better

[surreal path]

im gonna try and learn the APIC and figure out how to set it up and start using it

[rigid fable]

although I do not think you are going to port this to other archs anytime soon

[surreal path]

no

x86-64 only baby 😎

before i do anything tho

i wanna do some fun

before anything

cause yea

so im gonna try and like load an image or smthin via limine kernel modules

and display it onto the framebuffer

just for fun

[rigid fable]

that is very easy

do you already have the framebuffer set up?

[surreal path]

yep

[rigid fable]

do it then, should't take more than 20 minutes

what image are you going to use? (weren't you the one who wanted a "kawai" os?)

if that's the case some anime pic should do it

[surreal path]

first i need to find out how im gonna decode the file format

[rigid fable]

ah that. You could convert the image to a binary (very easy), or use stb image (also very easy)

if you use stb image you can directly load a png, jpg, bmp or whatever

[surreal path]

ill use stb image

[rigid fable]

https://github.com/nothings/stb

stbi_load_from_memory may be the function you need

do you know how to add a module via limine?

[surreal path]

not rlly sure

but ill figure it out

[rigid fable]

MODULE_PATH=boot:/// + path

MODULE_PATH=boot:///image.png will load the image from the root directory

[surreal path]

okay

lemme find an image to load

😃

[rigid fable]

you also need to interface via the limine protocol requests, but I will leave the fun to you (https://github.com/limine-bootloader/limine/blob/v7.x/PROTOCOL.md)

You want to use modules

what resolution are you targetting?

@surreal path

[surreal path]

resolution?

[rigid fable]

the framebuffer resolution

[surreal path]

i dont know limine gives me whatever resolution framebuffer it wants to give

[rigid fable]

Seems nice (just a suggestion)

[surreal path]

okay wait

just got limine to load the image for like the boot screen which is really easy but i was just modifying my makefile for that to work

now i will make a module and try to load

it

yea

[rigid fable]

hmmm

maybe you can use the stbi_load_from_memory function to load the image directly inside the framebuffer

[surreal path]

okay time to get the module

got the module path

[kind root]

Congratulations

[surreal path]

thank u

thats ze address of ze module

lemme try and setup STB_IMAGE.h

@rigid fable will stb_malloc ever allocate a page or more

i probs should have my kmalloc check that actually

[kind root]

Yes

[surreal path]

yea

i did that but

why tf is stb_image including stdlib

how do i stop that

[kind root]

Ask it nicely

[surreal path]

okay i will

[rigid fable]

hmmm

I think stb image might not be a good idea, since it seems like it is heavily using userspace functions

[surreal path]

nah i only had to comment them out

void *krealloc(void *addr, size_t oldsz, size_t newsz)
{
    void *new_shit = kmalloc(newsz);
    memcpy(new_shit, addr, oldsz);
    kfree(addr, oldsz);
    return new_shit;
}

[rigid fable]

it may not work

[surreal path]

why?

why so?

[rigid fable]

for me it is giving a ton of undefined references to C functions

[surreal path]

because u have to comment out a lot of stuff

im reading minsukis patch on stbi_image

applying it manually

[rigid fable]

You might aswell just load a raw binary image

[surreal path]

nah

i got this dw

[rigid fable]

https://lvgl.io/tools/imageconverter

[surreal path]

got it to compile cause im so pro 😎

i will try to load the image

[rigid fable]

@surreal path

[surreal path]

like wait

[rigid fable]

the entire code is like 5 lines (with the pointer declaration)

    framebuffer[i] = image[i];
}```

[surreal path]

yea trying to load it with stb image isnt work well

[rigid fable]

just do as I did

try to see what resolution is your os running on

I did a screenshot of the screen and measured the size in pixels of the qemu window

mine was 1280 * 720 (edit: those 80 pixels were the qemu title bar and I mistakenly thought it was the fb res, so it is actually 16:9)

[surreal path]

how will i load it

what should be the output format

[rigid fable]

binary rgb888

As input format I put cf true color

you can also dither

but make sure the image is the correct size, else it will either not fit or crash

[surreal path]

i tried to do this

but

didnt rlly work

[rigid fable]

do not declare the fb pointer inside the loop

[surreal path]

okay but

its not doing anything

for some reason

[rigid fable]

...

why is the size in the for 100

[surreal path]

just to try the first couple of pixels

[rigid fable]

what is happening?

[surreal path]

oh nvm

ummmm

[rigid fable]

can you send here the actual image?

[surreal path]

ok

[rigid fable]

can you send the original png?

I just want to compare the result with the og image

[surreal path]

ok

[elder shoal]

where pitch

[surreal path]

wdym

(sorry if thats a stupid question, i dont know much about framebuffers)

[rigid fable]

we are doing it in the bad way

[rigid fable]

the size in bytes per line

[elder shoal]

The memory offset between the start of each line

Yeah

[surreal path]

okay

[rigid fable]

we are doing it in a hackish way

[rigid fable]

your image crashes my program too

...

[elder shoal]

@surreal path whats the format of the image youre reading

[rigid fable]

resize the image to 1280*720 and remove alpha

[elder shoal]

24 bpp or 32 bpp

[surreal path]

binary rgb888

[surreal path]

how to remove alpha

[elder shoal]

Thats probably whats going on

[surreal path]

bpp?

[surreal path]

?

[elder shoal]

Bits per pixel

[surreal path]

32 i think

[elder shoal]

This assumes both fb and img are 32 bpp

[rigid fable]

no no, the issue is the image itself being formatted poorly by the converter, probably because of the alpha channel. I used the exact same way but it worked

[rigid fable]

yes

[elder shoal]

Ohh

[rigid fable]

but since we are using qemu and the same converted that won't be an issue

in theory

[elder shoal]

I see

[rigid fable]

np

for me the framebuffer IS actually 800 in height, and not 720

[surreal path]

tried removing alpha channel but still

[rigid fable]

how did you try? And what is the image size?

[surreal path]

used some site do remove the alpha channel then i reconverted it

image size is 522x614

[rigid fable]

wait

here you go

[surreal path]

causes page fault

oh wait size is wrong

still

its looking all weird like that

[rigid fable]

the image needs to be of the same size as the framebuffer (at least in width), else the loop won't work

[surreal path]

i did

for (int i = 0; i < 507 * 597; i++)
    {
        fb[i] = img[i];
    }

[surreal path]

oh

but what if i dont want that

[rigid fable]

wait

    for(int x = 0; x < WIDTH; x++) {
        fb[x + y * FB_WIDTH] = img[x + y * WIDTH];
    }
}```

in theory this should work

[surreal path]

wowie

thats an image

[rigid fable]

good

just for curiosity, did you use my double for loop or wrote something yourself?

because for me it is not working

[surreal path]

your double loop

for(int y = 0; y < 597; y++) {
        for(int x = 0; x < 507; x++) {
            fb[x + y * framebuffer->width] = img[x + y * 507];
        }
    }

[rigid fable]

bah

aha

the issue was that YOU gave me the wrong image width

507 works

[surreal path]

yea

[rigid fable]

now try with an anime image

so you can flex

time to port xorg to have windows!

@surreal path how is it going? I am eager to see what image you chose

[surreal path]

sec i

im picking an image

[rigid fable]

tryharding

[rigid fable]

are you using qemu from wsl?

[surreal path]

yea

[rigid fable]

what window server are you using?

[surreal path]

?

[rigid fable]

are you using VcXsrv or WSLg or something else?

[surreal path]

wslg

anyways loading that image was fun

even got a little bit of transparency going

😎

[rigid fable]

by rendering the image before the text?

[surreal path]

no by doing a check

checking if the pixel we are gonna place the pixel on is black

if it is

place the img pixel

if it isnt

dont do anything

[rigid fable]

https://stackoverflow.com/questions/746899/how-to-calculate-an-rgb-colour-by-specifying-an-alpha-blending-amount

use this in your image rendering function

out = alpha * new + (1 - alpha) * old

out is the framebuffer, new is the color of the image, old is the value at the framebuffer before writing

oh and you do this after the text is rendered. otherwise you would put this inside of the text rendering instead

(you would need to have floating points working)

else just rewrite the function using ints, but it needs some formula conversion

[surreal path]

dont have floating points

😎

[thorn bramble]

lf those are page addresses then id what you’re doing but its definitely wrong 💀

bruh discord trolled me

nevermind i guess

[surreal path]

what? those arent page addresses

????

[thorn bramble]

i was replying to like

an old message

[surreal path]

ah kk

[thorn bramble]

idek where it is now

mobile discord moment

[surreal path]

its all correct now

so its fine 😎

[thorn bramble]

i was replying to this

discord didnt show me any newer messages for some reason

sooo hows integrating uacpi going, im not following this thread very closely :^)

[surreal path]

we have it working

uacpi now loads

[thorn bramble]

hell yeah

[surreal path]

yea !!!

[thorn bramble]

we

[surreal path]

we

[thorn bramble]

[surreal path]

communism

[rigid fable]

fairyness (in todays tutorial I am going to show you how to get banned from osdev!)

[surreal path]

NyaOS is bending the computer to its will

the cpu will listen to whatever nyaos says

😠

[wicked loom]

btw an update on the slab situation i mentioned yesterday

the slab allocator was fine

so was the pmm

[haughty kite]

(a) is this the right place for it? (b) what was it?

[wicked loom]

the bug was somewhere in the ELF load code which would end up writing 0x2000 in an area allocated of size 0x1000

[haughty kite]

not good

[wicked loom]

(a) yes, because i brought it up yesterday in here in relation to nyaos's issues getting uACPI to run

that were assumed to be due to the slab allocator

[haughty kite]

ah

[wicked loom]

i said i would report back

so i am now reporting back

[haughty kite]

ah yeah okay

does glxgears work now?

[wicked loom]

yeah

[haughty kite]

based

[wicked loom]

it still runs out of memory after a while

there are leaks i know about, and others i do not

but it's at least stable and reproducible now

well, for the most part

the scheduler still seems to not be 100%, especially when running on 1 core

and glxgears can be made to page fault in userland by running more than 1 instance of it

but anyways it's better than it was before and that's what matters

glxgears is a really intensive process to run

[surreal path]

nyaos now runs uacpi nicely!

!!!

no more allocator bugs

[wicked loom]

yeah i saw

good job

[surreal path]

yea 😎

thanks mint!

[surreal path]

what is ur opinion on the cool image loading (via limine modules) i got 😎 😎

[wicked loom]

ah yeah

that's one of those windows waifus isn't it

[surreal path]

yea

[wicked loom]

i wanted to mention that maybe you may want to look into @edgy pilot 's flanterm version that also handles loading bg images; though i never used it myself so idk how good it is

[thorn bramble]

vinix?

[surreal path]

spent a good 10 minutes trying to find a kawaii wallpaper for this (to fit with the theme)

[wicked loom]

and also, the flanterm submodule doesn't seem to be the latest commit but whatever

[surreal path]

they havent updated it in a while

[wicked loom]

yes

Lyre is hopeless

[surreal path]

oh wait

[thorn bramble]

ah nice

[surreal path]

yea ill update that

[thorn bramble]

oh come on

[wicked loom]

i mean like

not you

i mean ilobilo's flanterm thing

[surreal path]

yea thats old

[haughty kite]

i know what your real problem is

[surreal path]

they need to update it

[haughty kite]

not enough borrow checking

[thorn bramble]

ryre time

[surreal path]

ryre?

[haughty kite]

worry not, for valex said its going to be in V at some point afaik

[thorn bramble]

rust lyre

[haughty kite]

which actually would really be super cool

[wicked loom]

V's autofree works surprisingly well

[haughty kite]

well yeah i mean

its a pretty classic concept

[surreal path]

ryre time

[haughty kite]

just instead of autofree they usually call it "regular optimizer shit"

[wicked loom]

Vyre

[surreal path]

Vyre

[thorn bramble]

we’ve had destructors and move semantics in c++ for quite a while now

[haughty kite]

that sounds a lot better than vinix

[haughty kite]

c++ move semantics are rather weird

[thorn bramble]

im glad v is finally catching up

[wicked loom]

well i guess we could rename it :^)

[surreal path]

maybe i should rename my os to be fair

[thorn bramble]

nyux

[surreal path]

nyux?

[wicked loom]

nyux is good

[surreal path]

okay NyaOS is now Nyux

[thorn bramble]

oh god

[wicked loom]

anything is better than xxxxxOS

[haughty kite]

i agree

[surreal path]

Nyux

😎

[wicked loom]

which is why i kinda cringe when people say LyreOS even though that's the org name

it's only the org name because Lyre is taken

same with limine

[surreal path]

yea

[wicked loom]

it would be limine/limine if limine hadn't already been taken

i should probably email gh support about it, to see if they can give it to me

i know someone that did that once and it worked for them

[thorn bramble]

they dont give away stale names

anymore at least

they used to

[wicked loom]

well that's a shame

[thorn bramble]

but i think it changed with the microsoft acquisition

[surreal path]

NyaUX

Nyaux

yea i think that works

also its pronounced Ne-ya-ex

[wicked loom]

no it isn't

[surreal path]

how is it pronounced then

[wicked loom]

/ɲoks/

[surreal path]

ah oka

Coming up with a name is the hardest part of osdev

[wicked loom]

actually [ɲɔks]

i got the o wrong

[surreal path]

i dont know how to pronounce that 😭

[wicked loom]

http://ipa-reader.xyz/

[surreal path]

ah i see

okay

[wide latch]

nyaux

[surreal path]

nyaux

[surreal path]

oh yeah mint if you dont mind can u like pin this in the thread?

[surreal path]

thanksss

oh yeah mint is there like a way to make flanterm not draw the background or smthin

i dont wanna reupdate the image everytime i write text

[elder shoal]

You can pass a canvas to flanterm

[surreal path]

canvas?

whats a canvas?

[elder shoal]

The background image to be used

[surreal path]

i can just give it the background image?

and it will load it

???

[elder shoal]

I imagine you will have to resize the image too

[surreal path]

the image has the same width and height of the framebuffer sooo idk

[elder shoal]

Mintsuki knows how flanterm works better than me they can explain better I think but yeah

[elder shoal]

Then Indont think you need to resize

[surreal path]

nothing happens

when i give flanterm the img

[elder shoal]

@wicked loom how does one use the canvas in flanterm again

[wicked loom]

wdym?

it's just a background, it's a raw bitmap

but yeah you have to resize it and all

and it doesn't automatically generate the nice box with a margin and alpha blending like Limine does

that's why i suggested using ilobilo's thing, because it does all that

[elder shoal]

I see

[surreal path]

i tried loading it but nothing happens

[wicked loom]

define nothing

do you set a background colour at any point that isn't default?

[surreal path]

oh

ok wait

[wicked loom]

default bg == canvas

as in

you set the background colour to default using escape sequences (or just don't set an alternative bg colour)

[surreal path]

this is what i do

[surreal path]

i set the bg to null and still nothing happens

[wicked loom]

try nulling out the default_bg

[surreal path]

i did

nothing happens

[wicked loom]

what is the format of img

[surreal path]

its a binary file

[surreal path]

produced by this website

[wicked loom]

oh wait i know why

[surreal path]

format is

RGB8888

[surreal path]

why?

[wicked loom]

for the canvas to work you need to pass an allocator to flanterm

[surreal path]

how do i do that

[wicked loom]

first 2 arguments

you pass it malloc and free

[surreal path]

oh okay

[wicked loom]

you can just initialise flanterm twice

[surreal path]

rlly?

[wicked loom]

the first time without the allocator if you need it before you have the allocator initialised, and then afterwards you can deinit the previous context and make another one with the allocator

yeah

deinit with c ctx->deinit(ctx);

[surreal path]

size?

[wicked loom]

no

[surreal path]

huh?

[edgy pilot]

I just updated

[wicked loom]

it takes the free() function, you can pass NULL

since your first context was initialised without allocator

your autocomplete isn't saying size_t, it's saying void (*)(void *, size)

[surreal path]

uhhhh

[wicked loom]

aka a sized free

yeah that just looks like you set the bg to black using escape sequences

that's normal lol

[surreal path]

how to undo that

[wicked loom]

you just want to set the bg to default, not black

it's another escape sequence

[surreal path]

this

[wicked loom]

does that look like an escape sequence lol

[surreal path]

no

[wicked loom]

wait are you calling directly into those?

you shouldn't really do that

https://man7.org/linux/man-pages/man4/console_codes.4.html

[surreal path]

whats the escape code for the default background

[wicked loom]

\e[49m

alternatively, \e[m will reset all

both bg and fg

[edgy pilot]

I like this https://gist.github.com/fnky/458719343aabd01cfb17a3a4f7296797

[wicked loom]

yeah this also works

[surreal path]

fixes nothing

[wicked loom]

are you sure it's not white on white

[surreal path]

huh

wdym

[wicked loom]

also

hmm

i am so confused

how is it still showing the previous terminal context's text

[surreal path]

no idea

[wicked loom]

did you call the init func with sensible parameters?

[surreal path]

yea?

[wicked loom]

idk your screenshot cuts it off

[surreal path]

ctx = flanterm_fb_init(kmalloc, kfree, framebuffer->address, framebuffer->width, framebuffer->height, framebuffer->pitch, framebuffer->red_mask_size, framebuffer->red_mask_shift, framebuffer->green_mask_size, framebuffer->green_mask_shift, framebuffer->blue_mask_size, framebuffer->blue_mask_shift, img, NULL, NULL, &bg, NULL, NULL, NULL, NULL, 0, 0, 1, 0, 0, 0);

the function call

[wicked loom]

check if you're not getting NULL here

you should check for errors

[surreal path]

no its not null

[wicked loom]

then it should work

how much memory do you give your VM?

[surreal path]

3G

[haughty kite]

sounds like your malloc might be bad

[wicked loom]

does your kfree take a size parameter?

[surreal path]

yep

[wicked loom]

in bytes or pages?

[surreal path]

bytes

[wicked loom]

okay

then yeah

[surreal path]

no not rlly, uacpi ran fine

i went through my oberrow hell already

[wicked loom]

i mean that's not necessarily proof your vmm isn't broken

pmm*

or both lol

[surreal path]

i dont think they are lol

[haughty kite]

idk man

you are getting weird artifacting

that could easily be caused by a bad malloc

[wicked loom]

flanterm works fine under ubsan, asan, and through extensive fuzzing, so i strongly doubt flanterm is the issue

[haughty kite]

and you are going like "definitely not that"

[wicked loom]

like

when the context is initialised, the screen is cleared to bg

[surreal path]

cause i spent days debugging extensively and working on it to get uacpi to work 😭

[surreal path]

it did initally but when i put the img it just

it doenst clear it

[wicked loom]

what

[surreal path]

like

if i dont give flanterm the image

the screen is cleared just fine

like this

[haughty kite]

still doesnt mean anything

make your kmalloc memset new regions to like 0xaa

[surreal path]

why??

[edgy pilot]

you could try using this https://github.com/ilobilo/limine-terminal

[wicked loom]

it sounds likely your kmalloc is broken for large allocations

[haughty kite]

to catch issues

[wicked loom]

does it reliably allocate ranges significantly larger than 1 page?

[surreal path]

yep

[wicked loom]

that says failure

[surreal path]

lol

im just printing that

for no reason

[wicked loom]

have you tried halting without printing anything?

[rigid fable]

what kind of font format does flanterm use? A flat binary?

[wicked loom]

in the new context

[surreal path]

idk

[surreal path]

ok ill try

[rigid fable]

mintsuki may know

asking for curiosity

[wicked loom]

yes

[surreal path]

same result

please note that the binary is like

a 3mb file

[haughty kite]

did you do the memset thing i mentioned yet

[wicked loom]

can you try passing a canvas which is just an empty malloc of width*height*4

instead of the image

[surreal path]

sure

[rigid fable]

wouldn't that draw garbage?

[wicked loom]

well, it would draw whatever

if the mallocs are zeroed out then it would print black

else, whatever garbage

it doesn't matter though as it's just a test

[surreal path]

oh its not zeroed out

my kmalloc doesnt zero out by default

[wicked loom]

flanterm doesn't expect that

so it doesn't matter

[surreal path]

whats weird is like

the last piece of line of text disappeared

[wicked loom]

have you done any of the testing pitust or i mentioned yet?

[surreal path]

sure

i will

sec

something like this?

[haughty kite]

yes

[surreal path]

causes a gpr

[haughty kite]

so your kmalloc is broken

well there you go

[rigid fable]

thw nightmare has begun

[wicked loom]

yeah you're malloc is probs broken

[surreal path]

oh fuck no not again

[haughty kite]

what happens if you remove kfree

like

[surreal path]

okay sec

[haughty kite]

if you make it never do anything

[surreal path]

still gpr'd

[haughty kite]

sounds like your malloc is pretty broken

[surreal path]

[wicked loom]

btw

just to make sure

[haughty kite]

oh btw @wicked loom: to find leaks, you can try writing a log of something like c struct entry { bool free_not_malloc; uint32_t alloc_size; uint64_t address, caller; } into the magic ivshmem device i mentioned, and then postprocess than in python or whatever to find all the allocations that don't get freed

[wicked loom]

you mean gpf, not gpr, right?

[surreal path]

gpf? yea a general protection fault. 0xd

[wicked loom]

you said gpr

[wicked loom]

alright

[surreal path]

should've said gpf

but yea it gpf'd

r13 doesnt look canoical

so its my malloc correct?

[haughty kite]

well yeah thats the memset

obviously

but memsetting the framebuffer to whatever shouldnt cause a gpf

[surreal path]

im not memsetting the framebuffer

im memsetting the kmalloc allocation

[haughty kite]

really.

oh well yeah whatever

either way

[surreal path]

the memsetting isnt the FAULTING instruction

[haughty kite]

memsetting that shouldnt cause a gpf no matter what garbage ends up there

[surreal path]

so its my kmalloc

@haughty kite ?

[haughty kite]

yes

[surreal path]

why

ANOTHER

oberrow hell

this time its my vmm

wait i do memset with my vmm

is that a problem

no that shouldnt be

great

this is just great

okay creates the 3mb region

it looks valid

so why does memsetting 0xaa and then giving it to flanterm cause a gpf

why

oh wait...

kmalloc returns a 64 bit address virtual address

img is of uint32

still didnt fix anything

what it looks like just before it gpf'd

[rigid fable]

...

hmm.

[rigid fable]

and? That is a POINTER variable for 32 bits, so the variable is still 64 bits wide

[surreal path]

oh

[rigid fable]

you might as well implement the pmm and vmm from scratch and test it bit by bit with test cases

[surreal path]

bro ur kidding right...

dude your actually kidding.

[rigid fable]

np, writing one means you will know every but of it, and can test it more in depth

😀

this emoji is so cool haha

[surreal path]

no i need to fix the problem with my current vmm region allocator

smthin funky is going on

void *vmm_region_alloc(uint64_t size, uint8_t flags)
{
    struct vmm_region *cur_node = vmm_head;
    struct vmm_region *prev_node = NULL;
    while (cur_node != NULL)
    {
        // ASSUME REGIONS IN ORDER CAUSE WE COOL :sunglasses:
        if (prev_node == NULL)
        {
            prev_node = cur_node;
            cur_node = cur_node->next;
            continue;
        }
        if ((cur_node->base - (prev_node->base + prev_node->length)) >= align_up(size, 4096) + 0x1000)
        {
            struct vmm_region *new_guy = kmalloc(sizeof(struct vmm_region));
            new_guy->base = (prev_node->base + prev_node->length);
            new_guy->length = align_up(size, 4096);
            prev_node->next = new_guy;
            new_guy->next = cur_node;
            cur_node = cur_node->next;
            int num_of_pages = align_up(size, 4096) / 4096; // num of pages to alloc :sunglasses:
            for (int i = 0; i < num_of_pages; i++)
            {
                void *page = pmm_alloc_singlep();
                // memzero that shit!
                memset(page + hhdm_request.response->offset, 0, 4096);
                map((uint64_t)pml4 + hhdm_request.response->offset, new_guy->base + (i * 0x1000), page, flags);
            }
            return new_guy->base;

        }
        else
        {
            // not enough space for our new region sadly, continue
            prev_node = cur_node;
            cur_node = cur_node->next;
            continue;
        }
    }
    // STILL HERE?
    // PANIC CAUSE NO REGIONS CAN FIT VMM REGION WOWIE!
    serial_print("NO FREE REGIONS\n");
    asm ("cli");
    for (;;)
    {
        asm ("hlt");
    }
}

this is how im allocating my vmm region

the problem must be coming from here

cause like

yea

[surreal path]

why am i tortured to this allocator hell

why everytime

[elder shoal]

Welcome to osdev

[surreal path]

and i had just THOUGHT

I THOUGHT I SOLVED EVERYTHING

and then

this happens

this is painful

Creating Region of Base: FFFF8000BFF31000 with Limit: FFFF8000C0231000
requested: 792
requested: 4096
requested: 32
Creating Region of Base: FFFF8000BFF2D000 with Limit: FFFF8000BFF2E000
requested: 36864
requested: 32
Creating Region of Base: FFFF8000C0231000 with Limit: FFFF8000C023A000
requested: 65088
requested: 32
Creating Region of Base: FFFF8000C023A000 with Limit: FFFF8000C024A000
requested: 173568
requested: 32
Creating Region of Base: FFFF8000C024A000 with Limit: FFFF8000C0275000
requested: 43392
requested: 32
Creating Region of Base: FFFF8000C0275000 with Limit: FFFF8000C0280000
requested: 3145728
requested: 32
Creating Region of Base: FFFF8000C0280000 with Limit: FFFF8000C0580000

now do these virtual addresses look valid

hmm

FFFF8000C0280000 to FFFF8000C0580000

3mb region

addresses look valid

so why is a general protection fault happening

why here of all places

i dont get it

uh huh

that shouldnt be happening

why tf

is it like

not countingous or something???

[wicked loom]

have you checked why you're getting a GPF?

like, GPFs are fairly specific (in being non specific) in that they are not page faults

[surreal path]

uh yea

[wicked loom]

you can usually infer why you are triggering one

[surreal path]

it doesnt trigger a gpf when i dont call flanterms ctx init

but instead produces this weird result

[surreal path]

which is odly similar

[wicked loom]

i mean this makes sense, you should check for 0xaaaaaaaa

it's a uint32_t

[surreal path]

okay theres no what the fuck

like at all

so every piece of memory IS 0xaaaaaaaa

and it is being given correctly

if thats the cause

why is it appearing like that

why does flanterm gpf

what the fuck is going on

[wicked loom]

it doesn't necessarily have to be the cause

there could honestly be any number of issues

[surreal path]

so it isnt malloc it seems

[wicked loom]

ranging from allocator bugs to other sorts of corruptions and whatnot

it could still be your malloc, but only when it is called by flanterm later on

check why you are getting a GPF from flanterm

dump the registers, see the error code if any

etc

check the stack

[surreal path]

i dont believe so because uacpi has done thousands of calls upon malloc, to which everything works fine

[surreal path]

okay

check_exception old: 0xffffffff new 0xd
   413: v=0d e=0000 i=0 cpl=0 IP=0028:ffffffff80016f8b pc=ffffffff80016f8b SP=0030:ffff80007fe8ee50 env->regs[R_EAX]=0000000000000000
RAX=0000000000000000 RBX=ffff800000008018 RCX=0000000000000000 RDX=0000000000000000
RSI=ffff8000c0275000 RDI=ffff800000008018 RBP=ffff80007fe8ee80 RSP=ffff80007fe8ee50
R8 =0000000000001530 R9 =00000000000c03f3 R10=ffff8000c0280000 R11=0000000000000009
R12=0000000000000000 R13=00aaaaaa00aaaaaa R14=ffff8000c0275000 R15=0000000000000090
RIP=ffffffff80016f8b RFL=00000006 [-----P-] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0030 0000000000000000 00000000 00209300 DPL=0 DS   [-WA]
CS =0028 0000000000000000 00000000 00209a00 DPL=0 CS64 [-R-]
SS =0030 0000000000000000 00000000 00209300 DPL=0 DS   [-WA]
DS =0030 0000000000000000 00000000 00209300 DPL=0 DS   [-WA]
FS =0030 0000000000000000 00000000 00209300 DPL=0 DS   [-WA]
GS =0030 0000000000000000 00000000 00209300 DPL=0 DS   [-WA]
LDT=0000 0000000000000000 00000000 00008200 DPL=0 LDT
TR =0000 0000000000000000 0000ffff 00008b00 DPL=0 TSS64-busy
GDT=     ffffffff80101680 00000040
IDT=     ffffffff801016e0 00001000
CR0=80010011 CR2=0000000000000000 CR3=0000000000009000 CR4=00000020
DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 
DR6=00000000ffff0ff0 DR7=0000000000000400
CCS=0000000000000000 CCD=00aaaaaa00aaaaaa CCO=LOGICQ
EFER=0000000000000d00

e=0000

so not a segment error

Accessing a memory address with bits 48-63 not matching bit 47 (e.g. 0x_0000_8000_0000_0000 instead of 0x_ffff_8000_0000_0000) in 64 bit mode.

[wicked loom]

diasssemble what's at RIP

[surreal path]

okay

static void draw_cursor(struct flanterm_context *_ctx) {
    struct flanterm_fb_context *ctx = (void *)_ctx;

    if (ctx->cursor_x >= _ctx->cols || ctx->cursor_y >= _ctx->rows) {
        return;
    }

    size_t i = ctx->cursor_x + ctx->cursor_y * _ctx->cols;

    struct flanterm_fb_char c;
    struct flanterm_fb_queue_item *q = ctx->map[i];
    if (q != NULL) {
        c = q->c;
    } else {
        c = ctx->grid[i];
    }
    uint32_t tmp = c.fg;
    c.fg = c.bg;
    c.bg = tmp;
    plot_char(_ctx, &c, ctx->cursor_x, ctx->cursor_y);
    if (q != NULL) {
        ctx->grid[i] = q->c;
        ctx->map[i] = NULL;
    }
}

this function

at line c = q->c;

[wicked loom]

i said disassemble

[surreal path]

oh okay

the first instruction?

it seems to gpf at the first instruction?

yea this instruction

stack trace looks like this?

this is um

very weird

why this instruction specically?

wait r13 has that weird ah address

00aaaaaa00aaaaaa

i think its trying to dereference this????

tf?????

why is it trying to dereference r13

whats going on

[tawdry mirage]

looks like you passed in colors by value and not by pointer again?

[surreal path]

img is a pointer

i pass in

[tawdry mirage]

0xaaaaaa looks like a color

[surreal path]

yea

[haughty kite]

or the 0xaa memset thats one line down?

your. kmalloc. is. broken.

[surreal path]

but i did that loop

and all the data

in that img array

is 0xaaaaaaaa

so how is it broken????

and ive checked what vmm_region_alloc gave

it gave a correct base virtual address

and the vmm_region struct holds the correct length for the region

[tawdry mirage]

show the full flanterm_fb_init invocation

[surreal path]

okay

volatile uint32_t *img = kmalloc(framebuffer->width * framebuffer->height * 4);
    memset(img, 0xaa, framebuffer->width * framebuffer->height * 4);
    // for (int i = 0; i < framebuffer->width * framebuffer->height; i++)
    // {
    //     if (img[i] != 0xaaaaaaaa)
    //     {
    //         serial_print("WHAT THE FUCK\n");
    //     }
    //     fb[i] = img[i];
    // }
    ctx = flanterm_fb_init(kmalloc, NULL, framebuffer->address, framebuffer->width, framebuffer->height, framebuffer->pitch, framebuffer->red_mask_size, framebuffer->red_mask_shift, framebuffer->green_mask_size, framebuffer->green_mask_shift, framebuffer->blue_mask_size, framebuffer->blue_mask_shift, img, NULL, NULL, &bg, NULL, NULL, NULL, NULL, 0, 0, 1, 0, 0, 0);

[haughty kite]

what if instead of 0xaa you use 0xbb

[surreal path]

okay sure

[surreal path]

now r13 is 00bbbbbb00bbbbb

faulting at same instruction

[haughty kite]

and also how many times do i have to repeat "your malloc is broken" until you accept your malloc is in fact broken

and that you should fix that

[surreal path]

because i like to cope

because allocator bugs are the bane of my existence

[haughty kite]

its honestly just annoying at this point

[surreal path]

yea okay so mallocs broken, memory corruption or something

is that it?

[surreal path]

its annoying that i keep having issues like this

hmmm

what if i dont give flanterm the image and just give it my malloc

no it doesnt fault

all these addresses malloc is returning look valid

so why is this memory corruption happening

why

[surreal path]

cant u see im trying to

[kind root]

lol

writing a working allocator is hard

i guess

[surreal path]

and why tf did it work under uacpi but failed with flanterm

[kind root]

who knows

[surreal path]

why is the memory getting corrupted

why tf

why do i always write shitty code