Frama-C Bug Tracking System - Frama-C
View Issue Details
0000530Frama-CPlug-in > jessiepublic2010-07-07 00:242010-12-18 11:19
Assigned Tocmarche 
PlatformOSOS Version
Product VersionFrama-C Boron-20100401 
Target VersionFixed in VersionFrama-C Carbon-20101202-beta2 
Summary0000530: crash
Description/usr/include/libkern/i386/_OSByteOrder.h:59:[jessie] failure: Unexpected failure.
                  Please submit bug report (Ref. "").
[kernel] The full backtrace is:
         Raised at file "src/kernel/", line 506, characters 30-31
         Called from file "src/kernel/", line 500, characters 2-9
         Re-raised at file "src/kernel/", line 503, characters 8-9
         Called from file "src/lib/", line 746, characters 40-45
         Called from file "", line 134, characters 6-20
         Called from file "src/kernel/", line 50, characters 4-20
         Called from file "src/kernel/", line 170, characters 4-8
         Plug-in jessie aborted because of an internal error.
         Please report as 'crash' at
Additional InformationI was trying to see if Frama-c/Jessie could help verify properties of code produced by a code generator we are building. Maybe the c code produced is too twisted for jessie.
TagsNo tags attached.
related to 0000541closed virgile When using -pp-annot and including stdbool.h, can't parse \false in annotations 
Attached Filesc t3.c (4,463) 2010-07-07 00:24

2010-07-08 16:04   
Your C file doesn't seem too horrible at all, and the error comes from one of the system headers on your computer, so things may go differently on ours. System header contain all sorts of horrible things, and never the same ones from one system to the next (and do you really intend to verify the code for use on this particular computer anyway?)

If you want generic, noncommittal header files, we provide quite a few of the C99/POSIX standard ones in .../share/frama-c/libc/. Since you have attached your C file, I will make a try myself when I get the chance.
2010-07-13 06:22   
Of course, it would help greatly if we distributed replacement headers that Frama-C can actually parse.

I used the commandline:

frama-c -jessie -cpp-command "gcc -I/usr/local/Frama-C_B/share/frama-c/libc -C -E " t3.c

In order to circumvent a bunch of errors of the form below, I had to patch one of the Frama-C substitution header file.

[kernel] preprocessing with "gcc -I/usr/local/Frama-C_B/share/frama-c/libc -C -E -dD t3.c"
/usr/local/Frama-C_B/share/frama-c/libc/stdlib.h:127:[kernel] user error: lexical error, illegal character \
[kernel] user error: skipping file "t3.c" that has errors.
[kernel] Frama-C aborted because of an invalid user input.

The patch follows below. Once this problem was out of the way, the next, and probably last (but one never knows, one never knows) issue appears to be that of recognition of the C99 bool type by Jessie:

Manzana:t3 pascal$ frama-c -jessie -cpp-command "gcc -I/usr/local/Frama-C_B/share/frama-c/libc -C -E " t3.c
[kernel] preprocessing with "gcc -I/usr/local/Frama-C_B/share/frama-c/libc -C -E -dD t3.c"
[jessie] Starting Jessie translation
[jessie] Producing Jessie files in subdir t3.jessie
[jessie] File t3.jessie/t3.jc written.
[jessie] File t3.jessie/t3.cloc written.
[jessie] Calling Jessie tool in subdir t3.jessie
File "t3.jc", line 36, characters 2-7: typing error: unknown type _bool
[jessie] user error: Jessie subprocess failed: jessie -why-opt -split-user-conj -v -locs t3.cloc t3.jc

I guess that Claude is the only person who can tell if (C99) bool support in Jessie in a long way off, but meanwhile, while not continue the experiment by putting an enum definition instead in stdbool.h (using the right macros so as not to clash with the C99 bool type)?

Good luck...

Manzana:t3 pascal$ diff -u ~/ppc/share/libc/stdlib.h /usr/local/Frama-C_B/share/frama-c/libc/stdlib.h
--- /Users/pascal/ppc/share/libc/stdlib.h 2010-04-26 18:42:31.000000000 +0200
+++ /usr/local/Frama-C_B/share/frama-c/libc/stdlib.h 2010-07-13 06:08:21.000000000 +0200
@@ -124,7 +124,7 @@
 /* ISO C: 7.20.4 */
-/*@ terminates \false; */
+/* @ terminates \false; */
 void abort(void);
 /*@ assigns \result \from \nothing ;*/
@@ -134,16 +134,16 @@
 int at_quick_exit(void (*func)(void));
- terminates \false;
+// terminates \false;
   assigns \nothing;
- ensures \false;
+// ensures \false;
 void exit(int status);
- terminates \false;
+// terminates \false;
   assigns \nothing;
- ensures \false;
+// ensures \false;
 void _Exit(int status);
@@ -153,9 +153,9 @@
 char *getenv(const char *name);
- terminates \false;
+// terminates \false;
   assigns \nothing;
- ensures \false; */
+// ensures \false; */
 void quick_exit(int status);
 /*@ assigns \result \from string[..]; */
Manzana:t3 pascal$
2010-07-13 06:45   

Actually, the parsing error that I first bumped into only happens when using the -jessie option. I will investigate a little further and report it here when I understand it better.

It all depends what kind of properties you intended to check, but with the commandline:

frama-c-gui -cpp-command "gcc -I/usr/local/Frama-C_B/share/frama-c/libc -C -E " t3.c -val -slevel 100

the value analysis is precise enough to tell that there are no run-time errors in the execution of the program, and to give variation ranges for some variables and structure fields.
2010-12-16 16:48   

Why 2.28 outputs a better error message. The problem is is the specification: equality over structures are not supported and should be replaced by the equality of all the fields (e.g. defined as logic predicate)

Issue History
2010-07-07 00:24agoodloeNew Issue
2010-07-07 00:24agoodloeStatusnew => assigned
2010-07-07 00:24agoodloeAssigned To => cmarche
2010-07-07 00:24agoodloeFile Added: t3.c
2010-07-08 16:04pascalNote Added: 0000984
2010-07-13 06:22pascalNote Added: 0001002
2010-07-13 06:45pascalNote Added: 0001003
2010-07-30 16:34virgileRelationship addedrelated to 0000541
2010-12-16 16:48cmarcheNote Added: 0001315
2010-12-16 16:48cmarcheStatusassigned => resolved
2010-12-16 16:48cmarcheResolutionopen => fixed
2010-12-18 11:18signolesFixed in Version => Frama-C Carbon-20101202-beta2
2010-12-18 11:19signolesStatusresolved => closed