IRC channel logs
2025-10-28.log
back to list of logs
<rlb>mwette: hmm, what's the issue -- I have an rpi4 here that I think has it, but I'd have to fire it up to see... <rlb>mwette: guile itself wasn't installed, but is now, and basics seem to be fine... <rlb>might also look in /etc/apt/preferences* in case ubuntu did something funny <rlb>I think mine's probably coming via <rlb>(the relevant sources entry) <mwette>the preferences say "Package: *" ; I'm guessing that is what I want to see; also "Pin: release o=UbuntuESM" <rlb>suppose it might be that pin -- I use pins sometimes, but I'm not an expert. <rlb>Sometimes also useful "apt policy". <rlb>"apt policy guile-3.0" <rlb>I've never really used ubuntu, so not sure how they handle things in general. <mwette>Thanks. I'll contact the h/w vendor (system76) tomorrow. <apteryx>old: oh, maybe the segfault is only visible at the REPL? from your comment "because the vector is being printed on the terminal." <apteryx>maybe I can alter its representation and try again <apteryx>because it sems the object itself should be protected in the guardian, and should perhaps be usable if not trying to read the memory it points to <old>apteryx: ya that's my guess. the repl is trying to print the bytevector <old>which results in segfault in my case because by default the protection is PROT_NONE <old>doing: (and (mmap ...) #t) do the trick for me <apteryx>I'm adding some print style logging to the pump handler to see what's going on <apteryx>using pk there doesn't seem to work for reasons <apteryx>while debugging, I switch to SRFI 69 hash tables, which have better introspection... but strangely, its own 'hash-table-exists?' fails on a weak hash table created with: (make-hash-table eq? hashq #:weak 'key) -> error: (wrong-type-arg scm_hash_fn_get_handle Wrong type argument in position ~A (expecting ~A): ~S (1 hash-table #<weak-table 0/31>) (#<weak-table 0/31>)) Guile bug? <apteryx>using hash-table-ref/default works as a workaround <apteryx>I think (hash-table-set! %unmapped-bytevectors bv #t) fails with a similar error <apteryx>maybe I need to use hash-by-identity instead of hashq as the hash function <apteryx>(define ht (make-hash-table eq? hash-by-identity #:weak 'key)) (hash-table-set! ht "something" 666) => In procedure scm_hash_fn_create_handle_x: Wrong type argument in position 1 (expecting hash-table): #<weak-table 0/31> :-D <apteryx>this must be a Guile tacked on feature <apteryx>hm, the same happens for native weak key hash tables when using 'hash-count': In procedure hash-count: Wrong type argument in position 2 (expecting hash-table): #<weak-table 0/31> <dsmith>Hmm. In the docstrings for srfi 69: Maybe s/Answer/Return/ ? <apteryx>old: I possibly found a bug with weak-hash tables/guardians; the weak-hash table is supposed to retain the value as long as the object is in the guardian. It's documented this way in the last paragraph of (info "(guile) Guardians"). My weak-hash table is always empty in the pump-mmap-guardian, just after the object is popped from the guardian. I can't its content before getting the bv out of the guardian because of issue #43 above. <apteryx>yep. easy to see with a minimal reproducer. bug report incoming <apteryx>in the 3rd paragraph actually: "as long as an object can be returned from a guardian it will not be removed from such a weak vector or hash table." <apteryx>so I think the SIGSEV I saw yesterday was just because of the the print representation of the bytevector trying to read dereference its pointer to print its content. In practice I see no segfault but I my hash table is always empty, so I can't prevent the double munmap/free. <apteryx>old: one thing about MADV_DONTNEED is that, similar to depending on the timing of the GC, we'd now depend on the behavior of the kernel ("Note that, when applied to shared mappings, MADV_DONTNEED might not lead to immediate freeing of the pages in the range. The kernel is free to delay freeing the pages until an appropriate moment." from man 2 madvise) <apteryx>so it seems still beneficial to allow manual munmap (but discourage its general usage due to the associated risks), for cases like MAP_SHARED mmap followed by file exec. <rlb>apteryx: my recollection is also that fadvise and/or madvise settings may be and sometimes are completely ignored by the platform (any given version of linux, *bsd, etc.). <rlb>i.e. aside from whatever posix requires, "they vary" -- iirc some versions of linux in particular did nothing for some of the requests. <rlb>apteryx: what version were you using when testing #44? <rlb>From a first (not sure it's right pass), it doesn't seem to happen here with the current debian version (3.0.11 plus some patches from main). <rlb>I'll try again later to double-check. <apteryx>maybe I can try it from a locally built guile <rlb>I'd say if you're up for it, yeah, be good to try 3.0.11 and/or main too. <rlb>(Though actually, I can probably do it soonish if you like.) <rlb>Another thing might be to check the 3.0.10 NEWS for anything suspicious -- if, say, it won't reproduce in 3.0.10. <rlb>Ahh, might have been repl vs not repl. <rlb>i.e. from the repl, the gc doesn't move important to the guardian, but from a script it does, and of course given that the gc's conservative, ymmv, I suppose. <rlb>When I run it via "guile test-guardian.scm", I do see #f at the end <rlb>before I didn't get past the (gc) step because I couldn't get it to move to the guardian. <apteryx>I reproduce in GNU Guile 3.0.10.264 + a few of my commits on top <rlb>yeah, I get the same result here now, with debian guile. <apteryx>I reproduce on main 3f02369484ba910f74d1ad25cf5911e490fed29f <apteryx>unless the build system is broken and won't rebuild things needed :-) <rlb>It did work for you from the repl too, though? <apteryx>I tested at the REPL with this local build of Guile too (./meta/guile) <rlb>Ahh, don't know if that's the same -- I was doing from the *real* (readline) repl :) <rlb>same here for main, so nvm <apteryx>I've commented the '=>' lines, for the next person (can just copy paste) <rlb>apteryx: you may have noticed, but the entry's gone from the hash table even before you pull it from the guardian -- unsurprisingly, it'd dropped by the gc. <rlb>Can see that by just (write ht) which goes from 1/31 entries to 0/31 after the gc. <rlb>Haven't looked at that yet. <apteryx>rlb: interesting, in my case it survived the (gc) <rlb>scm_i_identify_inaccessible_guardeds() is still in guardians.h, but never defined... <rlb>Here I put the (write ht) (newline) just before and after the (gc) <rlb>actually neither of those two functions are defined anymore... <apteryx>these functions were added in 06c1d9000 * gc-mark.c (scm_mark_all): Do not rely on hooks to run the weak hashtable and guardian machinery but call the relevant functions directly. <rlb>ACTION thanks dsmith again for the attack test not crashing <rlb>I think they may have been removed (one at least) when Ludovic added guardians. <rlb>Only two functions mentioned in guardians.h still exist. <rlb>was wondering how they work, then, but of course -- threeads :) <rlb>ACTION tries DEBUG_GUARDIANS <rlb>finalizing guarded 0x7f0cdeb18140 (1 guardians) <rlb>end of finalize (0x7f0cdeb18140) <apteryx>it's strange, I don't reproduce your findings that the weak hash table entry gets dropped just by (gc) <rlb>Looks like it doesn't with debian guile, but does with main (here). <rlb>If that really is just dependent on conservation, then many reasons it could vary. <rlb>But both still exhibit the final #f <apteryx>that's weird, it's like if calling (guardian) was running the mutator? <rlb>Now that's interesting -- I just had one run where at the very end: <rlb>i.e. after we show the copy, the weak table still claims to have an entry, but hashq-ref says no. <rlb>But I can't get it to do that again (i.e. re-runs all show 0/31 there). <rlb>That result suggests a problem with the weak hash table (at least). <rlb>Unless somehow hashq-ref is not quite right for the bitvector -- did you try just a plain integer or string? <rlb>Oh, better, a symbol <apteryx>object identity should be fine to check with eq?, I think? <rlb>Right, just wanted to simplify, and try variations. <rlb>Hmm, wait a minute -- are guardians supposed to hole on to weak *keys*? <rlb>i.e. if the value is in a guardian, then the weak key table can't drop the value (and so the key), but is the reverse supposed to be true? <apteryx>so in my example I'm relying on the fact that likely the gc does not in the little window of time between popping the value from the guardian and accessing it from the hash table <apteryx>maybe I should (gc-disable) and (gc-enable) to make sure. <rlb>But you don't put the value in the guardian, you put the key? <rlb>So you'd need a weak-value-hash-table for it to hang on? <apteryx>for a weak-key hash table, if the key is kept, the value is kept. <rlb>i.e. you're key's weak, and so being in a guardian has no effect? <rlb>Oh, I got it backward? <apteryx>> In other words, a weak link does not prevent an object from being considered collectable, but being inside a guardian prevents a weak link from being broken. <apteryx>3rd paragraph of (info "(guile) Guardians") <apteryx>4th paragraph also says "A key in a weak key hash table can be thought of as having a strong reference to its associated value as long as the key is accessible." <apteryx>so at least running (gc) while the key is in the guardian should not cause this key to be dropped from a weak-key hash table, IIUC. <rlb>Sure, though I could also read the 4th as saying that if the weak key is only in the guardian, then the value is eligible to be returned from a guardian too? <rlb>i.e. the value is gc-able whenever the key is <rlb>just checking my understanding <apteryx>and then I'd expect the key to not vanish immediately, only on the next (gc) <rlb>gc can happen "any time" in theory <rlb>well not *any* time :) <apteryx>otherwise how would we use weak hash tables in conjunction with guardians? :-) <rlb>I'd be a bit happier if that final "it" in the last paragraph was just "the value" (again)). <rlb>(but most likely interpretation is "the value" by proximity :) ) <rlb>But the rest of the paragraph is talking about the key being in a guardian, not the value. <rlb>In any case, I did think about the "race" you mention, but if that actually existed, I think it'd be a bug. <apteryx>my use case is tacking some extra information (e.g, state) to an object held in the guardian, and acting on that information at the time the object is retrieved from the guardian <apteryx>with the extra information associated to the object via a weak-key hash table <rlb>I'm actually getting #f from the guardian *and* #f from the hashq-ref. <rlb>While the weak table is still 1/31 <rlb>Oh, wait, that means that my symbol example is working correctly? <rlb>i.e. guardian returns #f, and so of course the hashq-ref fails because #f isn't a key in the weak table. <rlb>Oh, but that's a dumb example because the symbol won't ever be gced -- has to be something more complex. <apteryx>I got tricked by that once, but the example currently uses the object as returned by the guardian, so should be OK, assuming the object in the guardian and in the key is the very same object <rlb>cons pair works too ((cons 1 2) to demonstrate the problem). <rlb>right, but when I use a symbol, it's never gc'ed (of course?), and so the guardian will never return it <rlb>(cons 1 2) is more ephemeral, and so works too <apteryx>with an actual use case demonstrating the problem <rlb>I'm still not sure I understand exactly what's intended wrt guardians here -- i.e. I'm still not certain that it's not saying that once they key is only available via a guardian, the value is collectable. <rlb>And if that were so, then the next to last paragraph would be saying that the weak link won't be broken if the *value* is still accessible from a guardian. <rlb>Dunno -- might need to read the paper, and/or badger Ludovic. <apteryx>the paper mentions and showcases the use of both guardians and weak hash tables together, saying they complement each other well. <apteryx>so I would assume the interpretation of the doc is that as long as an object is in the guardian, the object remains in the weak hash table <apteryx>(with the kind of weak hash table depending on whether you use the guarded object as the key or value) <apteryx>but the presence of the object in a weak hash table does not hinder the guardian from returning said object <rlb>I understand, and I'll have to read more carefully later (or just let you and Ludovic handle this), but my question was whether "an object is in the guardian" might only apply to the value for a weak key hash table and the key for a weak value hash table. <rlb>i.e. not to the key for a weak key hash table. <rlb>It may also be that what I'm wondering doesn't make sense -- I'll have to wait until after I get some sleep to try to figure that out :) <apteryx>rlb: thanks to checking the issue and entertaining this discussion! <tohoyn>daviid: G-Golf example programs print some EGL errors in Debian unstable, see https://paste.debian.net/1403134/. Theme-D-Intr calculator example program has some rendering errors in Debian unstable and I suspect these may be related to the EGL errors. These problems do not occur in Debian stable (trixie). <kestrelwx>rgherdt: Hi! I just realised some functions have overloads. :o <morenonatural>hi, how should I write entries to a port that are "nul-char separated" to be further processed by a command like `xargs -0` <dsmith>morenonatural, Also, Guile strings are counted, not NUL terminated <dsmith>$ guile -c '(for-each (lambda (x) (display x) (display #\nul)) (list "foo" "bar" "baz"))' | hd <dsmith>00000000 66 6f 6f 00 62 61 72 00 62 61 7a 00 |foo.bar.baz.| <euouae>apteryx: still working on the ELF re-do, just letting you know. It's going well. <rlb>Hah, yeah, I assume so. <jralls>Then it's indeed your fault that I'm here! ;-) <rlb>This is trying to build guile on windows? <jralls>Yes, Mingw64 in particular, where sizeof(void*) is 8 but sizeof(long) is 4. <rlb>And are you trying to build that pr itself, or those commits rebased onto something else? <jralls>Those commits plus two more additional fixup commits onto main from a few days ago. <rlb>(I'm not very knowledgeable wrt the mingw64 aspects, just wanted to make sure it couldn't be the known issues we had in 3.0.10.) <rlb>OK, so then sorry, "no real idea" :) <rlb>(I've never worked with guile there (32 or 64-bit).) <jralls>IIUC the problem is that bytevector-u32-native-set! expects arg 3 to be mangled by left-shifting a couple of bits and then stuffing a value into opened-up bits to indicate a type. So my question is how do I figure out where that value is coming from? <rlb>Sure, if it's expecting a fixnum, that sounds right. <rlb>(e.g. SCM_I_MAKINUM in numbers.h) <jralls>Right, via scm_integer_from_int64 in integers.c. <rlb>Is that pr supposed to work fine on 64-bit? <rlb>You may know, but I believe there are some related threads on the list. <jralls>I can't tell from the discussion. If I'd submitted a PR that didn't work I'd explicitly say so and the point would be to ask for help. That's not apparent. <jralls>What list and where's the archive? <rlb>ArneBab may well know whether it's expected to work (if it's not already apparent from the pr). <rlb>"though it spans months" <rlb>It could also be that the pr has collected all the relevant info, I just haven't been following it since I have very little relevant experience with the platform. <jralls>That seems to be the lead up to the PR. There doesn't seem to be anything this month so I guess that PR22 and PR23 are the current state of play on the topic. <rlb>Well, regardless, thanks for the extra eval/testing. <ArneBab>jralls: please get in contact to Jonas (from the PR): itβs the lilypond folks who are driving Windows support forward. They have more patches. The PR is about moving towards proper Windows support again. <jralls>ArneBab, thanks. I'll start by looking at their repo for more patches. <ArneBab>Good luck! They are the ones with most experience in getting stuff on windows to work well. <jralls>ArneBab on PR22 you question the safety of scm_from_unsigned_integer in hash.c but it's just an alias for scm_from_uint64. What's the concern? <jralls>With the other lillypond patches I got an inscrutable segfault in jit.c so trying again with jit turned off... <jralls>Stuck again. With all of the lillypond patches applied and jit disabled it gets well into stage1, but compiling return-types, rotate-loops, and self-references in language/cps all segfault. <jralls>Running in gdb doesn't work because it won't load the file: "ice-9/read.scm:129:4: In procedure lp: #<unknown port>:1:5: unexpected end of input while searching for: )". <daviid>apteryx: g-golf used to use guardian and a weak hash table, to keep track of proxi instances and do the right thing when unreachable on the scheme side (basically call gobject-unref) ... I no longer use that, I switched to use the toogle reference mechanism provided by GLib/GObject ... but I can tell you that in the situation that the weak hash table entry value is the scheme object (so, not the key), then when the after-gc-hook code <daviid>do not need to remove the waek hash table entry, by the time the code runs, it has been removed already- fwiw <daviid>sneek: later tell tohoyn this has nothing to do with g-golf, those warnings are being emited by the low level renderer you (or the system) choosed to render ... I'll ask for some hint in #gtk, but I can't promiss I'll get an answer <daviid>sneek: later tell tohoyn can you launch the search-bar example, then hit Ctrl-Shitf-i, then in the inspector, go to the upper object (the GtkPaplicationWindow), then select the Global (header bar tab), then scroll down to the GL Renderer related entires, take a screenshot and posted somewhere, thanks <mwette>rlb: btw my ubuntu apt started all working the next day; vendor said it can take a while for the release files to download. 
