Issues

Issue #7 resolved

'eval' doesn't handle closures

ebm_boy
created an issue

Of course, I don't expect eval to return something interesting when given a closure but a segmentation fault is too painful ;)

$ pure

> g = \ x -> x;
> eval g;

Erreur de segmentation (core dumped)
$

Comments (23)

  1. Albert Graef

    Hmm, I can't reproduce this, this works fine over here:

    > g = \x->x;
    > eval g;
    #<closure 0x7f96f3b3c680>
    

    Can you please add some information about your system and LLVM version. Also, please attach the config.log of your Pure build.

    Thanks, Albert

  2. ebm_boy reporter

    lsb_release -a | grep Description -> Ubuntu 12.04.2 LTS

    pure --version -> Pure 0.57 (i686-pc-linux-gnu) Copyright (c) 2008-2013 by Albert Graef Compiled for LLVM 3.0 (http://llvm.org)

    llvm-clang --version -> Ubuntu clang version 3.0-6ubuntu3 (tags/RELEASE_30/final) (based on LLVM 3.0) Target: llvm-- Thread model: posix

    I am running pure from the ubuntu package I installed with the instructions found on this page : https://launchpad.net/~dr-graef/+archive/pure-lang.precise so I don't have a config.log, I guess.

  3. Albert Graef

    Hmm, that's pretty much what I'm running here, too, except that I'm on a 64 bit system. I'll have to do a virtual 32 bit installation of Ubuntu to see whether I can reproduce the bug there. But this will take a while, since I'll be on a conference next week.

    In the meantime you could build a debugging version of Pure and see whether you can produce a meaningful backtrace using gdb.

  4. ebm_boy reporter

    Here is the config.log of a newly non-debugging compiled version of pure-0.57 (after removing ubuntu package). Same segfault on the example. I will now try a debugging version as you mentionned.

  5. ebm_boy reporter

    With a debugging version, I have:

    $pure

    > g=\x->x;
    > eval g;
    

    pure: runtime.cc :744 : pure_expr pure_new_internal(pure_expr): l'assertion « tmps » a échoué.
    Abandon (core dumped)
    $

  6. Albert Graef

    I desperately tried to reproduce this issue, both on Ubuntu 12.04.3 and Windows XP (both 32 bit systems), but I can't. Your example works every time for me, no matter whether I use the premade package or compile Pure myself from either the 0.57 or the current hg sources, with or without debugging code. I even tested it after switching the locale to French, just in case there was something locale-related. And 'make check' works fine for me, too.

    Here are three more things that you can try:

    • Please double-check that your Ubuntu system is fully updated. Ubuntu has a track record of sometimes messing up their LLVM packages, so you should make sure that you're not having some stale packages there.

    • Run 'make check' in the directory where you compiled Pure. All tests should pass. If there's anything that goes wrong there, please zip up the entire test subdirectory and send it to me.

    • If that doesn't help either, try reproducing the bug while running the Pure interpreter under gdb and send me the full gdb backtrace. But please do this under an English locale, my French is a bit rusty. ;-)

    Other than that, I'm running out of ideas. The failed assertion you reported is fairly unspecific (it points to some kind of memory allocation error), but if there's something going awry in the expression heap management then I should be able to reproduce that here.

  7. Albert Graef

    As I can't reproduce the issue, I'm putting this on hold now until more information becomes available. Please feel free to reopen the issue if the problem persists for you.

  8. ebm_boy reporter

    1) my system is fully updated
    2) the 91 tests passed successfully
    3) here is the gdb backtrace:

    (gdb) run
    Starting program: /usr/local/bin/pure
    [Thread debugging using libthread_db enabled]
    Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".

    __ \ __ _ \ Pure 0.57 (i686-pc-linux-gnu)
    .__/ _, _ ___ (Type 'help' for help, 'help copying'
    _ for license information.)

    Loaded prelude from /usr/local/lib/pure/prelude.pure.

    g=\x->x;
    eval g;
    pure: runtime.cc :744 : pure_expr pure_new_internal(pure_expr): l'assertion « tmps » a échoué.

    Program received signal SIGABRT, Aborted.
    0xb7fdd424 in __kernel_vsyscall ()
    (gdb) bt

    0 0xb7fdd424 in __kernel_vsyscall ()

    1 0xb66181df in __GI_raise (sig=6)

    at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
    

    2 0xb661b825 in __GI_abort () at abort.c:91

    3 0xb6611085 in __assert_fail_base (

    fmt=0xb5d80764 "%s%s%s :%u : %s%s l'assertion « %s » a échoué.\n%n",   assertion=0xb7f52af2 "tmps", file=0xb7f52ac0 "runtime.cc", line=744,   
    function=0xb7f4e460 "pure_expr* pure_new_internal(pure_expr*)")  
    at assert.c:94
    

    4 0xb6611137 in GI_assert_fail (assertion=0xb7f52af2 "tmps",

    file=0xb7f52ac0 "runtime.cc", line=744,   
    function=0xb7f4e460 "pure_expr* pure_new_internal(pure_expr*)")  
    at assert.c:103
    

    5 0xb7df3453 in pure_new_internal (x=<optimized out>) at runtime.cc:744

    6 0xb7dc3bcb in interpreter::exec (this=0xbfffe2a8, x=0x88c2d60)

    at interpreter.cc:4315
    

    7 0xb7f38ca3 in yy::parser::parse (this=0xbfffdfc8) at parser.yy:249

    8 0xb7dc6bc0 in interpreter::run (this=0xbfffe2a8, priv=-1, _s=...,

    check=false, sticky=true) at interpreter.cc:2838
    

    9 0x0804f331 in interpreter::run (this=this@entry=0xbfffe2a8, source=...,

    check=check@entry=false, sticky=sticky@entry=true) at interpreter.hh:718
    

    10 0x0804bcda in main (argc=1, argv=<optimized out>) at pure.cc:949

    (gdb)

    By the way, I should have missed something but I don't know how to build from the mercury source. I was looking for configure in pure-lang/pure directory but configure is not there. So all this is still for pure 0.57.

  9. Albert Graef

    Do you still see the problem with the latest hg source? It's a good idea to try that first before we start a lengthy debugging session. :)

    Another thing that you could still try is to see whether the problem persists if you compile LLVM yourself and build Pure with that version.

    The backtrace clearly points to corrupted or uninitialized expression memory, but I have no idea how this could possibly happen. As I cannot reproduce the issue, the best that I can do from here is to give you instructions on how to debug the issue yourself. Unless you can give me an account so that I could log into your machine and run gdb on the interpreter.

  10. ebm_boy reporter

    Thank you. Yes, same problem with pure 0.58. Sorry, I don't want to compile llvm myself as it is used with other apps (I don't want to mess anything). How can I give you an account on Ubuntu ?

  11. Albert Graef

    Basically, 'sudo adduser username', then enter a password when prompted. I'll need to know the name and password of the user that you created. To allow remote login, you'll also need to have the openssh-server package installed (sudo apt-get install openssh-server).

    Here's some information to get you started: https://help.ubuntu.com/lts/serverguide/user-management.html#adding-deleting-users https://help.ubuntu.com/lts/serverguide/openssh-server.html

    To log into your machine, I'll also need your external IP address assigned by your ISP (https://www.google.com/search?q=Whats+my+IP). Unless you have a permanent Internet connection. this changes every time you establish a connection to your ISP, so I may have to ask you for that repeatedly.

    Your Internet modem or router probably has an integrated firewall, this may have to be configured so that the ssh port is open (port 22 by default). Unfortunately, the details of this vary with the particular model of router that you use, so I can't really tell you how to do that, but your router probably has a web interface which would allow you to perform such maintenance tasks.

    If that sounds like too much hassle, I can also provide you with instructions on how to debug the issue yourself. :)

  12. Albert Graef

    Ok, here are part 1 of the instructions in case you would like to give it a go yourself:

    1. Make sure you have the latest hg source of Pure installed, configured for a debugging build: ./configure --enable-debug && make && sudo make install
    2. Invoke gdb: gdb pure
    3. In gdb set a breakpoint at interpreter.cc:4343: break interpreter.cc:4343. gdb will complain that there's no interpreter.cc source file yet, just confirm that you want to set the breakpoint pending shared library loading (you need to type y there).
    4. Run the program: run
    5. When the interpreter starts up, enter the following line: g = \x->x; eval g;
    6. gdb should stop at line 4343 in interpreter.cc now. This should be the line reading result = pure_new(res);. Enter the following gdb command to print the value of *res: print *res

    I need the output of that last command. How to continue the debugging depends on that. I'd suggest that we meet in a chat to continue the debugging from there if needed. I'm on Google+, Facebook and Skype, and we also have an IRC chat at irc://irc.freenode.net/pure-lang, so just let me know what's most convenient for you.

  13. Albert Graef
    • changed status to open

    Confirmed. The following snippet triggers the bug:

    __show__ x::double = "???";
    g = \x->x; eval g;
    

    I can reproduce this now, and will fix asap. Thanks!

  14. Albert Graef

    Ok, so I guess that means that I can release Pure 0.58 now? ;-) The sources are tagged and I have the tarballs sitting on my hard disk already...

    BTW, I didn't forget about your other bug report concerning faust-lv2 on googlecode, that's next up on my TODO list.

  15. Log in to comment