IRC channel 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 ;-)

<wingo>:)

<nalaginrut>thanks

<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

<nalaginrut>ok

<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

<wingo>ah

<wingo>hmm

<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 :)

<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

IRC channel logs

2016-11-24.log