KLEE with uclibc will hang if a call to fscanf is made.

[delcypher]

Take concrete input file (numbers.txt):

50 55

and program (open.c):

#include <stdio.h>

int main(int argc, char* argv[])
{
  int numbers[2];
  FILE* f = fopen(argv[1],"r");

  if(f==0)
    return 1;

  int numGet = fscanf(f,"%i %i", numbers, (numbers) + 1);

  printf("Received: %i , %i\n",numbers[0],numbers[1]);

  if(numbers[0] > 0)
  {
    printf("first num > 0\n");
    if(numbers[1] > 0)
    {
      printf("second num > 0\n");
    }
    else
      printf("second num <= 0\n");
  }
  else
    printf("first num <= 0\n");
}

Compile this to llvm bitcode and try to run this is KLEE
$ llvm-gcc --emit-llvm open.c -o open.bc
$ klee --posix-runtime --libc=uclibc open.bc numbers.txt

KLEE will output the following and then hang:

KLEE: NOTE: Using model: /data/dev/KLEE/klee/bin/Release+Asserts/lib/libkleeRuntimePOSIX.bca
KLEE: output directory = "klee-out-47"
KLEE: WARNING: undefined reference to function: __isoc99_fscanf
KLEE: WARNING: undefined reference to function: __xstat64
KLEE: WARNING ONCE: calling external: syscall(16, 0, 21505, 38994784)
KLEE: WARNING ONCE: calling __user_main with extra arguments.
KLEE: WARNING ONCE: calling external: __xstat64(1, 38936544, 39025120)
KLEE: WARNING ONCE: calling external: __isoc99_fscanf(39026192, 38868928, 39102320, 39102324)

It appears that that KLEE is stuck in the JIT

(gdb) bt
#0  __lll_lock_wait_private () at         ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:93
#1  0x00007ffff6e46488 in _L_lock_53 () from /lib/x86_64-linux-gnu/libc.so.6
#2  0x00007ffff6e4639f in __isoc99_fscanf (stream=0x1e64a50, format=0x1e126d0 "%i %i") at isoc99_fscanf.c:31
#3  0x00007ffff7ed71d8 in __unnamed_1 ()
#4  0x00000000008a2449 in llvm::JIT::runFunction(llvm::Function*, std::vector<llvm::GenericValue, std::allocator<llvm::GenericValue> > const&) ()
#5  0x0000000000591ab8 in klee::ExternalDispatcher::runProtectedCall (this=0x1bc2eb0, f=0x1e37860, args=<optimised out>) at /data/dev/KLEE/klee/src/lib/Core/ExternalDispatcher.cpp:189
#6  0x000000000059265e in klee::ExternalDispatcher::executeCall (this=0x1bc2eb0, f=<optimised out>, i=0x1505158, args=0x7fffffffc160) at /data/dev/KLEE/klee/src/lib/Core/ExternalDispatcher.cpp:164
#7  0x000000000057bb12 in klee::Executor::callExternalFunction (this=0x1a83860, state=..., target=0x17bb420, function=0x1505380, arguments=...) at /data/dev/KLEE/klee/src/lib/Core/Executor.cpp:2724
#8  0x000000000057f996 in klee::Executor::executeCall (this=0x1a83860, state=..., ki=0x17bb420, f=0x1505380, arguments=...) at /data/dev/KLEE/klee/src/lib/Core/Executor.cpp:1097
#9  0x0000000000585157 in klee::Executor::executeInstruction (this=<optimised out>, state=..., ki=<optimised out>) at /data/dev/KLEE/klee/src/lib/Core/Executor.cpp:1604
#10 0x00000000005880db in klee::Executor::run (this=0x1a83860, initialState=...) at /data/dev/KLEE/klee/src/lib/Core/Executor.cpp:2465
#11 0x0000000000588b46 in klee::Executor::runFunctionAsMain (this=<optimised out>, f=0x1c780b8, argc=2, argv=0x1786600, envp=0x7fff000000d0) at /data/dev/KLEE/klee/src/lib/Core/Executor.cpp:3257
#12 0x0000000000561207 in main (argc=<optimised out>, argv=<optimised out>, envp=0x7fffffffea18) at /data/dev/KLEE/klee/src/tools/klee/main.cpp:1429

This was an issue I noticed a while ago and a recent mailing list post ( http://www.mail-archive.com/klee-dev@imperial.ac.uk/msg01259.html ) reminded me of this.

Uclibc seems to provide fscanf so I'm not quite sure why KLEE is trying to call fscanf externally. I unfortunately do not have time to investigate now.

[MartinNowack]

Hi @delcypher ,
In case you've some time can you check if it works when you you explicitly compile your application with gcc -std=c89 under your setup (http://stackoverflow.com/questions/16376341/isoc99-scanf-and-scanf)? KLEE tries to call '__isoc99_fscanf' which is indeed not defined by uclibc. Maybe we have to add a wrapper for this.

Thanks,
Martin

[afsafzal]

I have the same issue with KLEE. There's a program which calls scanf to get the input to the program and I need to find all the paths for this program. Unfortunately KLEE hangs for the input (which I don't have).
I've also tried the -std=c89 option but it didn't work.

[yxliang01]

I have tried -std=c89 and it works. However, the target program that I want to run with KLEE contains C99 features. Would be great if there is some quick workaround or fix for this.

Thanks

[MartinNowack]

@yxliang01 This bugreport is quite old. Currently I cannot reproduce @delcypher's example. Which KLEE and LLVM version are you using? What is the output of KLEE?

[yxliang01]

@MartinNowack

Program used:

#include <stdio.h>

int main(int argc, char** argv) {
int a;
scanf("%d", &a);
printf("%d", a);
return 0;
}

Compiled using wllvm with clang version 3.4 and flag -std=c99 was added, LLVM 3.4, KLEE commit dcea8bb , inside docker container built with KLEE dockerfile.

KLEE command: klee -optimize -libc=uclibc -posix-runtime a.out.bc -sym-stdin 10

KLEE output:

KLEE: NOTE: Using klee-uclibc : /home/klee/klee_build/klee/Release+Debug+Asserts/lib/klee-uclibc.bca
KLEE: NOTE: Using model: /home/klee/klee_build/klee/Release+Debug+Asserts/lib/libkleeRuntimePOSIX.bca
KLEE: output directory is "/home/klee/klee-out-3"
KLEE: Using STP solver backend
KLEE: WARNING: undefined reference to function: __isoc99_scanf
KLEE: WARNING ONCE: calling external: syscall(16, 0, 21505, 64152400) at /home/klee/klee_src/runtime/POSIX/fd.c:980
KLEE: WARNING ONCE: Alignment of memory from call "malloc" is not modelled. Using alignment of 8.
KLEE: WARNING ONCE: calling external: __isoc99_scanf(77030816, 68382976) at /home/klee/klee_src/runtime/POSIX/fd_init.c:160

I am actually kind of surprised that you can't reproduce. Would be great if you can also pose your experiment setting.

Thanks

[MartinNowack]

Thanks, I could reproduce the problem.

@yxliang01 please use -std=c89 to compile the input file. With this you can workaround the problem.

[yxliang01]

Thanks @MartinNowack. However, like what I said in the previous comment, the target programs that I want to run with KLEE requires C99. Therefore, using -std=c89 is not a solution for this case.

[MartinNowack]

@yxliang01 Ah, sorry, misread this.

A couple of options, but they all have their drawbacks

• comment out the part of the code
• add an alias for __iso99_scanf into KLEE tool/klee/main.cpp that works in my case

     replaceOrRenameFunction(mainModule, "__libc_open", "open");
     replaceOrRenameFunction(mainModule, "__libc_fcntl", "fcntl");
     replaceOrRenameFunction(mainModule, "scanf", "__isoc99_scanf");

[yxliang01]

@MartinNowack Thanks for the workaround. However... It didn't work for me. Could you share your experiment setting and did you modify base on commit 495b3e5 ?

Thanks

[MartinNowack]

Interesting. With master you have indeed this issue and indeed it still indicates that it calls an external function.
Please apply the following patch on top of #868 This works for me.

diff --git a/tools/klee/main.cpp b/tools/klee/main.cpp
index 589ce98..b001550 100644
--- a/tools/klee/main.cpp
+++ b/tools/klee/main.cpp
@@ -1071,6 +1071,7 @@ linkWithUclibc(StringRef libDir,
   for (auto i = newModules, j = modules.size(); i < j; ++i) {
     replaceOrRenameFunction(modules[i].get(), "__libc_open", "open");
     replaceOrRenameFunction(modules[i].get(), "__libc_fcntl", "fcntl");
+replaceOrRenameFunction(modules[i].get(), "scanf", "__isoc99_scanf");
   }

   createLibCWrapper(modules, EntryPoint, "__uClibc_main");

[yxliang01]

@MartinNowack Indeed, this workaround works if the base is the pr #868 . Do you know which part of #868 is crucial for replaceOrRenameFunction function to be functional? Since I want to do this workaround on the klee-float fork. I have tried applying just the workaround, but it didn't work. Looks like I need to kind of porting at least part of #868 to the fork. As a result, it would be useful if you know why replaceOrRenameFunction doesn't work for master codebase.

Thanks @MartinNowack

[MartinNowack]

@yxliang01 Well, I'm afraid that there is no easy way out.
#868 Has some major changes according to the linking infrastructure of KLEE.
In a nutshell, it loads all the modules which might be needed, iteratively instruments and links missing dependencies, and finally optimizes the result.
The old version loads + links, instrument, links other libraries in and and optimizes.

[yxliang01]

@MartinNowack Are there other quick fixes or workarounds that don't use replaceOrRenameFunction? So that, the bug related to replaceOrRenameFunction is not needed to be fixed by manually porting #868. The porting is really nontrivial while floating point support is quite important to my case.

Thanks!

[MartinNowack]

@yxliang01 maybe you just copy the function scanf and add it as __isoc99_scanf into uclibc and recompile. maybe that can help already.

[yxliang01]

@MartinNowack Indeed, copy scanf function and rename it to __isoc99_scanf in klee-uclibc solves this problem. Thanks!

[hasanur-rahman]

@MartinNowack Indeed, copy scanf function and rename it to __isoc99_scanf in klee-uclibc solves this problem. Thanks!

Is it copying 'scanf' or 'fscanf'?

[hasanur-rahman]

@yxliang01 maybe you just copy the function scanf and add it as __isoc99_scanf into uclibc and recompile. maybe that can help already.

It worked. Thanks.