IRC channel logs


back to list of logs

<mark_weaver>Madsy: one issue is that when cross-compiling, the autoconf tests can't work properly. They might be making wrong guesses.
<Madsy>Afaik, there isn't any alternative makefile for libgc, but sure
<Madsy>I've done my best to inspect the configure logs
<Madsy>For w32-pthread I've tested prebuilt binaries just to be sure
<Madsy>The only other makefile I've seen recommended for libgc is, but it seems like it is made for MinGW on Windows
<Madsy>mark_weaver: Also, the libgc tests pass. That has to count for something.
<Madsy>And the deadlock in guile happens consistently in the same place, both on Vista 32-bit and Windows 7 64-bit
<Madsy>So I'm getting more certain this is a bug with guile. If it isn't, then the libgc and w32-pthread tests are lacking
<mark_weaver>I think it's premature to make predictions about where the bug is, but in any case, we need to know what the bug is in order to fix it.
<mark_weaver>if there's a deadlock, we need more information about which locks are involved.
<mark_weaver>regarding autoconf tests, I was actually referring mostly to guile's configure script, which tests for several functions in libgc.
<Madsy>I have a stacktrace and gdb log. It consistently happens inside GC_grow_table, invoked by scm_init_strings
<mark_weaver>probably most (or all) of the GC_* functions that it looks for will be in 7.2e, but it might be assuming that they're not present.
<mark_weaver>Madsy: thanks, but that's still not enough information.
<mark_weaver>For starters, 'scm_init_strings' does a lot of stuff. it calls 'scm_i_make_string', and also a bunch of other initializers from libguile/strings.x. which of these things was it doing when it got stuck?
<mark_weaver>scm_i_make_string uses scm_i_pthread_once, and does allocation within the associated init function 'init_null_stringbuf'. Is that where the deadlock is happening?
<Madsy>Nope. It happens deep inside a call to scm_string_to_symbol called at strings.x line 21. As far as I know, the last good call is to GC_grow_table which never returns. I tried to set a breakpoint there.
<Madsy>I'll try building 2.0.9 tomorrow and see if I have any luck there. But I'm currently out of ideas until someone can confirm whether my GC library is fine or not :)
<davexunit>so I started using guile-json and I like it, but I don't like that JSON objects are represented as hash tables instead of alists.
<davexunit>and I found quite a long thread on the ML in which hash tables were argued about at length.
<davexunit>and I still can't tell whether or not hash tables were the right choice for guile-json
<davexunit>to me they are a suboptimal choice because they aren't as convenient to inspect as alists.
<nalaginrut>morning guilers~
<b4283>nalaginrut: morning
<civodul>Hello Guilers!
<wingo>morning civodul
<civodul>hey wingo
<janneke>anyone have a nice piece of elisp for me to do: (or (geiser-edit-symbol-at-point) (find-tag)) bound to M-. ?
<janneke>geiser killed my tag lookup
<janneke>and M-,
<wingo>jao doesn't seem to be around
<dsmith>wingo, Morning greets. BTW, I get the exact same numbers in the signals.test ERROR messages on my 32bit laptop and the 64 it machine at work.
***cluck` is now known as cluck
<wingo>greets, mark_weaver
<mark_weaver>hi wingo!
<Madsy>hey both :)
<Madsy>mark_weaver: You might have been right yesterday. I found out guile's ./configure didn't pick up _GC_pthread_cancel, _GC_pthread_exit or _GC_pthread_sigmask.
<Madsy>That might have something to do with it. I'll investigate that tonight.
<Madsy>Which is weird, because I checked w32-pthread's exports, and it has pthread_cancel and pthread_exit
<Madsy>Though I know that pthread_cancel can't actually cancel blocking threads on Windows without an additional driver
<Madsy>I'll have to check if I can get w32-pthread to build with sigmask support as well
<Madsy>I thought the testsuite I ran tested those functions. So sorry if I was bold/assertive yesterday
<mark_weaver>Madsy: ./configure tests most of those things by compiling little test programs and running them. obviously that can't work when cross-compiling, so it makes a guess.
<mark_weaver>sigmask will definitely be needed.
<mark_weaver>I wouldn't worry about pthread-cancel though.
<Madsy>mark_weaver: Actually it doesn't run the programs. It only checks if gcc returns 0 or not
<Madsy>So it's not guile ./configures fault. libgc didn't export those functions for some reason I've yet to figure out
<mark_weaver>ah, okay
<mark_weaver>maybe libgc's configure didn't find them for a similar reason?
<mark_weaver>s/them/some functions/
<Madsy>I didn't find any relevant flags in libgc's config.log. I must be missing a #define used in gc.h or similar
<mark_weaver>it might be worth trying libgc 7.4.
<Madsy>That will be plan B
<Madsy>I'm writing down all my efforts. Maybe that would be nice to have in the INSTALL or README file
<Madsy>If it ends up working
<mark_weaver>yes, it should definitely be documented somewhere.
<mark_weaver>given how cheap libgc is to build, I'd think that it would be worth checking to see if it exports those missing functions before digging into the libgc source code.
<mark_weaver>libgc 7.4, that is
<Madsy>I did and it doesn't
<mark_weaver>I wonder if we should switch to using the gnulib threadlib, which has backends for posix threads, GNU Pth threads, solaris threads, and Windows threads.
<stis>evening guilers!
<mark_weaver>hmm. (http-get "") reports: "web/http.scm:188:11: Bad uri header component: /web/20130913084535/" Why?
<mark_weaver>what's wrong with this URL? wget handles it properly.
<didi>mark_weaver: There are too `http's.
<didi>two, even.
<mark_weaver>so what? the second one is just a directory name.
<didi>mark_weaver: Ask http-get.
<mark_weaver>these are the URLs used by the internet wayback machine. and incidentally, the reason I'm using that is because Hans Boehm's website at HP has been down for a while.
<wingo>there is a new web site fwiw
<mark_weaver>oh? where?
<wingo>but that's still a bug to uncover :)
<wingo>i found that using my newfound magical power of email
<wingo>mark_weaver: i assume you saw the gnutls bug; nasty stuff!
<mark_weaver>I did see something about that. so terrible :-(
<mark_weaver>ooh, thanks for reminding me. time to upgrade the version in guix