[SOLVED]printf/log fixes program, without it stales on net.recv

[frozen crane]

I'm creating a webserver using kqueue and core:net. I noticed a strange pattern that if I remove the printf/log from the event_loop (before the recv call), the program doesn't respond to the request. Is it possible that it's being tree-shaked? Any ideas how can I debug this?

The code is bigger than the example below, but the structure is similar to this. Any guidance is welcome!

handle_connection :: proc(server: ^Server, conn: net.TCP_Socket) {
    bytes_read: int
    err: Error
    buf := [PACKET_SIZE]u8{}
    bytes_read, err = net.recv_tcp(conn, buf[:])

    // rest of request handling
}

main :: proc() {
    running := false
    for running {
        err := eio.sync(&server.io) // read kqueue events
        if err != nil {
            log.debugf("Failed to listen to event: %v\n", err)
            continue
        }
        for i in 0 ..< server.io.n_events {
            event := server.io.events[i]
            // log.debugf("Event: %v\n", event) // If I uncomment this line, the program responds to requests

            switch event.filter {
            case .SIGNAL:
                if event.ident == uintptr(eio.Signal.SIGINT) {
                    running = false
                }
            case .READ:
                if event.ident == uintptr(server.socket) {
                    conn, source, err := net.accept_tcp(server.socket)
                    if err != nil {
                        log.debugf("Error accepting connection: %v\n", err)
                        continue
                    }

                    handle_connection(server, conn)
                }
            }
        }
    }
}

[cerulean fiber]

tree shaked? wdym

[frozen crane]

This https://en.m.wikipedia.org/wiki/Tree_shaking

But I have 0 confidence of that

[cerulean fiber]

odin does not do that if you run without optimisations

seems more like you have stack corruption or something and the debugf is moving things around

if you run this in the debugger you can follow what the code does

[slate tendon]

Yeah this looks a lot like stack corruption, pretty common if your bindings/syscall definitions are incorrect

[slate tendon]

Btw, you can look here at my kqueue implementation: https://github.com/laytan/odin-http/blob/main/nbio/_kqueue/kqueue.odin, to see if the bindings/api matches up

[frozen crane]

I'm following your implementation already, it's awesome, ty!

I found a bug in my application code, I wasn't closing the connection after the recv .Would_Block error. Setting the lldb debugger helped a lot!

I don't know if this makes sense, but maybe having the printf/logs before the recv sometimes was the necessary time for the socket to be ready for reading

[slate tendon]

Ah that could also be the case yes