GC.free type missmatch compiler error

[CausticKirbyZ]

When trying to use the client's query function, the macro expands to use the incorrect pointer type.

compiler command: crystal build kuzu_test.cr -p compiler error:

Showing last frame. Use --error-trace for full trace.

There was a problem expanding macro 'macro_140075884361136'

Code in lib/kuzu/src/kuzu.cr:239:3

 239 | {% begin %}
       ^
Called macro defined in lib/kuzu/src/kuzu.cr:239:3

 239 | {% begin %}

Which expanded to:

 > 14 |   end
 > 15 | ensure
 > 16 |     GC.free pointerof(__temp_1072)
                    ^
Error: expected argument #1 to 'GC.free' to be Pointer(Void), not Pointer(LibKuzu::Value)

Overloads are:
 - GC.free(pointer : ::Pointer(Void))

system: Arch Linux kuzu version: 0.6.0.2 (self compiled) crystal version: 1.13.2 kuzu shard installed with shards.yml and shards install test crystal code:

require "kuzu"

struct Company < Kuzu::Node 
  getter name : String = ""
end 

kuzu = Kuzu::Client.new("kuzu.db")

kuzu.execute "CREATE NODE TABLE Company( name STRING, PRIMARY KEY (name))"
# up to here the code compiles and executes normally 

puts "Adding 1000 companies..."
10000.times do |i|
  kuzu.execute "CREATE (c:Company { name:\"#{cname}_#{i}\"} )"
end 
# the code executes through here fine without issues. and when loaded into a separate view client the data is valid.

puts "Querying the companies to print the names"
kuzu.query "match (c:Company) return c", as: { Company } do |(comp)|
  p! comp
end 
# if you comment out the kuzu.cr lib line that causes the compiler error the resulting compiled binary crashes in the above loop

happy to supply more info if needed.

[jgaskins]

Ahh, yep, I used GC.free instead of LibC.free. I had this fixed locally, but hadn't yet committed it. I had to step away from working on this shard because the underlying Kuzu library had just made a bunch of changes to its C API but hadn't yet cut a release with those changes, so I was working against a snapshot of code I wasn't confident was stable.

I fixed this part in d75d36e, though.

if you comment out the kuzu.cr lib line that causes the compiler error the resulting compiled binary crashes in the above loop

This does reproduce locally for me. This was caused by my confusion around the out keyword in Crystal and seeing memory usage increasing over time. I assumed I wasn't freeing memory. It seems like Crystal does free memory allocated by out, though — I can't imagine another reason we'd be seeing that double-free error here. I'm still not sure about it, though. I need to look more into it.

[CausticKirbyZ]

I updated my code for the changes you made. it is now triggering a runtime error of free(): invalid pointer when running a query that returns data. Im not sure if this ties into the double free method you mentioned. but wanted to provide update/provide more info.

Once the program hits this point the program becomes unresponsive and even trying to kill via SIGKILL is extremely delayed.