search

staab / janet-pqutils

A utility library for Janet and janet-pq.
MIT License
8 stars 0 forks source link

Fix segfault #7

Closed staab closed 4 years ago

staab commented 4 years ago 
UndefinedBehaviorSanitizer:DEADLYSIGNAL
==11071==ERROR: UndefinedBehaviorSanitizer: SEGV on unknown address 0x7f94ecbfb240 (pc 0x7fff633066f2 bp 0x7ffeea954ae0 sp 0x7ffeea954ae0 T7799094)
==11071==The signal is caused by a READ memory access.
    #0 0x7fff633066f1 in _platform_strlen (libsystem_platform.dylib:x86_64+0x16f1)
    #1 0x1052d2c02 in janet_cstring (janet:x86_64+0x100028c02)
    #2 0x10532c1b3 in populate_oids (core.so:x86_64+0x11b3)
    #3 0x10532c74f in cfun_exec (core.so:x86_64+0x174f)
    #4 0x1052dcea3 in run_vm (janet:x86_64+0x100032ea3)
    #5 0x1052ddbdd in janet_continue (janet:x86_64+0x100033bdd)
    #6 0x1052dd14e in run_vm (janet:x86_64+0x10003314e)
    #7 0x1052ddbdd in janet_continue (janet:x86_64+0x100033bdd)
    #8 0x1052cf981 in janet_dobytes (janet:x86_64+0x100025981)
    #9 0x1052df7f4 in main (janet:x86_64+0x1000357f4)
    #10 0x7fff6311e3d4 in start (libdyld.dylib:x86_64+0x163d4)

==11071==Register values:
rax = 0x415ad6da00000000  rbx = 0x415ad6da00000000  rcx = 0x00007f94ecbfb240  rdx = 0x00007f94ecbfb240
rdi = 0x00007f94ecbfb240  rsi = 0x00007f94ec400000  rbp = 0x00007ffeea954ae0  rsp = 0x00007ffeea954ae0
 r8 = 0x0000000000000006   r9 = 0x0000000000000000  r10 = 0x0000000000000007  r11 = 0x0000000000000007
r12 = 0x00007f94ec634ec0  r13 = 0x0000000000000011  r14 = 0x00007f94ecbfb240  r15 = 0x00007f94ec502d01
UndefinedBehaviorSanitizer can not provide additional info.
==11071==ABORTING
staab commented 4 years ago

This might be a result of not marking stuff properly for gc. See fced73a for a possible solution. We might also need to either use refcounts or store references to active Results on the corresponding Connection, then when the Connection gets gc'd close the active results first.

staab commented 4 years ago

To re-state in @bakpakin's words: an open requests counter on the connection could do that. The request object finalizer would decrement the counter on the connection, and if it was 0 and the connection was closed, only then actually clean up the connection. The connection finalizer would similarly decrement the counter, and only Pq free or whatever the connection if the counter was 0.

bakpakin commented 4 years ago

As of 1.6.0, if two values are freed in the same GC cycle, they will be freed in the reverse order they are allocated (LIFO). This is not guaranteed by the API, but by the current implementation. It also means we don't need to mess with counters or the like right now - the finalizer for a connection will always run after the finalizer for a request if the connection is allocated first (which it must be, as it is used to create the request).

staab commented 4 years ago

Cool, so I think the basic structure of core.c is good for now then. The above segfault obviously isn't related to the gc issue, and I haven't hit it in a while, so closing this for now.