From haoxintu.2020 at phdcs.smu.edu.sg Wed Jan 24 15:53:46 2024 From: haoxintu.2020 at phdcs.smu.edu.sg (TU Haoxin) Date: Wed, 24 Jan 2024 15:53:46 +0000 Subject: [klee-dev] Different behavior when invoking the "error" function with the argument buffer from heap or stack Message-ID: Dear KLEE developers, Hope you are all doing well, and hope this is the right place to raise questions about KLEE. I have a question regarding the modeling of the function `error` function in `klee-uclibc` when I used KLEE. Since I couldn't find similar cases either in the GitHub issue or the klee-dev mailing list, I would like to seek your suggestions here. I do apologize if I missed anything. Please consider the following simple code (test.c): ``` #include #include #include #include #include static void * //_GL_ATTRIBUTE_PURE nonnull (void *p) { if (!p){ exit(1); } return p; } void * xxmalloc (int s){ return nonnull (malloc(s)); } int main(){ char *p =(char*) xxmalloc(10); // p from heap memset(p, 'A', 10); error(1, 1, p, p); // this is problematic //char* pp = "hello world.\n"; // pp from stack //error(1, 1, pp, pp); // this is ok free(p); return 0; } ``` Commands to compile the above code and run klee (execute.sh): ``` #!/bin/bash clang -emit-llvm -c -g test.c klee --libc=uclibc --posix-runtime test.bc ``` Execute the script `execute.sh`, I got the following: ``` KLEE: WARNING: executable has module level assembly (ignoring) KLEE: WARNING ONCE: calling external: syscall(16, 0, 21505, 93825035744416) at runtime/POSIX/fd.c:1007 10 KLEE: WARNING ONCE: Alignment of memory from call "malloc" is not modelled. Using alignment of 8. KLEE: WARNING ONCE: calling __klee_posix_wrapped_main with extra arguments. KLEE: ERROR: libc/stdio/_vfprintf.c:572: memory error: out of bound pointer KLEE: NOTE: now ignoring this error at this location KLEE: done: total instructions = 17386 KLEE: done: completed paths = 0 KLEE: done: partially completed paths = 1 KLEE: done: generated tests = 1 ``` Here is the stack information when the error occurs: ``` Error: memory error: out of bound pointer File: libc/stdio/_vfprintf.c Line: 572 assembly.ll line: 18473 State: 1 Stack: ??????#000018473 in _ppfs_init (=93825004575232, =93825035189056) at libc/stdio/_vfprintf.c:572 ??????#100015268 in vfprintf (=93825004959696, =93825035189056, =93825035841056) at libc/stdio/_vfprintf.c:1888 ??????#200012650 in __error (=1, =1, =93825035189056) at libc/misc/error/error.c:57 ??????#300009767 in __klee_posix_wrapped_main () at test.c:24 ??????#400007354 in __user_main (=1, =93825013002624, =93825013002640) at runtime/POSIX/klee_init_env.c:245 ??????#500000592 in __uClibc_main (=93825035146016, =1, =93825013002624, =0, =0, =0, =0) at libc/misc/internals/__uClibc_main.c:401 ??????#600000757 in main (=1, =93825013002624) Info: ??????address: 93825035189066 ??????next: object at 93825004575232 of size 256 ????????????MO7712[256] allocated at vfprintf(): %7 = alloca %struct.ppfs_t.715, align 16 ``` I tested the above code using clang-9 with klee-2.1 (as well as klee-2.3-pre). ``` $klee --version KLEE 2.3-pre (https://klee.github.io) Build mode: Debug (Asserts: ON) Build revision: 0ba95edbad26fe70c8132f0731778d94f9609874 LLVM (http://llvm.org/): LLVM version 9.0.0 Optimized build. Default target: x86_64-pc-linux-gnu Host CPU: skylake-avx512 ``` The confusion is that when I replaced the pointer `p` from the heap to `pp` from the stack (as shown in the two commented lines), KLEE could execute the function `error` well. I think both the buffers from the heap or stack should work (I tested the native execution and these two versions of code both work ok) but it does not in KLEE, and I don't know why that is the case. Since the `error` function involves variadic arguments (https://github.com/klee/klee-uclibc/blob/klee_0_9_29/libc/misc/error/error.c#L50), I suspect that this is because KLEE has some implementation limitations of the handling of variadic functions when it involves the pointers from the heap (I also tried to find the reason behind it but failed). Could you please take a look and help me understand about this case? Why does KLLE behave differently when the pointer is from the heap or stack? Any ideas or insights are welcome! Thank you so much for your time and help! Best regards, Haoxin -------------- next part -------------- HTML attachment scrubbed and removed From c.cadar at imperial.ac.uk Wed Jan 24 20:52:25 2024 From: c.cadar at imperial.ac.uk (Cristian Cadar) Date: Wed, 24 Jan 2024 20:52:25 +0000 Subject: [klee-dev] Different behavior when invoking the "error" function with the argument buffer from heap or stack In-Reply-To: References: Message-ID: <651a6cad-d75f-40a4-b732-828fa3e30779@imperial.ac.uk> Hi Haoxin, It looks to me that you are not passing a null-terminated string to error() in the heap case, and the error reported by KLEE is genuine. Best, Cristian On 24/01/2024 15:53, TU Haoxin wrote: > Dear KLEE developers, > > Hope you are all?doing?well, and hope this is the right place to raise > questions about KLEE. > > I have a question regarding the modeling of the function `error` > function in `klee-uclibc` when I used KLEE. Since I couldn't find > similar cases either in the GitHub issue or the klee-dev mailing list, I > would like to seek your suggestions here. I do apologize if I missed > anything. > > Please consider the following simple code (test.c): > ``` > #include > #include > #include > #include > #include > > static void * //_GL_ATTRIBUTE_PURE > nonnull (void *p) > { > ? if (!p){ > ? ? exit(1); > ? } > ? return p; > } > > void * xxmalloc (int s){ > ? ? return nonnull (malloc(s)); > } > > int main(){ > ? ? char *p =(char*) xxmalloc(10); // p from heap > ? ? memset(p, 'A', 10); > ? ? error(1, 1, p, p); // this is problematic > ? ? //char* pp = "hello world.\n"; // pp from stack > ? ? //error(1, 1, pp, pp); // this is ok > ? ? free(p); > ? ? return 0; > } > ``` > > Commands to compile the above code and run klee (execute.sh): > ``` > #!/bin/bash > clang -emit-llvm -c -g test.c > klee --libc=uclibc --posix-runtime test.bc > ``` > > Execute the script `execute.sh`, I got the following: > > ``` > KLEE: WARNING: executable has module level assembly (ignoring) > KLEE: WARNING ONCE: calling external: syscall(16, 0, 21505, > 93825035744416) at runtime/POSIX/fd.c:1007 10 > KLEE: WARNING ONCE: Alignment of memory from call "malloc" is not > modelled. Using alignment of 8. > KLEE: WARNING ONCE: calling __klee_posix_wrapped_main with extra arguments. > KLEE: ERROR: libc/stdio/_vfprintf.c:572: memory error: out of bound pointer > KLEE: NOTE: now ignoring this error at this location > > KLEE: done: total instructions = 17386 > KLEE: done: completed paths = 0 > KLEE: done: partially completed paths = 1 > KLEE: done: generated tests = 1 > ``` > > Here is the stack information when the error occurs: > ``` > Error: memory error: out of bound pointer > File: libc/stdio/_vfprintf.c > Line: 572 > assembly.ll line: 18473 > State: 1 > Stack: > ??????#000018473 in _ppfs_init (=93825004575232, =93825035189056) at > libc/stdio/_vfprintf.c:572 > ??????#100015268 in vfprintf (=93825004959696, =93825035189056, > =93825035841056) at libc/stdio/_vfprintf.c:1888 > ??????#200012650 in __error (=1, =1, =93825035189056) at > libc/misc/error/error.c:57 > ??????#300009767 in __klee_posix_wrapped_main () at test.c:24 > ??????#400007354 in __user_main (=1, =93825013002624, =93825013002640) > at runtime/POSIX/klee_init_env.c:245 > ??????#500000592 in __uClibc_main (=93825035146016, =1, =93825013002624, > =0, =0, =0, =0) at libc/misc/internals/__uClibc_main.c:401 > ??????#600000757 in main (=1, =93825013002624) > Info: > ??????address: 93825035189066 > ??????next: object at 93825004575232 of size 256 > ????????????MO7712[256] allocated at vfprintf(): ?%7 = alloca > %struct.ppfs_t.715, align 16 > ``` > I tested the above code using clang-9 with klee-2.1 (as well as > klee-2.3-pre). > ``` > $klee --version > KLEE 2.3-pre (https://klee.github.io) > ? Build mode: Debug (Asserts: ON) > ? Build revision: 0ba95edbad26fe70c8132f0731778d94f9609874 > > LLVM (http://llvm.org/): > ? LLVM version 9.0.0 > ? Optimized build. > ? Default target: x86_64-pc-linux-gnu > ? Host CPU: skylake-avx512 > ``` > > The confusion is that when I replaced the pointer `p` from the heap to > `pp` from the stack (as shown in the two commented lines), KLEE could > execute the function `error` well. I think both the buffers from the > heap or stack should work (I tested the native execution and these two > versions of code both work ok)?but it does not in KLEE, and?I don't know > why that is the case. Since the `error` function involves variadic > arguments > (https://github.com/klee/klee-uclibc/blob/klee_0_9_29/libc/misc/error/error.c#L50 ), I suspect that this is because KLEE has some implementation limitations of the handling of variadic?functions when it involves the pointers from the heap (I also tried to find the reason behind it but failed). Could you?please take?a?look and help me understand about this case? Why does KLLE behave differently when the pointer is from the heap or stack? Any ideas or insights are welcome! > > Thank you so?much for your time and help! > > > Best regards, > Haoxin > > _______________________________________________ > klee-dev mailing list > klee-dev at imperial.ac.uk > https://mailman.ic.ac.uk/mailman/listinfo/klee-dev From zhangbohan039 at gmail.com Thu Jan 25 04:07:28 2024 From: zhangbohan039 at gmail.com (Bohan) Date: Wed, 24 Jan 2024 22:07:28 -0600 Subject: [klee-dev] Mapping Path Constraint to the Actual Path in Source Code Message-ID: ???:klee-dev at imperial.ac.uk ?? 2024/1/24 19:18 Hi, I am new to Klee. I have a question about how to determine which path constraints generated in the KQuery file correspond to specific paths or lines of code in the original source code or in the IR? For example; I have a dummy c code that have 3 path, #include #include int main() { int num; int a = 10; // Make 'num' a symbolic variable klee_make_symbolic(&num, sizeof(num), "num"); if (num > a + 3) { printf("branch 0.\n"); } else if (num < a) { printf("branch 1.\n"); } else { printf("branch 2.\n"); } return 0; } And here is the Kquery file for a ktest file where the num = 2147483647, and it goes to branch 0. array num[4] : w32 -> w8 = symbolic (query [(Slt 13 (ReadLSB w32 0 num))] false) My question is there any info from Klee that tells this query is for the branch 0. Thank you very much for help! -------------- next part -------------- HTML attachment scrubbed and removed From c.cadar at imperial.ac.uk Thu Jan 25 21:10:17 2024 From: c.cadar at imperial.ac.uk (Cristian Cadar) Date: Thu, 25 Jan 2024 21:10:17 +0000 Subject: [klee-dev] Mapping Path Constraint to the Actual Path in Source Code In-Reply-To: References: Message-ID: Hi, KLEE does not provide this information, although you could add such metadata when adding a new constraint. However, because constraint solving optimisations could combine constraints, obtaining the origin of a constraint might not be possible in the general case. Best, Cristian On 25/01/2024 04:07, Bohan wrote: > > ???:klee-dev at imperial.ac.uk > ?? 2024/1/24 19:18 > > Hi, > > I am new to Klee. I have a question about how to determine which path > constraints generated in the KQuery file correspond to specific paths or > lines of code in the original source code or in the IR? > > For example; I have a dummy c code that have 3 path, > > #include? #include? int?main() { ? ? int?num; > int?a?=?10; ? ? // Make 'num' a symbolic variable > klee_make_symbolic(&num, sizeof(num), "num"); ? ? if?(num?>?a?+?3) { > ? ? printf("branch 0.\n"); ? ? } else?if?(num? printf("branch 1.\n"); ? ? } else?{ ? ? ? ? printf("branch 2.\n"); ? ? } > ? ? return?0; } > > And here is the Kquery file for a ktest file where the num = 2147483647, > and it goes to branch 0. > > |array num[4] : w32 -> w8 = symbolic (query [(Slt 13 > (ReadLSB w32 0 num))] ? ? ? ? false) | > > My question is there any info from Klee that tells this query is for the > branch 0. > > Thank you very much for help! > > > _______________________________________________ > klee-dev mailing list > klee-dev at imperial.ac.uk > https://mailman.ic.ac.uk/mailman/listinfo/klee-dev From haoxintu.2020 at phdcs.smu.edu.sg Wed Jan 31 05:07:30 2024 From: haoxintu.2020 at phdcs.smu.edu.sg (TU Haoxin) Date: Wed, 31 Jan 2024 05:07:30 +0000 Subject: [klee-dev] Different behavior of KLEE when testing `dircolors` with "--optimize=true/false" option Message-ID: Dear KLEE developers, I found an interesting behavior of KLEE while using a variant tool of KLEE (https://github.com/haoxintu/SymLoc) to test the dircolors? package in GNU Coreutils. The behavior is that KLEE fails to fork at a branch that should be forked with the option --optimize option enabled (i.e., --optimize=true). While the --optimize option is disabled (i.e., --optimize=false), the branch can be successfully forked as usual. Please check more details at https://gist.github.com/haoxintu/183dda2923965d1e33f64ad59c7f5338. (I recorded here mainly because the markdown format makes it easy to present some code examples). Could you please look at this case and check if this is a potential issue in KLEE's optimization (LLVM's optimization probably)? Please also let me know if I can provide anything further. Thank you very much for your time and help! Best regards, Haoxin -------------- next part -------------- HTML attachment scrubbed and removed From cnx at loang.net Wed Jan 31 05:34:48 2024 From: cnx at loang.net (=?utf-8?q?Nguy=E1=BB=85n_Gia_Phong?=) Date: Wed, 31 Jan 2024 14:34:48 +0900 Subject: [klee-dev] Different behavior of KLEE when testing `dircolors` with "--optimize=true/false" option In-Reply-To: References: Message-ID: On 2024-01-31 at 05:07+00:00, TU Haoxin wrote: > The behavior is that KLEE fails to fork at a branch > that should be forked with the option --optimize option enabled > (i.e., --optimize=true). While the --optimize option is disabled > i.e., --optimize=false), the branch can be successfully forked [...] > > ### Reproduce the behavior > #### Enviroment > * KLEE-2.1 (also tested KLEE-2.3, and they behave the same) Just curious, is the issue reproducible for KLEE 3? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 248 bytes Desc: not available URL: From haoxintu.2020 at phdcs.smu.edu.sg Wed Jan 31 06:58:12 2024 From: haoxintu.2020 at phdcs.smu.edu.sg (TU Haoxin) Date: Wed, 31 Jan 2024 06:58:12 +0000 Subject: [klee-dev] Different behavior of KLEE when testing `dircolors` with "--optimize=true/false" option In-Reply-To: References: Message-ID: Hi Nguyen, Just installed and run this case using KLEE-3.0 with LLVM-10, and it seems the issue is still reproducible for KLEE 3. Please check more here: https://gist.github.com/haoxintu/183dda2923965d1e33f64ad59c7f5338#other-trials Thanks, Haoxin ________________________________ From: Nguy?n Gia Phong Sent: Wednesday, January 31, 2024 13:34 To: TU Haoxin; klee-dev at imperial.ac.uk Subject: Re: [klee-dev] Different behavior of KLEE when testing `dircolors` with "--optimize=true/false" option On 2024-01-31 at 05:07+00:00, TU Haoxin wrote: > The behavior is that KLEE fails to fork at a branch > that should be forked with the option --optimize option enabled > (i.e., --optimize=true). While the --optimize option is disabled > i.e., --optimize=false), the branch can be successfully forked [...] > > ### Reproduce the behavior > #### Enviroment > * KLEE-2.1 (also tested KLEE-2.3, and they behave the same) Just curious, is the issue reproducible for KLEE 3? -------------- next part -------------- HTML attachment scrubbed and removed From d.schemmel at imperial.ac.uk Wed Jan 31 23:26:15 2024 From: d.schemmel at imperial.ac.uk (Daniel Schemmel) Date: Wed, 31 Jan 2024 23:26:15 +0000 Subject: [klee-dev] Different behavior of KLEE when testing `dircolors` with "--optimize=true/false" option In-Reply-To: References: Message-ID: Hi Haoxin, The described behavior is indeed very odd. Luckily, the `assembly.ll` that is generated by KLEE shows that this is an actual optimization error - the code that is intended to print your messages does not exist anymore. This means that the issue lies either with the LLVM optimization passes, or in our usage of them. As you were using fairly old LLVM versions (LLVM 9 & 10 support is about to be removed from KLEE ), I tried to reproduce the issue in a few different configurations: - LLVM 9 (KLEE master): REPRODUCED - LLVM 10 (KLEE master): REPRODUCED - LLVM 11 (KLEE master): NOT reproduced - LLVM 12 (KLEE master): NOT reproduced - LLVM 13 (docker.io/klee/klee): NOT reproduced - LLVM 14 (KLEE master): NOT reproduced - LLVM 15 (#1664 ): NOT reproduced - LLVM 16 (#1664 ): requires an additional include in xmalloc.c to compile; NOT reproduced Since this bug only occurs with the two LLVM versions that are about to be removed in the next few days anyway, and there is a hard break (none of the newer versions exhibit the same behavior), I tend towards assuming that this specific issue probably stems from an old LLVM bug that has since been rectified. Best, Daniel On 2024-01-31 06:58, TU Haoxin wrote: > Hi Nguyen, > > Just installed and run this case using KLEE-3.0 with LLVM-10, and it > seems the issue is still reproducible for KLEE 3. > > Please check more here: > https://gist.github.com/haoxintu/183dda2923965d1e33f64ad59c7f5338#other-trials > > > > Thanks, > Haoxin > > > > ------------------------------------------------------------------------ > *From:*?Nguy?n Gia Phong > *Sent:*?Wednesday, January 31, 2024 13:34 > *To:*?TU Haoxin; klee-dev at imperial.ac.uk > *Subject:*?Re: [klee-dev] Different behavior of KLEE when testing > `dircolors` with "--optimize=true/false" option > > On 2024-01-31 at 05:07+00:00, TU Haoxin wrote: > > The behavior is that KLEE fails to fork at a branch > > that should be forked with the option --optimize option enabled > > (i.e., --optimize=true).? While the --optimize option is disabled > > i.e., --optimize=false), the branch can be successfully forked [...] > > > > ### Reproduce the behavior > > #### Enviroment > > * KLEE-2.1 (also tested KLEE-2.3, and they behave the same) > > Just curious, is the issue reproducible for KLEE 3? > > _______________________________________________ > klee-dev mailing list > klee-dev at imperial.ac.uk > https://mailman.ic.ac.uk/mailman/listinfo/klee-dev -------------- next part -------------- HTML attachment scrubbed and removed