If I test with ls and try klee --libc=uclibc --posix-runtime --max-memory=64 --init-env ls.bc --sym-args 10 10 10 --sym-files 10 10 I get instead ... KLEE: WARNING: skipping fork (memory cap exceeded) ...
but no crash. My fd limit is: ulimit -a | grep files open files (-n) 100000 Maybe you can attach a .bc file to a bug report http://llvm.org/bugs/ Thanks, Cristi On Jul 25, 2010, at 9:35 PM, heechul Yun wrote: > Sorry, the previous mail was mistakenly sent in the middle of writing. > > I tried both with/without -max-memory=64, but they all gave me the same > result. > Stack trace at the fault is the following. > > terminate called after throwing an instance of 'std::bad_alloc' > what(): std::bad_alloc > > Program received signal SIGABRT, Aborted. > 0x0012d422 in __kernel_vsyscall () > (gdb) bt > #0 0x0012d422 in __kernel_vsyscall () > #1 0x002b0651 in *__GI_raise (sig=6) at > ../nptl/sysdeps/unix/sysv/linux/raise.c:64 > #2 0x002b3a82 in *__GI_abort () at abort.c:92 > #3 0x0020a52f in __gnu_cxx::__verbose_terminate_handler() () from > /usr/lib/libstdc++.so.6 > #4 0x00208465 in ?? () from /usr/lib/libstdc++.so.6 > #5 0x002084a2 in std::terminate() () from /usr/lib/libstdc++.so.6 > #6 0x002085e1 in __cxa_throw () from /usr/lib/libstdc++.so.6 > #7 0x00208c5f in operator new(unsigned int) () from /usr/lib/libstdc++.so.6 > #8 0x00208d3d in operator new[](unsigned int) () from /usr/lib/libstdc++.so.6 > #9 0x081c3bec in ObjectState (this=0xbfe8a1e0, os=...) at Memory.cpp:140 > #10 0x081dc5ba in klee::AddressSpace::getWriteable (this=0xbf0d2844, > mo=0xbfeec740, os=0xbfeeb480) at AddressSpace.cpp:45 > #11 0x081a51ed in klee::Executor::executeMemoryOperation (this=0x9807aa0, > state=..., isWrite=true, address=..., value=..., target=0x0) > at Executor.cpp:2981 > #12 0x081ae4d9 in klee::Executor::executeInstruction (this=0x9807aa0, > state=..., ki=0x98864a8) at Executor.cpp:1868 > #13 0x081b4562 in klee::Executor::run (this=0x9807aa0, initialState=...) at > Executor.cpp:2428 > #bc=uclibc -max-memory=48 --only-output-states-covering-new httpd.bc14 > 0x081b56ec in klee::Executor::runFunctionAsMain (this=0x9807aa0, f=0x8fb0028, > argc=1, argv=0x91f0918, envp=0xbffffb78) > at Executor.cpp:3214 > #15 0x0818b9e9 in main (argc=-1073743004, argv=0xbffffb78, envp=0xbffff620) > at main.cpp:1416 > > Is that a strange behavior? > > Best > > > On Sun, Jul 25, 2010 at 2:28 PM, heechul Yun <heechul.yun at gmail.com> wrote: > I tried > klee --libc=uclibc -max-memory=48 --only-output-states-covering-new httpd.bc > > terminate called after throwing an instance of 'std::bad_alloc' > what(): std::bad_alloc > 0 klee 0x08bfcfc8 > Aborted > > > On Sun, Jul 25, 2010 at 2:20 PM, Cristian Zamfir <cristian.zamfir at epfl.ch> > wrote: > > This is strange because Klee should handle out of memory exceptions, at least > if you provided the max-memory switch. Did you try using that? > > Cristi > > On Jul 17, 2010, at 6:11 PM, heechul Yun wrote: > > > This patch solve the segfault problem, but I encountered out of memory > > exception instead. > > It seems that the problem is not because of running out of file descriptors > > but because of running out of memory. > > > > Easy reproduction is limiting heap size with ulimit as in the following, > > > > $ ulimit -v 65536 > > > > Running klee that requires more than 64MB of memory will give the following > > memory allocation problem. > > > > $ klee --libc=uclibc --only-output-states-covering-new httpd.bc > > .. > > KLEE: WARNING: unable to open output test case .info file > > ... > > terminate called after throwing an instance of 'St9bad_alloc' > > what(): std::bad_alloc > > make: *** [test] Aborted > > > > Therefore, there will be no real fix for this (running out of memory!), but > > it may be better to catch memory exception and give user some better > > explanation. > > > > Just for curiosity, Is there anyone who is working on extending klee to > > support smp or cloud? > > > > Best Regards, > > > > Heechul > > > > On Fri, Jul 16, 2010 at 11:04 AM, Cristian Zamfir <cristian.zamfir at > > epfl.ch> wrote: > > This happens when Klee runs out of file descriptors. You can avoid it by > > increasing the number of file descriptors using ulimit. > > > > The crash happens because callers of openTestFile do not check if the > > return is NULL. > > We encountered this problem before. The attached patch should fix it, in > > the sense that it avoids crashing and prints a warning instead. If it is > > ok, I can commit it. > > > > Cristi > > > > > > > > On Jul 16, 2010, at 5:27 PM, Daniel Dunbar wrote: > > > > > Seems like it, yes. Please file a bugzilla if you have a reasonable test > > > case. > > > > > > There are cases where KLEE can fail to generate a report (the solver > > > times out, for example), but it shouldn't crash. > > > > > > - Daniel > > > > > > On Fri, Jul 16, 2010 at 7:16 AM, heechul Yun <heechul.yun at gmail.com> > > > wrote: > > >> I ran KLEE to test a http protocol parser. In the middle of symbolic > > >> execution by KLEE, it gave me the following message and halt. in the > > >> output > > >> directory, only files up to test00031.ktest. > > >> Is this a bug in KLEE? > > >> KLEE: ERROR: klee-uclibc/libc/string/strcpy.c:27: memory error: out of > > >> bound > > >> pointer > > >> KLEE: NOTE: now ignoring this error at this location > > >> KLEE: WARNING: unable to write output test case, losing it > > >> KLEE: WARNING: error opening: test000033.ptr.err > > >> 0 klee 0x08bfb468 > > >> make: *** [test] Segmentation fault > > >> -- > > >> Heechul > > >> > > >> _______________________________________________ > > >> klee-dev mailing list > > >> klee-dev at keeda.stanford.edu > > >> http://keeda.Stanford.EDU/mailman/listinfo/klee-dev > > >> > > >> > > > _______________________________________________ > > > klee-dev mailing list > > > klee-dev at keeda.stanford.edu > > > http://keeda.Stanford.EDU/mailman/listinfo/klee-dev > > > > > > > > > > > > -- > > > > Heechul > > > > > -- > > Heechul > > > > -- > > Heechul
