IRC channel logs
2014-10-04.log
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. <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. <ahills>yeah, I'm going through lib by lib and running tests, etc <mark_weaver>well, 7.4.0 has known problems with the master branch of guile, at least. <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. <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? <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>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. <ahills>heh, maybe it's this beautiful message that deceived me: <ahills>Program received signal SIGSEGV, Segmentation fault. <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? <mark_weaver>I think that libgc might make an intentional segfault during startup to find the stack bounds. <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 <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>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. <ahills>0x00007ffff77c96db in GC_find_limit_with_bound () from /usr/lib/libgc.so.1 <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/libguile-2.0.so.22 <mark_weaver>I don't get that segfault when I run guile in gdb, fwiw. <ahills>since it can recover from the first one, I guess that's fine <ahills>that doesn't exist; is pastebin alright? <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 :-( <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>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 <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 <ahills>mark_weaver: same here--I'm going to try again tomorrow <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>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>i was hoping `report' did not have too many callers that would need updating <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) <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 <mark_weaver>I'd like to see the first few words of the structure pointed to by 'table' in frame 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>0x7ffff7f8cf80: 0x0806f21f 0xffff8000 0x00000000 0x00000000 <ahills>{0xffff80000806f21f, 0x0, 0xffff80000807305f} <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>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>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 <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. <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>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>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)