IRC channel logs
2024-02-03.log
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>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>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 <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>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 paste.debian.net and share the link here). <apteryx>old: there were mmap syscalls yes, I think <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>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