IRC channel logs


back to list of logs

<madsy>Hm.. according to valgrind, guile 2.0.10 is leaking memory
<madsy>Could that be true?
<mark_weaver>ask wingo about it.
<mark_weaver>I don't know how valgrind interacts with libgc.
<mark_weaver>how does it decide that there's a leak? how can it know?
***brendyyn is now known as brendyn
<stis>sneek where is buggs
<stis>sneek: where is buggs
<civodul>Hello Guilers!
<wingo>heya civodul :)
*wingo writing out-of-memory tests and fixing various bugs
<davexunit>good morning, guilers.
<davexunit>libreplanet is about to kick off. :)
<madsy>Morning all!
<artyom-poptsov>Hi civodul
<madsy>wingo: Any chance 2.0.10 leaks memory? valgrind thinks so.
<davexunit>is it just me or does guile 2.0.11 still print 2.0.10 when the REPL is started?
<mark_weaver>madsy: you never answered my question before. how does valgrind decide that we leak memory?
<mark_weaver>davexunit: it prints 2.0.11 for me.
<davexunit>mark_weaver: cool. problem on my end then.
<mark_weaver>I suspect that somehow the shared library from 2.0.10 is being used.
<madsy>mark_weaver: I don't know the internals. But it does more than just tracking malloc/free for sure
<mark_weaver>madsy: according to valgrind detects leaks when the program exits. anything not reachable from the stack or globals is assumed to be leaked.
<mark_weaver>one issue is that our pointers do not always point to the beginning of the allocated memory block.
<mark_weaver>anyway, I think that guile does have at least one leak, but apparently it's quite slow.
<madsy>mark_weaver: Well, it differentiates between different kinds of leaked memory with differing accuracy.
<madsy>mark_weaver: I only take "definitely lost" into account, which does not look at the kind of pointers you just described.
<madsy>Pointers pointing in the middle of a block would show up in the "possibly lost" statistics, and should be taken with a grain of salt.
<madsy>And that statistic shows 0 bytes lost anyway
<mark_weaver>which statistic(s) are non-zero, and what are their values?
<mark_weaver>is the amount of leaked memory bounded, or does it increase with the amount of work you did with guile?
<madsy>Only "definitely lost" is worth inspecting. The rest is likely to be false alarms
<madsy>It seems to be bounded, but let me double check
<mark_weaver>is there a way to view the contents of the 'definitely lost' blocks?
<madsy>I don't think you can inspect the contents, but I could run valgrind with more verbose input to see what it complains about. It does use debugging info
<madsy>Like, which function or source file
<mark_weaver>oh, if it can show us the code that allocated those 'definitely lost' blocks, that would be swell.
<madsy>Yeah it seems to be bounded and always less than 10 KiB
<madsy>So if there is a leak, it's harmless
<mark_weaver>well, I think that's a very low priority item then :)
<madsy>But since it changes between invocations I have to disable guile when checking my own code for leaks
<madsy>Not a big issue though
<mark_weaver>also, I wonder what happens with GC-allocated blocks that are no longer reachable, but just haven't been GC'd yet, when the program exits.
<mark_weaver>i.e. I don't know how valgrind interacts with libgc
<mark_weaver>If I had to make a guess, I'd that guess valgrind probably sees only the big blocks that libgc allocates.
*wingo just made guile throw out-of-memory on allocation failures
<mark_weaver>wingo: nice!
<madsy>mark_weaver: My bad. The offending library is libglew :)
<madsy>And it seeems to be deep in driver land
<mark_weaver>ah, good :)
<madsy>Err.. libglfw
<madsy>I use it to create an OpenGL window and context
<madsy>When libguile runs alone, only 704 bytes shows up in "possibly" lost, which is just a false alarm. Evertyhing else is 0
<madsy>So the GC seems to do a better job than I do manually
<wingo>lloda: around? care to give master's test-suite another test?
<didi>OK, I'm terrible with regexps. But shouldn't (string-match "a.+?" "abbb") match "ab"?
<mark_weaver>didi: currently, guile's core regexps are just POSIX regexps, where the non-greedy syntax is not supported.
<mark_weaver>didi: we plan to add SRFI-115 when it's finalized, which will be much nicer.
<ijp>I haven't kept up with the new srfis, is 115 just irregex?
<mark_weaver>in the meantime, if you want nicer regexps, I would recommend irregex, which is close to SRFI-115.
<ijp>I suppose that answers it
<mark_weaver>ijp: it's based on irregex, but not quite the same.
<ijp>psychic conversation on #guile
<didi>mark_weaver: oic. Well, according to the manual: "By default, Guile supports POSIX extended regular expressions. That means that the characters ‘(’, ‘)’, ‘+’ and ‘?’ are special, and must be escaped if you wish to match the literal characters."
<didi>Not that anybody should care, but I already doubt myself any time I write regexps. This doesn't help.
<mark_weaver>didi: that's right. but the '+?' is not being interpreted as a single operator (non-greedy +), but rather as two separate operators. + is greedy, and then ? means that the '.+' is optional.
<mark_weaver>well, there are a lot of different variants of regexps, which doesn't help.
<mark_weaver>speaking of SRFI-115, I wonder what's up with that. its draft period was supposed to end on Dec 12, and the last post to the mailing list was on Dec 13. Nothing since then.
<mark_weaver>it's as though Alex just got distracted with other things.
<madsy>If I define a module in a .scm file, do I still have to load it with (load ..) ?
<madsy>Or is it enough to make sure that the scm file is reachable in the load path?
<didi>mark_weaver: Oh, OK. The manual should more explicit then. It points to the Emacs manual, where +? is a non-greedy variant.
<didi>s/should/should b
<taylanub>didi: POSIX ERE simply has no +?
*didi *sigh*
<ijp>so, I went on to find a good quote about psychics and irc....I have now spent 20 minutes on the site just reading
<taylanub>didi: You might have luck with "man regex" on your system for explanations of POSIX BRE and ERE
<taylanub>They are also what sed, grep, and AWK support per POSIX. (sed BRE, grep configurable, AWK ERE)
<ijp>good thing we have all these different regex varieties
<didi>And point to different sources.
<ijp>it would be terrible to write a regex and have it actually work first time
<taylanub>I sometimes think POSIX ERE ought to be enough for everyone but that could be because I never learned Perl RE.
<taylanub>Uh, could it be that SRFI-115 is thinking that PCRE stands for POSIX Compatible RE and not Perl Compatible RE ? "How to integrate with the PCRE regular expression library? The intention is to make this the primitive notation, and for POSIX require a separate wrapper such as (pcre->sre <str>)."
<taylanub>I'm probably misinterpreting or misunderstanding it; the References list "PCRE - Perl Compatible Regular Expressions".
<mark_weaver>didi: I agree that the link to the emacs manual is misleading, and something should be done there.
<mark_weaver>but more generally, I really dislike our current regexp API, so I'll be glad when we replace it with something much better.
<mark_weaver>namely SRFI-115 :)
<didi>mark_weaver: I would gladly help you with that. In the mean time, a manual edit is necessary IMO.
<mark_weaver>patches welcome
<madsy>When I've defined a module with define-module in a file, how do I get (use-module) to find it? Do I have to load it *and* use (use-module) ?
<mark_weaver>madsy: no, if it's a module, then just 'use-module'.
<madsy>I thought I had to add the path to #library-path or %load-path, but it didn't make a difference
<mark_weaver>when you (use-module (foo bar baz)) it looks in <DIR>/foo/bar/baz.scm, where <DIR> is a component of the load path.
<madsy>That explains it
<mark_weaver>the load path being in %load-path, which is initialized based on built-in stuff plus GUILE_LOAD_PATH
<madsy>I didn't know the name had path semantics. Thanks
<mark_weaver>also see %load-compiled-path and GUILE_LOAD_COMPILED_PATH
<madsy>Ok, so I added /some/long/path/modules to %load-path and %load-compiled-path, and my module is at /some/long/path/modules/lambda-demo/opengl.scm
<madsy>(use-modules (lambda-demo opengl)) still doesn't find it
<madsy>Should my (define-module) call in opengl.scm be (define-module (lambda-demo opengl)) or just (define-module (opengl)) ?
<mark_weaver>(define-module (lambda-demo opengl))
<mark_weaver>if you tried to load it once, and it failed, it might have cached the failure somehow, dunno.
<madsy>Maybe it ignores the module include because I have defined an internal module in C with the same name?
<mark_weaver>oh, yes, that's it.
<mark_weaver>it only tries to autoload it in the module doesn't yet exist.
<mark_weaver>the way this is normally handled is that the scheme module calls a C procedure that adds the C-level bindings to the modue.
<madsy>Great, I just changed the name. Now it works
<madsy>So Guile's module system isn't very unlike Clojure's and Java's
*mark_weaver goes afk for a while
<ijp>madsy: by and large there are only really three kinds of module system: none, normal, and ML
<madsy>When I try to compile some code which uses a macro in my module, I get an error from guile, saying that the module contains no code. How do I resolve that?
<artyom-poptsov>madsy: How do you compile the code? I mean, how do you call the compiler?
<madsy>artyom-poptsov: With geiser. compile-buffer. C-c- C-k
<madsy>artyom-poptsov: And my module has a single macro, no functions
<zacts>I need to learn geiser. currently I only use a scheme buffer, a scratch scheme buffer, and a repl.
<artyom-poptsov>madsy: I guess you should somehow tell the compiler path to directory with your module.
<madsy>artyom-poptsov: Geiser has the load path. That's not the problem
<tupi>madsy: try ... (eval-when (compile load eval) your macro defs here) ...
<madsy>No difference. boot-9 still throws
<tupi>i am not sure i understand what you do. could you paste a short example?
<madsy>Yes. Here's my code.
<madsy>That module lives under %load-path / lambda-demo/opengl/enums.scm
<madsy>And I'm loading it with (use-modules (lambda-demo opengl enums))
<madsy>That gives me: ice-9/boot-9.scm:106:20: In procedure #<procedure 3c70400 at ice-9/boot-9.scm:97:6 (thrown-k . args)>:
<madsy>ice-9/boot-9.scm:106:20: no code for module (lambda-demo opengl enums)
<madsy>But I did set %load-path properly in Geiser. I even modified load-path and load-compiled-path in the code before calling (use-modules)
<tupi>that cn only be true if the parent directory of lambda-demo/opengl is _not_ in %load-path
<madsy>Geiser has "add to load path.." Which is C-c C-e C-l. I've added the directory twice
<tupi>also you name [in the paste] this module "gistfile1.scm" but it must be named enums.scm
<tupi>is the case on your machine?
<madsy>Yes, the file name is just added by github
<madsy>It's really enums.scm
<artyom-poptsov>madsy: Basically `(lambda-demo opengl enums)' means that the module lives here: %load-path/lambda-demo/opengl/enums.scm
<madsy>artyom-poptsov: Indeed. And it does.
<madsy>That is, the full path is /home/madsy/Projects2/SchemingDemo/scheme-src/modules/lambda-demo/opengl/enums.scm
<madsy>And /home/madsy/Projects2/SchemingDemo/scheme-src/modules/ is in %load-path, and added to Geiser's path
<madsy>Maybe "(define-module (lambda-demo opengl enums) ....) is wrong?
<madsy>Probably not, since loading it works in the REPL.
<ijp>C-c C-e C-l adds the buffers directory
<ijp>which is wrong here
<tupi>is this path with the last #/ in %load-path [as you pasted here>]
<ijp>sorry, my bad, I misinterpreted the help
<ijp>anyway, I'm seeing the same thing
<ijp>which is weird, because I modify %load-path in my .guile with no problems
<artyom-poptsov>madsy: I think you should try to compile the code by using guild compiler directly, and then compare the results. Try to specify path to your module by passing it with `-L' option to the compiler.
<ijp>I stand correct, my problem was pebcak
<ijp>madsy: what version of guile are you using?
<ijp>I have a vague recollection of a related problem in an earlier version that was fixed
<ijp>the problem was if you looked up a module and it failed, and then you fixed it, it was still cached and so always failed
<ijp>does that sound similar, or does it happen in a fresh guile too?
<madsy>ijp: The last snapshot before 2.0.10
<ijp>that was fixed in 2.0.9 I think
<ijp>madsy: does it still fail if you run a fresh guile (with -q), and do (set! %load-path (cons "dir" %load-path)) (use-modules your-module)
<mark_weaver>madsy: what exactly is the value of '%load-path' ?
<tupi>madsy: earlier you said you defined : (define-module (lambda-demo opengl enums)
<tupi>but do (use-modules (lambda-demo graphics enums))
<mark_weaver>madsy: I suppose at this point I'd be tempted to attach 'strace' to the guile process and see where it looks when you try to load the module.
<madsy>tupi: I change it, because it could conflict with a hardcoded module path
<madsy>That is, (lambda-demo opengl) is a module defined in the C interface. So I assume anything with (lambda-demo ..) could be messed up
<madsy>I'll try to set the load-path on startup
<zacts>what is the proper way to configure guile to build with clang instead of gcc on gnu/linux?
<mark_weaver>zacts: pass CC=clang to configure
<mark_weaver>madsy: it is indeed plausible to me that (lambda-demo opengl) defined from C might be causing this problem.
<mark_weaver>there are some wierdnesses in the guile module system that I have yet to learn about.
<ijp>I'm not convinced as convinced
<ijp>we're not checking that prefixes are guile modules are we?
<ijp>madsy: when you changed the path, did you also change the define-module form?
<mark_weaver>but I seem to recall that guile modules are hierarchical in the sense that (lambda-demo opengl enums) is looked up by looking up 'lambda-demo' in a root module, and then looking up 'opengl' in the (lambda-demo) module, and then 'enums' in the (lambda-demo opengl) module, or something like that.
<ijp>(may as well rule that out)
<madsy>mark_weaver: I tried a completely new path now. %load-path/madsy-test/enum.scm. Still complains about no code
<mark_weaver>madsy: use strace
<mark_weaver>you changed the module name in the 'define-module' form to match?
<mark_weaver>(madsy-test enum) ?
<mark_weaver>okay, use strace please.
<zacts>mark_weaver: yep, this doesn't seem to be a FreeBSD bug, it's failing with clang on i386 gnu/linux
<ijp>madsy: and you tried loading it in a fresh guile instance?
<ijp>with -q for good measure
<zacts>at the same spot
<mark_weaver>zacts: okay, that's very helpful to know, thanks.
<madsy>ijp: I did start my application and passed -L<path> to scm_shell
<zacts>mark_weaver: now let me backtrace it on gnu/linux
<madsy>Okay.. loading the module works with guile, but not my libguile application
<zacts>mark_weaver: nice, I get a much more thorough backtrace on a gnu userland
<ijp>";; It used to be, however, that module names were also present in the ;; value namespace. When we enable deprecated code, we preserve this ;; legacy behavior."
<ijp>mark_weaver: is that the behaviour you are referring to mark?
<zacts>mark_weaver: <- I have a backtrace for you
<mark_weaver>zacts: can you try: make -C libguile clean && make CFLAGS="-O0 -g"
<mark_weaver>and see if that fixes it?
<mark_weaver>ijp: not quite. whether the submodules are in the normal value namespace is a separate question. but somehow, the submodules are looked up in their parent modules.
*mark_weaver goes afk for a while
<zacts>it didn't fix the problem
<mark_weaver>zacts: okay, that's also useful information, plus we get a much more useful backtrace :)
<zacts>mark_weaver: what do you think the problem is?
<mark_weaver>zacts: I'm reading the relevant code, trying to figure it out.
<zacts>ok, thanks. well /me will bbl. I have some schoolwork to do. :-)
<mark_weaver>zacts: okay, thanks for the info, this is very helpfull.
<mark_weaver>zacts: if you're around, there are some things you could do in gdb that would help me narrow it down.
<zacts>hey back for a sec
<zacts>what would you like me to try in gdb?
<mark_weaver>zacts: type "break create_gsubr" and then "run"
<mark_weaver>it should hit the breakpoint. then "p scm_subr_objcode_trampolines[0]" and "p scm_subr_objcode_trampolines[1]" and "p/x *(scm_t_bits *)scm_subr_objcode_trampolines[1]"
<mark_weaver>and show me the output
<zacts>I get: Function "create_gsubr" not defined.
<mark_weaver>and then it should ask "Make breakpoint pending on future shared library load? (y or [n])" no?
<zacts>oh yeah
<mark_weaver>say 'y'
<zacts>what should I say there?
<mark_weaver>then "run"
<mark_weaver>it should hit the breakpoint.
<mark_weaver>also, what number does "p sizeof(scm_t_cell)" print?
<mark_weaver>what does "p &objcode_cells" print?
<mark_weaver>I just need the hex address
<zacts>mark_weaver: $5 = (const struct {...} *) 0xb7fb6bb4
<mark_weaver>grump. it's not aligned properly, even though we put a scm_t_uint64 in there for alignment.
<mark_weaver>what does "p sizeof(scm_t_uint64)" print?
<zacts>mark_weaver: $6 = 8
<mark_weaver>well, okay, I know the problem now, anyway. thanks very much!
<zacts>cool! is it a guile problem, or clang?
<mark_weaver>I guess that putting in a 64-bit integer in there doesn't guarantee 64-bit alignment on a 32-bit machine, which I guess is plausible. I'll have to look into it.
<mark_weaver>I guess that gcc is aligning it on a 64-bit boundary, but clang isn't.
*mark_weaver looks at C99
<zacts>keep me updated, I gtg again..
<mark_weaver>zacts: I know what needs to be done now, anyway.
<mark_weaver>both GNU C and C11 allow the alignment of a variable to be specified explicitly.
<mark_weaver>and clang supports GNU C.
<zacts>hm.. will this be a guile patch?
<mark_weaver>okay, we already have a SCM_ALIGNED macro for exactly this, but it wasn't used where it needed to be used.
<mark_weaver>so the fix is easy.
<zacts>mark_weaver: if you can share the patch with me, so that I can include it within the port.
<mark_weaver>will do, I'll have a patch soon
<zacts>(unless you are willing to do a shiny new version of guile for this, but I'm assuming not) :-)
<mark_weaver>no, this isn't important enough :)
<mark_weaver>32-bit clang users can suck it up and apply the patch manually.
<zacts>heh, ok.
<zacts>oh mark_weaver let me give you my email again in a private /msg
<zacts>thanks, you may send me the patch there whenevers.
<mark_weaver>zacts: can you try this patch?
<zacts>mark_weaver: no I can not
<zacts>yeah, I'll try it out for you
<zacts>should I build normally, or with that special make line with -O0?
<zacts>ok, I'll let you know if/when the build finishes.