Running twice gives error

[restive salmon]

i've been trying to figure this out for a few days now, it's probably a memory leak, but i'm not sure.
i'm hoping someone can give it a look over and lead me down the right track.
heres the playground link:
https://playground.modular.com/user-redirect/?hubshare-preview=OTA0YjMzOWMzMjI5MzllNjQwYTUxYTgyYjg3M2YwMzFhNTVkMmQ5MzU3OWUxOWFiMmFkMGU0NmJlZDA5NWFhNi9VbmZvbGRlcjJlbGVjdHJpY2Jvb2dhbG9vLmlweW5i

sometimes, when i hold my tongue at the right angle, it gives the correct output for step [1,1,1], so i know the proccess is mostly working

[primal epoch]

It seems to me like you have a copy constructor and a move constructor. I don't see you using the ^ operator so you seem to be copying these a lot

You seem to be doing reference counting so I don't think that's a memory leak

but you array accessors don't seem to check the reference count

Are you intentionally trying to achieve shared mutable state here?

Because that can lead to very unpredictable behavior as you modify the same underlying storage in multiple places

[zealous vector]

Congrats @primal epoch, you just advanced to level 11!

[restive salmon]

what do you mean by this? i've tried doing some of the other stuff you mention

[primal epoch]

Well when you copy the array (and increase the reference count) you solve the problem of a double free.

But you still have the problem of shared mutable state, now you have 2 arrays that point to the same memory

if you try using both at once, like write something from one array into the other, but they both point to the same storage, you will be mutating an array while also reading from it

A copy must mean creating a new array.

what you can also do is copy-on-write, meaning you defer this operation to when trying to mutate an array, i.e. before writing to it your accessor should check if the reference count is greater than 1, if so copy

This is a danger in reference semantics based languages. The Objective-C array has a warning that you may not under any circumstances read and modify the same array if I recall correctly

[restive salmon]

when i do:

var arr = Array[Int](size)
arr = Array[Int](new_size, arr)

@always_inline
fn __init__(inout self, size: Int, owned array: Self): # owned array for the case of infinite self reference (self = array)
    self._size = size
    self._rc = Pointer[Int].alloc(1)
    self._data = Pointer[T].alloc(size) # uses the size defined localy
    self._rc.store(0)
    self.copy(array)
    self.clear(min(size, array._size), size)

@always_inline
fn copy(self, array: Self):
    memcpy(self._data, array._data, min(self._size, array._size))

[primal epoch]

I don't think you're using this anywhere

Wouldn't you have to use the ^ operator to pass ownership?

I don't see you using that operator anywhere

[restive salmon]

i tried using that it doesnt do much if the variable isnt used afterwards anyway

[primal epoch]

I think if you don't use it it's going to pass a copy instead of consuming it

I would have to check though

[restive salmon]

if you had to guess, is the problem with the containers, or the graph?

[primal epoch]

Well you're saying it fails if you use it twice right

I would assume that's a memory bug with the array itself, since you're copying it

[restive salmon]

also depending on how i use it, it might fail

ok

[primal epoch]

Yeah that doesn't seem great

you could try checking for out of bounds access just in case too

unless you're doing that aready

[restive salmon]

oh yeah thats a good point, didnt even htink about that

[primal epoch]

Yeah I've had weird bugs in languages like Zig, and turning on the ReleaseSafe mode (which does bounds checking) would often help me find those

I think you can use debug_assert for it, I used it for the Optional

fn unwrap(self) -> T:
    debug_assert(self.is_some(), "Unwrapped a none value")
    return self.raw_value

it's imported automatically

[broken hawk]

This is one interesting case that reminds me of early days of rust becoming mainstream and many users still confused about how ownership and borrow works in it.

This conversation here could be elaborated to become a full insightful look at the same with Mojo.

Do it, @primal epoch.

[restive salmon]

does this have anything to do with currently missing features?

[primal epoch]

In a sense.

the most primitive structures like smart pointers or arrays are very difficult to get right with an ownership system

[restive salmon]

i've made a few already that worked fine

[primal epoch]

Yeah, what I mean is ownership provides guanrantees when you're using things, but it's known to make "unsafe" operations harder

And the thing about UB is that it sometimes can work

it's hard to know from testing if something is actually correct

[restive salmon]

i was originally having the graph own all its containers, but i was running into even more issues there

and non mutable, ect..

[primal epoch]

What I'm trying to say is that your container needs to be designed in a way where even though you manually implement it it still respects all the assumptions the compiler is going to make.

[restive salmon]

i decided to do it this way bc i figured the ownership features werent ready yet

[primal epoch]

Lifetimes are not, ownership works

an example:

from list import List

fn consume(owned list: List[Int]):
    pass

fn main():
    let list: List[Int] = [1, 2, 3]
    consume(list^)
    print(list[0])

the error messages are not very good but this will not compile

but that's because the list does not have __copyinit__

I am forced to use ^ here to consume it

If you make it copyable you will have to do extra work to make sure no mutable state is shared

[restive salmon]

originally i had all move only

and cosuming

but i couldnt get as far

[primal epoch]

Well I unfortunately don't know what you did that caused problems in that case

If you have a link I could try to see

You could just try doing something simpler with your array before you try and go this far

first make sure everything works individually.

[restive salmon]

thats how i started, there is a section where i tested all the arrays features, and everything works.
i may go back and try to get some other patterns working like you mention

[primal epoch]

It's a bit early for Mojo to have detailed explanations on this so you can reference Rust's

Such as this https://doc.rust-lang.org/nomicon/aliasing.html

There's a lot of explanations why pointers in languages like Rust, Mojo, Swift etc are "unsafe" to use

[restive salmon]

yes, unfortunately it's not easy to wrap unsafe code safely rn, but my containers dont have any problems in my tests

[primal epoch]

What are you testing?

[restive salmon]

it's features

[restive salmon]

oh theres some textual errors there, but the code lines up

[primal epoch]

Do you test if changes to one table affect another?

I will copy the code and see if I can find what's happening

[primal epoch]

fn main():
    var table: Table[Int] = Table[Int](5, 5, 0)
    var table2: Table[Int] = Table[Int](table)
    
    print("table1")
    print(str(table))
    print("table2")
    print(str(table))
    
    table[Ind2(2,5)] = 5
    
    print("table1")
    print(str(table))
    print("table2")
    print(str(table))

This has undefined behavior

Sometimes it crashes

sometimes not

and I'm not seeing changes in the tables it's printing

Am I using it wrong?

[restive salmon]

works fine for me, but your index is 5, and your length is 5

so your setting out of bounds

[primal epoch]

Oh

yeah

[restive salmon]

i have a few things imma try

[restive salmon]

i put bounds checks on everything, but it still only shows a problem when run twice.

i also move the process out of the graph container, and made it move-only and being consumed for use, thought that might work but ig not

it gives an out of bounds on the second run, but not the first

is that normal?

[restive salmon]

all the code is inside a function

i think i've narrowed it down to here but that might just be where the issue is showing itself

[restive salmon]

wait why is my lb_to_id() wrong now? it wasnt before 🤔

[restive salmon]

🧐

[restive salmon]

im not sure i was accounting for the final pop, but theres still an issue

[restive salmon]

can this be done currently

[primal epoch]

Is there a reason it shouldn't be? I would have to understand what's happening in most functions to say what's wrong :/

It's probably one line of code hiding somewhere 🙂

[restive salmon]

because it's a new language

[zealous vector]

Congrats @restive salmon, you just advanced to level 6!

[restive salmon]

think i got it

[primal epoch]

What was it?

[restive salmon]

thanks for some of the help

had to keep the trace and mask alive long enough

[primal epoch]

oh they were destroyed too early?
Didn't you have reference counting?

I guess lifetimes aren't working yet so this is more difficult than it has to be

[full dragon]

anyway can you share your codes in a gist or something?

using the playground, i am unable to see the codes

[restive salmon]

will do

[restive salmon]

@full dragon https://github.com/helehex/mojo-test