IRC channel logs


back to list of logs

<ahills>hey, has anyone had success building guile 2.0+ against musl?
<mark_weaver>someone else asked about that recently. I haven't heard any reports at all, positive or negative.
<mark_weaver>ahills: ^^
<ahills>my build segfaults right now, still trying to pin the source
<mark_weaver>first, what version of libgc are you using, and have you run libgc's test suite?
<mark_weaver>more generally, I would recommend running the test suites of all the libraries that guile depends on.
<mark_weaver>also, what compiler (including version) ?
<ahills>gcc 4.8.2
<ahills>yeah, I'm going through lib by lib and running tests, etc
<ahills>I'm using libgc 7.4.0
<mark_weaver>best upgrade to libgc 7.4.2
<mark_weaver>well, 7.4.0 has known problems with the master branch of guile, at least.
<ahills>I'm trying to build 2.0.11
<mark_weaver>I don't know the details, but in general it seems a good idea to be running the latest micro version of a given minor version.
<ahills>I'll give that a shot
<mark_weaver>honestly, it probably won't fix it, but it's such a quick easy compile that it seems worth trying before expending more effort debugging.
<mark_weaver>also, maybe try configuring guile --without-threads first, in case the problem has to do with pthread issues.
<ahills>neither fixed it; I may need to break out gdb
<ahills>is building guile with debug symbols as easy as ./configure CFLAGS=-g?
<ahills>mark_weaver: ^
<mark_weaver>it's built with debug symbols by default, but you may want to turn off optimization. what you wrote should accomplish that (I think)
<ahills>oh, when I was trying to debug it earlier, gdb couldn't find any symbols
<mark_weaver>well, no, sorry. better put -O0 in there too
<mark_weaver>interesting. on my builds, the default cflags are always "-g -O2"
<mark_weaver>I never do anything special, and end up with debugging symbols. not sure why it's different on your system.
<mark_weaver>maybe you have CFLAGS set in your environment?
<ahills>heh, maybe it's this beautiful message that deceived me:
<ahills>Program received signal SIGSEGV, Segmentation fault.
<ahills>0x0000738cefd456db in ?? ()
<ahills>thanks gdb
<mark_weaver>ahills: "grep ^CFLAGS libguile/Makefile" should show you the cflags used.
<mark_weaver>gdb generally gives me much better information. what version of gdb? is this on bsd?
<ahills>no, linux with musl
<ahills>gdb 7.6.2
<mark_weaver>I think that libgc might make an intentional segfault during startup to find the stack bounds.
<ahills>... what?
<ahills>how could that possibly be useful?
<mark_weaver>well, I'm probably misremembering. sorry, grasping at straws here..
<ahills>if that's the case, I'm giving up right away
<mark_weaver>btw, the right way to debug the uninstalled guile is to run: meta/gdb-uninstalled-guile
<ahills>ah, let me see if that performs any better
<ahills>nah, same mysterious segfault
<mark_weaver>well, I guess I would put a breakpoint at main and step.
<ahills>I wonder if having a hardened kernel is making gdb's job harder...
<ahills>yeah, PaX is preventing insight
<ahills>I'll need to fix that before I can learn more
<mark_weaver>setting GC_MARKERS=1 in the environment will disable marking in separate threads by libgc. might also be worth a try.
<mark_weaver>but yeah, you'll need a working debugger :)
<ahills>got it :)
<ahills>you were right mark_weaver:
<ahills>0x00007ffff77c96db in GC_find_limit_with_bound () from /usr/lib/
<mark_weaver>let gdb continue
<mark_weaver>fwiw, I think it only does that when there's no better way, and probably on glibc there's a better way.
<ahills>0x00007ffff7adb53d in scm_variable_ref () from guile-2.0.11/libguile/.libs/
<mark_weaver>I don't get that segfault when I run guile in gdb, fwiw.
<ahills>it's the "next" segfault
<ahills>since it can recover from the first one, I guess that's fine
<mark_weaver>can you put the backtrace on a paste service?
<ahills>that doesn't exist; is pastebin alright?
<mark_weaver> sorry
<mark_weaver>pastebin blocks tor :-(
<ahills>oh, lame
<ahills>here you go:
<ahills>it looks like it's failing while trying to error out?
<ahills>sorry in advance for the very long paths
<mark_weaver>yeah, probably because the needed subsystems haven't yet been initialized to print the error.
<mark_weaver>it's lame that the arguments aren't included in the backtrace :-(
<ahills>are they normally?
<mark_weaver>on my system they certainly are.
<ahills>hmm, maybe I missed a PaX flag
<mark_weaver>in fact, with gdb 7.8 and guile 2.0.11, the scheme values are actually printed properly. but that requires a working guile first to link with gdb.
<mark_weaver>no line numbers either
<mark_weaver>I'd like to see the value of 'table' in scm_hash_fn_create_handle_x (frame 5)
<ahills>I'd like to see all the values, so I'm spinning up a new machine without grsec
<janneke>morning Guilers!
<mark_weaver>hi janneke!
<mark_weaver>janneke: sorry I haven't yet reviewed your recent patches. the most recent one, for the location information in the test-suite, basically looks good to me, but 'guile-test-runner' in srfi-64.test needs to be updated. the location information is in the result-alist, already decoded, although I forget the details off-hand.
<mark_weaver>you might consider just using srfi-64, for that matter.
<mark_weaver>I was hoping that wingo would review your earlier patches for GUD integration, but he seems quite busy on other things lately
<mark_weaver>ahills: I need to sleep soon. It's 03:19 here.
<ahills>mark_weaver: same here--I'm going to try again tomorrow
<ahills>thanks for the help thus far
<janneke>mark_weaver: yeah I'm really a bit stuck with emacs/GUD waiting for wingo
<janneke>i do appreciate that he's busy and all...
<janneke>mark_weaver: srfi-64.test breaks with my patch?
<janneke>i'll have a look...
<janneke>it would be nice if someone would test emacs/GUD with my debug patch
<janneke>next steps would be eclipse (*cough*) and possibly geiser integration (hmm?)
<janneke>or "just" improving the guile debugger itself ;-)
<mark_weaver>janneke: 'guile-test-runner' in srfi-64.test calls 'report'. you added another argument to that procedure, as I recall. I think you'll see the problem if there's an error in any of the tests in srfi-64-test.scm
<mark_weaver>I suppose 'guile-test-runner' really ought to be moved into test-suite/lib.scm, since it uses one of lib's private procedures.
<mark_weaver>and we may in the future import other srfi-64-based test suites.
<mark_weaver>in fact, the r7rs test suite from chibi scheme is such an example
<mark_weaver>'source-line' and 'source-file' are the two relevant keys from 'result-alist' in guile-test-runner. the line number has already had 1 added to it at that point.
<mark_weaver>well, maybe I should just handle this part myself...
<janneke>mark_weaver: ok that makes sense
<janneke>i was hoping `report' did not have too many callers that would need updating
<paroneayea>hey #guile :)
<mark_weaver>hi paroneayea!
<paroneayea>hi mark_weaver !
<ahills>mark_weaver: my default CFLAGS are -Os -fomit-frame-pointer, so I changed them to -O0 -g, and now gdb is playing much nicer (on the non-grsec machine)
<mark_weaver>that's good!
*mark_weaver looks
<ahills>it's even reading the actual source files
<ahills>yeah I'm building as root, no I'm not going to bother setting up another user
<ahills>annotated paste with bt full
<mark_weaver>I'd like to see the first few words of the structure pointed to by 'table' in frame 6
<mark_weaver>first three words
<mark_weaver>is this a 32-bit or 64-bit system?
<mark_weaver>64-bit, nevermind. obvious from the bt
<mark_weaver>p/x (scm_t_bits [3])*table
<mark_weaver>"frame 5" before that
<mark_weaver>sorry, 6.
<ahills>hmm, gdb has changed since the ancient version I used at my last job
<ahills>nope, it hasn't, my memory is just poor
<ahills>but why is it printing in binary...
<ahills>ok, first four words coming up
<ahills>0x7ffff7f8cf80: 0x0806f21f 0xffff8000 0x00000000 0x00000000
<ahills>{0xffff80000806f21f, 0x0, 0xffff80000807305f}
<ahills>yeah, ^
<mark_weaver>well, that's supposed to be a hash table, but the type tag is wrong.
<mark_weaver>might be that it's getting corrupted. we better start earlier.
<mark_weaver>"break scm_modules_prehistory" and "run" please
<mark_weaver>also, the second word shouldn't be 0
<mark_weaver>I want to see what it looks like right after that hash table has been initialized.
<mark_weaver>the structure in question is 'scm_pre_modules_obarray', initialized in scm_modules_prehistory
<mark_weaver>s/structure/hash table/
<ahills>same value in frame 7
<ahills>what's this 1533 magic number?
<ahills>at the end of make_hash_table?
<mark_weaver>the initial size of the hash table vector.
<mark_weaver>(it'll get expanded later as needed).
<ahills>n = 1759
<ahills>on line 285 of hashtab.c
<mark_weaver>I'm not sure why you stopped there, I asked for a breakpoint in scm_modules_prehistory. did you step into scm_c_make_hash_table?
<ahills>I said ready like ten minutes ago, got bored, started digging in
<mark_weaver>for now, I'd rather let scm_modules_prehistory finish and then look at the results
<ahills>I can reset easily
<ahills>yeah, it's done
<mark_weaver>and then: p/x (scm_t_bits[3])*scm_pre_modules_obarray
<ahills>{0x1d, 0x7ffff7fa8000, 0x7ffff7f8bf90}
<mark_weaver>okay, that looks right, so now to find out where it's getting corrupted.
<mark_weaver>hmm, let's take this private, and not spam the whole channel with this.
<daviid>hello guilers!
<sneek>Welcome back daviid, you have 1 message.
<sneek>daviid, mark_weaver says: rlb asked about the status of guile-gnome, for purposes of getting it updated in debian to use guile 2.0. time is short wrt the freeze. can you get in touch with him about it?
<daviid>sneek: got it thanks
<daviid>mark_weaver: sure, just answered your email
<daviid>rlb: hello! i'd like to forward the email i just sent top mark_weaver if that's ok with you
<daviid>then of course we can [always] talk...
<daviid>rlb: so I went ahead and forwarded the email I sent to mark_weaver
<daviid>mark_weaver: guile-gnome-platform is not even in testing anymore, see
<daviid>it's been reintroduced in unstable in february as a non-maintainer upload
<rlb>daviid: thanks -- one option may be to just remove the packages from jessie for now (for the ones that haven't been removed already)
<rlb>(or eventually from debian altogether, if there are no interested maintainers)