crack hello: Segmentation fault

[GoogleCodeExporter]

What steps will reproduce the problem?
1. crack hello.crk
2.
3.

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

What version of the product are you using? On what operating system?
crack trunk, Gentoo Hardened ~amd64

Please provide any additional information below.

Original issue reported on code.google.com by wbr...@gmail.com on 16 Aug 2012 at 11:25

[GoogleCodeExporter]

Is this "example/hello.crk" in the distro?

None of use use Gentoo, we aren't seeing this problem on Ubuntu or Arch.

Please run the test suite with "make check" and let us know which tests are 
failing, "example/hello.crk" actually imports a substantial amount of code, the 
earlier tests will help us narrow down where the problem lies.

Also, can you run "./crack_dbg -- -l lib example/hello.crk", type "r" at the 
prompt and then "bt" after the seg-fault, then paste the debugger output into 
this bug report?

Original comment by mind...@gmail.com on 16 Aug 2012 at 11:50

[GoogleCodeExporter]

It isn't useful 

Program received signal SIGSEGV, Segmentation fault.
0x000003785c2cfff9 in ?? ()
(gdb) bt
#0  0x000003785c2cfff9 in ?? ()
#1  0x000003785c2e68da in ?? ()
#2  0x0000000000020550 in ?? ()
#3  0x0000002700b35ab0 in ?? ()
#4  0x0000002700ac0380 in ?? ()
#5  0x000003785c2d97d7 in ?? ()
#6  0x0000037859da0e40 in ?? () from /lib64/libc.so.6
#7  0x0000037859a96b82 in calloc () from /lib64/libc.so.6
#8  0x000003785c2e4830 in ?? ()
#9  0x0000039c0f8046f0 in ?? ()
#10 0x000003785b39157f in operator< (other=..., this=<optimized out>) at 
debug/DebugTools.cc:41
#11 operator() (__y=..., __x=..., this=<optimized out>) at 
/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.4/include/g++-v4/bits/stl_function.h:236
#12 find (this=0x3785c152aa0, __k=...) at 
/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.4/include/g++-v4/bits/stl_tree.h:1539
#13 find (__x=..., this=0x3785c152aa0) at 
/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.4/include/g++-v4/bits/stl_set.h:605
#14 (anonymous namespace)::lookUpString (key=...) at debug/DebugTools.cc:60
#15 0x000003785b440710 in builder::mvll::LLVMJitBuilder::run 
(this=0x3785c2e36a9) at builder/llvm/LLVMJitBuilder.cc:217
#16 0x000003785b441257 in builder::mvll::LLVMJitBuilder::doRunOrDump 
(this=0x27005dba00, context=...) at builder/llvm/LLVMJitBuilder.cc:375
#17 0x000003785b442b73 in builder::mvll::LLVMJitBuilder::innerCloseModule 
(this=0x27005dba00, context=..., moduleDef=0x27005f0260) at 
builder/llvm/LLVMJitBuilder.cc:360
#18 0x000003785b4433cd in recursiveClose (builder=<optimized out>, context=..., 
this=<optimized out>) at builder/llvm/BJitModuleDef.h:73
#19 closeOrDefer (builder=0x27005dba00, context=..., this=0x27005f0260) at 
builder/llvm/BJitModuleDef.h:82
#20 builder::mvll::LLVMJitBuilder::closeModule (this=0x27005dba00, context=..., 
moduleDef=<optimized out>) at builder/llvm/LLVMJitBuilder.cc:383
#21 0x000003785b3cf327 in model::ModuleDef::close (this=0x27005f0260, 
context=...) at model/ModuleDef.cc:48
#22 0x000003785b3a0916 in model::Construct::parseModule (this=0x2700243370, 
context=..., module=0x27005f0260, path=..., src=...) at model/Construct.cc:397
#23 0x000003785b3a32bc in model::Construct::loadModule (this=0x2700243370, 
moduleNameBegin="crack", moduleNameEnd=..., canonicalName=...) at 
model/Construct.cc:605
#24 0x000003785b3db324 in parser::Parser::parseImportStmt (this=0x39c0f805d10, 
ns=0x2700832e68) at parser/Parser.cc:2679
#25 0x000003785b3e839d in parser::Parser::parseStatement (this=0x39c0f805d10, 
defsAllowed=true) at parser/Parser.cc:356
#26 0x000003785b3e877b in parser::Parser::parseBlock (this=0x39c0f805d10, 
nested=false, closeEvent=parser::Parser::noCallbacks) at parser/Parser.cc:485
#27 0x000003785b3e8a36 in parser::Parser::parse (this=<optimized out>) at 
parser/Parser.cc:3396
#28 0x000003785b3a090b in model::Construct::parseModule (this=0x2700243370, 
context=..., module=0x2700832e30, path=..., src=...) at model/Construct.cc:396
#29 0x000003785b3a159b in model::Construct::runScript (this=0x2700243370, 
src=..., name="example/hello.crk") at model/Construct.cc:782
#30 0x000003785b48e446 in Crack::runScript (this=0x39c0f806320, src=..., 
name="example/hello.crk") at Crack.cc:108
#31 0x00000026fea0e0fa in main (argc=4, argv=0x39c0f806768) at crack_main.cc:277

Original comment by wbr...@gmail.com on 16 Aug 2012 at 12:07

[GoogleCodeExporter]

 $ make check
mkdir -p lib/crack/ext
ln -f .libs/runtime.so lib/crack
ln -f test/.libs/testext.so lib
for ext in _cairo _gl _gtk _pcre _sdl _alsa_midi _sdlgfx _fluidsynth ; do \
  if [ -e .libs/$ext.so ]; then \
    ln -f .libs/$ext.so lib/crack/ext; \
  fi \
done
BUILD_ROOT=`pwd` ./test/screen
Using root directory: .
      build directory: /mnt/md3/cache/inst/crack-language

rebuilding screen.bin...
./test/screen: line 44: 27074 Segmentation fault      $builddir/crack -B 
llvm-native -Gl "$lib_paths" -b out=$builddir/test/screen.bin 
$root/screen/screen.crk
./test/screen: line 60: /mnt/md3/cache/inst/crack-language/test/screen.bin: No 
such file or directory
make: *** [check] Error 127

Original comment by wbr...@gmail.com on 16 Aug 2012 at 12:09

[GoogleCodeExporter]

Yeah, figures that we can't build screen.  We have an alternate test driver, 
can you run "screen/planB" and give us the output to that?

Original comment by mind...@gmail.com on 16 Aug 2012 at 12:18

[GoogleCodeExporter]

attached

Original comment by wbr...@gmail.com on 16 Aug 2012 at 12:26

Attachments:

• planB.txt

[GoogleCodeExporter]

It doesn't crash if I run: valgrind -v ./crack hello.crk 

==1429== Invalid read of size 8
==1429==    at 0x6ED3329: _wordcopy_fwd_dest_aligned (in /lib64/libc-2.14.1.so)
==1429==    by 0x6ECCFEB: __GI_memmove (in /lib64/libc-2.14.1.so)
==1429==    by 0x6E8A4CB: realpath@@GLIBC_2.3 (in /lib64/libc-2.14.1.so)
==1429==    by 0x56BA716: builder::mvll::LLVMBuilder::getSourcePath(std::string 
const&) (in /usr/local/lib64/libCrackLang.so.3.0.1)
==1429==    by 0x56E3061: 
builder::mvll::LLVMJitBuilder::createModule(model::Context&, std::string 
const&, std::string const&, model::ModuleDef*) (in 
/usr/local/lib64/libCrackLang.so.3.0.1)
==1429==    by 0x5626135: model::Context::createModule(std::string const&, 
std::string const&, model::ModuleDef*) (in 
/usr/local/lib64/libCrackLang.so.3.0.1)
==1429==    by 0x55F8D29: 
model::Construct::loadModule(__gnu_cxx::__normal_iterator<std::string const*, 
std::vector<std::string, std::allocator<std::string> > >, 
__gnu_cxx::__normal_iterator<std::string const*, std::vector<std::string, 
std::allocator<std::string> > >, std::string&) (in 
/usr/local/lib64/libCrackLang.so.3.0.1)
==1429==    by 0x56649BA: parser::Parser::parseImportStmt(model::Namespace*) 
(in /usr/local/lib64/libCrackLang.so.3.0.1)
==1429==    by 0x5651729: parser::Parser::parseAnnotation() (in 
/usr/local/lib64/libCrackLang.so.3.0.1)
==1429==    by 0x564FCED: parser::Parser::getToken() (in 
/usr/local/lib64/libCrackLang.so.3.0.1)
==1429==    by 0x5652500: parser::Parser::parseBlock(bool, 
parser::Parser::Event) (in /usr/local/lib64/libCrackLang.so.3.0.1)
==1429==    by 0x566A07A: parser::Parser::parse() (in 
/usr/local/lib64/libCrackLang.so.3.0.1)
==1429==  Address 0x800cd60 is 64 bytes inside a block of size 68 alloc'd
==1429==    at 0x4C29467: operator new(unsigned long) (vg_replace_malloc.c:287)
==1429==    by 0x676784C: std::string::_Rep::_S_create(unsigned long, unsigned 
long, std::allocator<char> const&) (in 
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.7.2/libstdc++.so.6.0.17)
==1429==    by 0x6768D77: std::string::_Rep::_M_clone(std::allocator<char> 
const&, unsigned long) (in 
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.7.2/libstdc++.so.6.0.17)
==1429==    by 0x6768EBF: std::string::reserve(unsigned long) (in 
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.7.2/libstdc++.so.6.0.17)
==1429==    by 0x67695C5: std::string::append(std::string const&) (in 
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.7.2/libstdc++.so.6.0.17)
==1429==    by 0x55EA04F: std::basic_string<char, std::char_traits<char>, 
std::allocator<char> > std::operator+<char, std::char_traits<char>, 
std::allocator<char> >(std::basic_string<char, std::char_traits<char>, 
std::allocator<char> > const&, std::basic_string<char, std::char_traits<char>, 
std::allocator<char> > const&) (in /usr/local/lib64/libCrackLang.so.3.0.1)
==1429==    by 0x55F4F24: model::Construct::joinName(std::string const&, 
std::string const&) (in /usr/local/lib64/libCrackLang.so.3.0.1)
==1429==    by 0x55F4724: model::Construct::searchPath(std::vector<std::string, 
std::allocator<std::string> > const&, __gnu_cxx::__normal_iterator<std::string 
const*, std::vector<std::string, std::allocator<std::string> > >, 
__gnu_cxx::__normal_iterator<std::string const*, std::vector<std::string, 
std::allocator<std::string> > >, std::string const&, int) (in 
/usr/local/lib64/libCrackLang.so.3.0.1)
==1429==    by 0x55F8C7E: 
model::Construct::loadModule(__gnu_cxx::__normal_iterator<std::string const*, 
std::vector<std::string, std::allocator<std::string> > >, 
__gnu_cxx::__normal_iterator<std::string const*, std::vector<std::string, 
std::allocator<std::string> > >, std::string&) (in 
/usr/local/lib64/libCrackLang.so.3.0.1)
==1429==    by 0x56649BA: parser::Parser::parseImportStmt(model::Namespace*) 
(in /usr/local/lib64/libCrackLang.so.3.0.1)
==1429==    by 0x5651729: parser::Parser::parseAnnotation() (in 
/usr/local/lib64/libCrackLang.so.3.0.1)
==1429==    by 0x564FCED: parser::Parser::getToken() (in 
/usr/local/lib64/libCrackLang.so.3.0.1)
==1429== 

Original comment by wbr...@gmail.com on 16 Aug 2012 at 12:48

[GoogleCodeExporter]

The problem valgrind is reporting may or may not be related to the crash.  
We've seen cases where doing string functions on pointers returned from 
std::string::c_str() has produced valgrind read errors before.

You may be able to fix this valgrind problem (expect to see lots of leaks after 
this) with the following patch:

--- a/builder/llvm/LLVMBuilder.cc       Sat Aug 11 00:37:59 2012 +0200
+++ b/builder/llvm/LLVMBuilder.cc       Thu Aug 16 09:41:19 2012 -0400
@@ -2785,7 +2785,9 @@
 }

 std::string LLVMBuilder::getSourcePath(const std::string &path) {
-    char *rp = realpath(path.c_str(), NULL);
+    char *temp = strdup(path.c_str());
+    char *rp = realpath(temp, NULL);
+    free(temp);
     string result;
     if (!rp) {
         result = path;

The seg-fault you are seeing may be a related problem, but what we're seeing 
from the stack trace is bizarre: "InternedString::operator <" only calls 
strcmp(), I have no idea how calloc() is getting called from there.

Original comment by mind...@gmail.com on 16 Aug 2012 at 1:48

[GoogleCodeExporter]

patch didn't solve neither crash nor valgrind problem

Original comment by wbr...@gmail.com on 16 Aug 2012 at 2:04

[GoogleCodeExporter]

Is there any way how to unhide these functions?
#0  0x000003785c2cfff9 in ?? ()
#1  0x000003785c2e68da in ?? ()
#2  0x0000000000020550 in ?? ()
#3  0x0000002700b35ab0 in ?? ()
#4  0x0000002700ac0380 in ?? ()
#5  0x000003785c2d97d7 in ?? ()
#6  0x0000037859da0e40 in ?? () from /lib64/libc.so.6
#7  0x0000037859a96b82 in calloc () from /lib64/libc.so.6
#8  0x000003785c2e4830 in ?? ()
#9  0x0000039c0f8046f0 in ?? ()

Original comment by wbr...@gmail.com on 16 Aug 2012 at 2:33

[GoogleCodeExporter]

I tried to disassemble. There are things which don't make sense
example
according to gdb it crashes at instruction "test   %eax,%eax"
#10 0x0000038e3338d57f in operator< (other=..., this=<optimized out>) at 
debug/DebugTools.cc:41

   0x0000038e3338d572 <+98>:    49 8b 74 24 20  mov    0x20(%r12),%rsi
   0x0000038e3338d577 <+103>:   48 89 ef    mov    %rbp,%rdi
   0x0000038e3338d57a <+106>:   e8 f1 07 fe ff  callq  0x38e3336dd70 <strcmp@plt>
   0x0000038e3338d57f <+111>:   85 c0   test   %eax,%eax
   0x0000038e3338d581 <+113>:   78 2d   js     0x38e3338d5b0 <(anonymous namespace)::lookUpString((anonymous namespace)::InternedString const&)+160>
   0x0000038e3338d583 <+115>:   48 8b 54 24 08  mov    0x8(%rsp),%rdx
   0x0000038e3338d588 <+120>:   64 48 33 14 25 28 00 00 00  xor    %fs:0x28,%rdx
   0x0000038e3338d591 <+129>:   49 8d 44 24 20  lea    0x20(%r12),%rax

Original comment by wbr...@gmail.com on 16 Aug 2012 at 7:05

[GoogleCodeExporter]

I tried to recompile glibc with more debugging symbols, but it didn't help
There are nonsensical addresses
#3  0x00000000000205e0 in ?? ()
#6  0x0000000000000020 in ?? ()

Program received signal SIGSEGV, Segmentation fault.
0x0000038e342cbff9 in ?? ()
(gdb) bt
#0  0x0000038e342cbff9 in ?? ()
#1  0x0000038e342e28da in ?? ()
#2  0x0000038e31d9ce60 in using_malloc_checking () from /lib64/libc.so.6
#3  0x00000000000205e0 in ?? ()
#4  0x0000004a6ffaac40 in ?? ()
#5  0x0000038e342d57d7 in ?? ()
#6  0x0000000000000020 in ?? ()
#7  0x0000038e31a92252 in __libc_calloc (n=<optimized out>, 
elem_size=<optimized out>) at malloc.c:4065
#8  0x0000038e342e0830 in ?? ()
#9  0x000003c61d4a1a00 in ?? ()
#10 0x0000038e3338d57f in operator< (other=..., this=<optimized out>) at 
debug/DebugTools.cc:41
#11 operator() (__y=..., __x=..., this=<optimized out>) at 
/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.4/include/g++-v4/bits/stl_function.h:236
#12 find (this=0x38e3414eaa0, __k=...) at 
/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.4/include/g++-v4/bits/stl_tree.h:1539
#13 find (__x=..., this=0x38e3414eaa0) at 
/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.4/include/g++-v4/bits/stl_set.h:605
#14 (anonymous namespace)::lookUpString (key=...) at debug/DebugTools.cc:60
#15 0x0000038e3343c750 in builder::mvll::LLVMJitBuilder::run 
(this=0x38e342df6a9) at builder/llvm/LLVMJitBuilder.cc:217
#16 0x0000038e3343d297 in builder::mvll::LLVMJitBuilder::doRunOrDump 
(this=0x4a6fb69460, context=...) at builder/llvm/LLVMJitBuilder.cc:375
#17 0x0000038e3343ebb3 in builder::mvll::LLVMJitBuilder::innerCloseModule 
(this=0x4a6fb69460, context=..., moduleDef=0x4a6fc2e4a0) at 
builder/llvm/LLVMJitBuilder.cc:360
#18 0x0000038e3343f40d in recursiveClose (builder=<optimized out>, context=..., 
this=<optimized out>) at builder/llvm/BJitModuleDef.h:73
#19 closeOrDefer (builder=0x4a6fb69460, context=..., this=0x4a6fc2e4a0) at 
builder/llvm/BJitModuleDef.h:82
#20 builder::mvll::LLVMJitBuilder::closeModule (this=0x4a6fb69460, context=..., 
moduleDef=<optimized out>) at builder/llvm/LLVMJitBuilder.cc:383
#21 0x0000038e333cb327 in model::ModuleDef::close (this=0x4a6fc2e4a0, 
context=...) at model/ModuleDef.cc:48
#22 0x0000038e3339c916 in model::Construct::parseModule (this=0x4a6f7b8230, 
context=..., module=0x4a6fc2e4a0, path=..., src=...) at model/Construct.cc:397
#23 0x0000038e3339f2bc in model::Construct::loadModule (this=0x4a6f7b8230, 
moduleNameBegin="crack", moduleNameEnd=..., canonicalName=...) at 
model/Construct.cc:605
#24 0x0000038e333d7324 in parser::Parser::parseImportStmt (this=0x3c61d4a3020, 
ns=0x4a6fc14458) at parser/Parser.cc:2679
#25 0x0000038e333e439d in parser::Parser::parseStatement (this=0x3c61d4a3020, 
defsAllowed=true) at parser/Parser.cc:356
#26 0x0000038e333e477b in parser::Parser::parseBlock (this=0x3c61d4a3020, 
nested=false, closeEvent=parser::Parser::noCallbacks) at parser/Parser.cc:485
#27 0x0000038e333e4a36 in parser::Parser::parse (this=<optimized out>) at 
parser/Parser.cc:3396
#28 0x0000038e3339c90b in model::Construct::parseModule (this=0x4a6f7b8230, 
context=..., module=0x4a6fc14420, path=..., src=...) at model/Construct.cc:396
#29 0x0000038e3339d59b in model::Construct::runScript (this=0x4a6f7b8230, 
src=..., name="example/hello.crk") at model/Construct.cc:782
#30 0x0000038e3348a736 in Crack::runScript (this=0x3c61d4a3630, src=..., 
name="example/hello.crk") at Crack.cc:108
#31 0x0000004a6dd7b15a in main (argc=4, argv=0x3c61d4a3a78) at crack_main.cc:277

Original comment by wbr...@gmail.com on 16 Aug 2012 at 7:12

[GoogleCodeExporter]

other.val seems to be null pointer

(gdb) frame 10
#10 0x000003b9ef45257f in operator< (other=..., this=<optimized out>) at 
debug/DebugTools.cc:41
41              return strcmp(val, other.val) < 0;
(gdb) info locals
No locals.
(gdb) p val
value has been optimized out
(gdb) p other
$1 = (const (anonymous namespace)::InternedString &) @0x3b9ee636f00: {val = 0x0}
(gdb) quit

Original comment by wbr...@gmail.com on 16 Aug 2012 at 8:08

[GoogleCodeExporter]

It can be cause of crash:

int
strcmp (p1, p2)
     const char *p1;
     const char *p2;
{
  register const unsigned char *s1 = (const unsigned char *) p1;
  register const unsigned char *s2 = (const unsigned char *) p2;
  unsigned reg_char c1, c2;

  do
    {
      c1 = (unsigned char) *s1++;
      c2 = (unsigned char) *s2++;
      if (c1 == '\0')
        return c1 - c2;
    }
  while (c1 == c2);

  return c1 - c2;
}

Original comment by wbr...@gmail.com on 16 Aug 2012 at 8:11