screen.bin file not found

[GoogleCodeExporter]

What steps will reproduce the problem?
1.Build crack with:
cd crack-language; ./bootstrap; ./configure; make; make check; sudo make install

2.
3.

What is the expected output? What do you see instead?

No error.  Error with screen.bin - see below.
What version of the product are you using? On what operating system?

Crack 0.8.  Archlinux x86_64.
Please provide any additional information below.
./unittests
serializerTestUInt...ok
serializerTestLargeStrings...ok
moduleTestDeps...ok
moduleSerialization...ok
moduleReload...ok
reloadOfSelfReferrentTypes...ok
operatorSerialization...ok
BUILD_ROOT=`pwd` ./test/screen
Using root directory: .
      build directory: /home/rick/crack-language

rebuilding screen.bin...
terminate called after throwing an instance of 'std::ios_base::failure'
  what():  basic_ios::clear
./test/screen: line 44: 30765 Aborted                 (core dumped) 
$builddir/crack -B llvm-native -Gl "$lib_paths" -b 
out=$builddir/test/screen.bin $root/screen/screen.crk
./test/screen: line 60: /home/rick/crack-language/test/screen.bin: No such file 
or directory
Makefile:2731: recipe for target 'check' failed
make: *** [check] Error 127
[sudo] password for rick: 
[rick@comet crack-language]$ 

Original issue reported on code.google.com by dick.hal...@gmail.com on 14 Jan 2014 at 8:07

[GoogleCodeExporter]

It looks like the executor is dying while trying to build screen.bin.  Can you 
try running the debugger: crack_dbg -- -B llvm-native -l lib:screen 
screen/screen.crk

Then run the program ('r'), produce a backtrace ('bt') and copy it into this 
bug report? 

Original comment by mmul...@google.com on 20 Jan 2014 at 4:58

[GoogleCodeExporter]

Starting program: /home/rick/crack-language/./.libs/crack -B llvm-native -l 
lib:screen screen/screen.crk
warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
terminate called after throwing an instance of 'std::bad_cast'
  what():  std::bad_cast

Program received signal SIGABRT, Aborted.
0x00007ffff4dbc369 in raise () from /usr/lib/libc.so.6
(gdb) bt
#0  0x00007ffff4dbc369 in raise () from /usr/lib/libc.so.6
#1  0x00007ffff4dbd768 in abort () from /usr/lib/libc.so.6
#2  0x00007ffff56aa635 in __gnu_cxx::__verbose_terminate_handler() ()
   from /usr/lib/libstdc++.so.6
#3  0x00007ffff56a87a6 in ?? () from /usr/lib/libstdc++.so.6
#4  0x00007ffff56a87d3 in std::terminate() () from /usr/lib/libstdc++.so.6
#5  0x00007ffff56a8a46 in __cxa_rethrow () from /usr/lib/libstdc++.so.6
#6  0x00007ffff56debea in std::basic_ostream<char, std::char_traits<char> >& 
std::__ostream_insert<char, std::char_traits<char> >(std::basic_ostream<char, 
std::char_traits<char> >&, char const*, long) () from /usr/lib/libstdc++.so.6
#7  0x00007ffff6a07fed in operator<< <char, std::char_traits<char>, 
std::allocator<char> > (__str="98399e6d06bc7aed18d8684d2ba9bf27", __os=...)
    at /usr/include/c++/4.8.2/bits/basic_string.h:2758
#8  (anonymous namespace)::briefPath (filename="screen/screen.crk")
    at model/Construct.cc:746
#9  0x00007ffff6a08364 in modNameFromFile (filename="screen/screen.crk")
    at model/Construct.cc:757
#10 model::Construct::runScript (this=0x60c350, src=..., 
    name="screen/screen.crk") at model/Construct.cc:772
#11 0x00007ffff6afc283 in Crack::runScript (this=this@entry=0x7fffffffe4f0, 
    src=..., name="screen/screen.crk") at Crack.cc:104
#12 0x0000000000402e21 in main (argc=6, argv=0x7fffffffe848)
    at crack_main.cc:310
(gdb)

Original comment by dick.hal...@gmail.com on 22 Jan 2014 at 6:19

[GoogleCodeExporter]

Sorry for letting this languish for so long :-(.

This traceback shows a bad_cast coming from an ostream operation on a plain 
std::string, which doesn't make any sense to me.  I suspect this is a problem 
specific to your environment, but I'm running it by our resident Arch expert to 
see if he can reproduce it.

Original comment by mind...@gmail.com on 31 Jan 2014 at 1:33

[GoogleCodeExporter]

Thank you - I was just going to look at how Crack was coming along.  I
might try it on another system I have.

Original comment by dick.hal...@gmail.com on 1 Feb 2014 at 10:10

[GoogleCodeExporter]

Sorry for taking so long to take a look at this. Now that Arch has upgraded 
llvm to 3.4 it's not possible for me to investigate this further (at least for 
the moment). All I can say is that I've never experienced a similar error.
I'll try porting crack to llvm 3.4 (minus exception handling for the moment, 
since that requires switching to the new JIT I believe) and then see if I can 
reproduce this.

Original comment by Arno.R...@gmail.com on 18 Feb 2014 at 5:44

[GoogleCodeExporter]

No drama and thanks for the reply.  I am busy right now so I don't have
time to check Crack out, but I will try again in a few weeks.

Original comment by dick.hal...@gmail.com on 20 Feb 2014 at 1:07