IRC channel logs


back to list of logs

<MoronicAcid>Anyone have tips to troubleshooting a call to load-extension that kills the REPL session?
<MoronicAcid>for troubleshooting*
<nalaginrut>wingo: I'm trying to parameterize the suspendable I/O waiters, how can I throw EAGAIN when it's blocked?
<wingo>(parameterize ((current-read-waiter (lambda (port) (throw-my-error-here)))) ...)
<wingo>also for current-write-waiter
<nalaginrut>wingo: but I have to throw when it's going to block, how can I check that?
<wingo>if the waiter is called, it means the call would block
<nalaginrut>the preferred operation is: read some bytes -> encounter blocking -> throw EAGAIN, my understand is that Guile I/O won't throw EAGAIN for me, so I have to do it myself (according to suspendable-ports module comment), is that right?
<nalaginrut>wingo: if Guile doesn't throw EAGAIN for me, how can I know it's going to block before it's already blocked
<nalaginrut>maybe I don't understand suspendable-ports correctly ;-P
<nalaginrut>wingo: well, do you mean Guile I/O will call the waiter when it's going to block, so I just throw EAGAIN in waiters simply?
<wingo>the last thing you said :)
<wingo>guile calls the waiter when it's going to block.
<wingo>provided the fd was put into nonblocking mode
<wingo>so your waiter should just throw an exception
<nalaginrut>wingo: nice, it seems work, but I need more elegant design to take advantage of this mechanism ;-)
<nalaginrut>wingo: BTW, do you think this would be a correct format to throw EAGAIN: (scm-error 'system-error "async-read" "~A" (list (strerror EAGAIN)) EAGAIN)
<nalaginrut>I'm not sure about the preferred format to throw system-error
<wingo>i have no idea tbh
<wingo>i always have to look at source :P
<wingo>i suggest causing an error and seeing what it raises
<wingo>what keys and values i mean
<nalaginrut>ok, maybe it's better to make a convention in the manual? since the users have to throw system related exception by themselves
<nalaginrut>if users do according to the convention, they may use system-error-errno, but it's fine if they want to use their own format, IMO
<lluis>hi there, I'm having a weird error with a program that embeds guile; when I call scm_with_guile, function GC_mark_from ends up producing a SEGV against a mapped memory region that has no access permisions (the region is right before the heap)
<lluis>my web search foo did not return any results pointing to the source of the problem; ideas?
<lluis>oh, the main thread is faulting here, and there is only another thread not created by guile/gc, which is used by librcu
<lluis>sorry, liburcu
<lluis>the issue is, how to I tell guile/libgc to ignore memory mmaped by the main program?
<daviid>match rocks!
<wingo>lluis: is the segv captured?
<wingo>there is an initial phase where libgc discovers the stack boundaries where it will produce a segv i think
<wingo>but handled
<wingo>i.e. does it kill your program or are you just seeing that in gdb
<lluis>wingo: no, I made sure there's no SEGV handler from the program, so it gets killed
<wingo>it sounds like a libgc bug to me tho
<lluis>the actual probem is that the program performs some memory allocations, and then mprotects them to disable access as a buffer overflow measure
<lluis>when GC_init tries to scan the program's memory, it cannot access that region
<wingo>and they don't contain pointers to heap-allocated data i guess?
<lluis>I don't know why GC_init is scanning the whole thing, though
<lluis>they should be all zeroes, since it's a freshly allocated buffer that is munpretected
<wingo>see GC_exclude_static_roots maybe
<wingo>but more generally i suggest writing the libgc mailing list
<lluis>I'm looking into that, but seems weird libgc scans all the process's memory, instead of only the gc allocations and thread's stacks
<wingo>it scans "data" sections too
<wingo>so that static SCM foo = bar is scanned
<wingo>but i mmap many things and don't run into this problem, so i wonder what's up with that
<lluis>I think it's the zero protection in them (i.e., cannot be written *nor* read)
<lluis>it's just to ensure the program segfaults if you go beyond one of its buffers
<wingo>could simply be a libgc bug
<lluis>I'll contact the libgc people, thx
<wingo>np, happy hacking
<lluis>in the meantime, I hope GX_exclude... will to the trick
<lluis>wingo: BTW, switching my code to guile 2.2 was worth the effort :)
<wingo>oh i'm glad to hear that :-)
<wingo>how did it go?
<wingo>i want to release soon; i think i'm done with everything on my stack
<lluis>the generated code is correct in all cases, and cleaner in some aspects
<amz3>hélllllllloooooooo #guile :)
<wingo>good evening amz3 :)
<lluis>wingo: the problematic memory region *is* on the data section (my bad for not realizing before), so that tells why libgc is going through it
<wingo>ah, interesting
<artyom-poptsov>hello amz3 :-)
<amz3>What do we wait to conquer the world and its surroundings?
<lluis>is it correct to call scm_init_guile on a thread the first time it uses guile's functions? Even if it will later call guile's functions from some other function in my program? Or do I always *have* to use scm_with_guile?
<wingo>scm_with_guile is the recommended interface
<wingo>not sure if that answers the question :)
<lluis>not really, I understand scm_with_guile can discover the thread's stack, assuming any previous frames will have no SCM values (unless nested)
<lluis>but what happens if I use scm_init_guile?
<lluis>will that confuse libgc?
<lluis>Example: main -> f1 -> f2 -> scm_init_guile & something
<lluis>then: f1 -> f3 -> something more with guile
<wingo>i think it won't confuse libgc.
<lluis>aha, then I guess it's correct, and therefore don't understand the use for scm_with_guile