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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://keeda.Stanford.EDU/pipermail/klee-dev/attachments/20100725/7e20fdf0/attachment-0001.html
