IRC channel logs


back to list of logs

<old>there is for sure an infite loop in libgc
<old>would need to rebuild it with debug info to determine where
<apteryx>this kind of loop can happen in Guix when there is a cycle in the packages graph
<apteryx>it seems like replacing pkg-conf by pkgconf triggers such a loop, though I haven't figured out why yet
<apteryx>the only hint I have is that when issuing ,build pkg-config at the REPL, with (set! %load-verbosely #t), I see: ;;; loading [...]gnu/packages/commencement.scm
<apteryx>in (gnu packages commencement) gnu-make-final uses a package variable at the top level, which is not a good thing for module cycles, but modules seem to load fine here.
<apteryx>(it uses %pkg-config)
<apteryx>why would something fail only when used with ,trace ? the error is: In procedure primitive-call-ip: Wrong type argument in position 1 (expecting PRIMITIVE_P): #<procedure 7fac587ea640 (_ _ _)>
<apteryx>old: I think I've found how to debug this, using the REPL: ,trace (with-store store (run-with-store store (lower-object pkg-config))
<old>why is a cycle making the garbage collector go into an infinite loop?
<old>this does not happen with circular structures AFAIK?
<apteryx>old: the memory keeps growing; perhaps it's eating the stack?
<old>which memory?
<old>if there's sbrk or mmap syscall with strace then it is not the stack
<old>and typically if there a recursion problem the amount of memory quickly explode and the program crash
<jmes>Is there a string->sexp function provided somewhere? Maybe an ice-9 module?
<Arsen>(call-with-input-string "(foo bar baz)" read)
<jmes>Arsen: yeah I guess that'll do it!
<Arsen>that was actualy more elegant than I anticipated :-)
<jmes>At least I don't have to tell you explicitly that I'm not a good guiler :P
<Arsen>much the same here ;P
<jmes>Haha, well, thanks. I'm working on a config file template thingy to extend guix home... Probably something more advanced already exists (maybe in mainline guix or rde), but whatever.
<old>reading this:
<old>would it be possible to avoid to duplicate the defintion of foreign bindings?
<old>Having to declare it once in scheme and once in javascript for wasm is redundant. Anyway to speed up this process?
<merlin0170>Hello, could anyone help me with a problem I am having with Guile scheme? I keep running into a problem when I try to assign the value of a variable within a letrec block with the value of another variable within the same letrec block. I get wrong type to apply: #guile<unspecified>
<mwette>I guess you are assigning from a function that does not return anything. Can you show the code (e.g., post to and share the link here).
<apteryx>old: there were mmap syscalls yes, I think
<apteryx>but mostly futex
<mwette>maybe try call-with-stack-overflow-handler ?
<mwette>or use vm hooks to trace filename/linenumber (from passed frame)
<mwette>(let ((src (frame-source frame))) (source:file src) (source:line source))
<old>apteryx: I see it here. Tons of mmap and futex
<old>to me that's sound like an infinite loop that keep adding stuff
<old>GC Warning: Repeated allocation of very large block (appr. size 29908992): May lead to memory leak and poor performance
<old>apteryx: here this could help
<old>oops sorry made a syntax error
<old>if the first argument to `append' is a circular-list, you get the same behavior
<old>not if the circular list is the second parameter
<old>apteryx: this is the behavior you have:
<old>so something in the guix store is appending a circular list to something else. I guess you were right, there's a circular dependency somewhere
<mwette>according to find+grep, there are only two set-cdr! in guix/guix/
<mwette>one in guix/guix/derivations.scm, coalesce-duplicate-inputs