fuzzilli

fuzzilli copied to clipboard

I run fuzzilli with this command 'swift run -c release FuzzilliCli --profile="v8" --jobs=48 --storeagePath=/result /home/v8/out/fuzzbuild/d8 --minCorpusSize=10240 --engine=hybrid'

After running few hour, it died with this message 'Illegal instruction (core dump)'

in the statistics report, it covered d8 14.98%.

How can i find out which part of the program has problem. is there any log files?

I also had same result with ''swift run -c release FuzzilliCli --profile="v8" --jobs=48 --storeagePath=/result /home/v8/out/fuzzbuild/d8 --minCorpusSize=10240 --engine=multi'

Thanks,

That's not really debuggable without more information.

Here's what I use to get good debug information: Compile with swift build -Xswiftc -g -Xlinker --export-dynamic, which produces a debug build with symbols at .build/debug/FuzzilliCli

Then, run that in gdb or the debugger of your choice to get a stack trace at the point of crash.

@saelo I'm not sure this is what happened to the original poster, but I did hit a similar while running testing the Markov corpus. From my understanding, Swift compiles integer sizing issues into the ud2 instruction, which produces the error above. Here's the stack trace I got, due to trying to assign a variable id greater than can be stored in 16 bits.

Swift/Integers.swift:3444: Fatal error: Not enough bits to represent the passed value
Current stack trace:
0    libswiftCore.so                    0x00007efd827eb210 swift_reportError + 50
1    libswiftCore.so                    0x00007efd8285ffc0 _swift_stdlib_reportFatalErrorInFile + 112
2    libswiftCore.so                    0x00007efd82549f56 <unavailable> + 1425238
3    libswiftCore.so                    0x00007efd82549b7f <unavailable> + 1424255
4    libswiftCore.so                    0x00007efd8254991c <unavailable> + 1423644
5    libswiftCore.so                    0x00007efd82549430 _assertionFailure(_:_:file:line:flags:) + 441
6    libswiftCore.so                    0x00007efd82547f9c <unavailable> + 1417116
7    FuzzilliCli                        0x000055c58b416090 Variable.init(number:) + 115
8    FuzzilliCli                        0x000055c58b3a3e10 Instruction.init<A>(_:inouts:index:) + 341
9    FuzzilliCli                        0x000055c58b39bef0 Code.append(_:) + 197
10   FuzzilliCli                        0x000055c58b333e60 ProgramBuilder.internalAppend(_:) + 804
11   FuzzilliCli                        0x000055c58b327870 ProgramBuilder.adopt(_:keepTypes:) + 420
12   FuzzilliCli                        0x000055c58b4a9f7c <unavailable> + 3850108
13   FuzzilliCli                        0x000055c58b326250 ProgramBuilder.adopting(from:_:) + 84
14   FuzzilliCli                        0x000055c58b4a9160 BaseInstructionMutator.mutate(_:using:) + 2212
15   FuzzilliCli                        0x000055c58b4b3960 Mutator.mutate(_:for:) + 257
16   FuzzilliCli                        0x000055c58b313a80 MutationEngine.fuzzOne(_:) + 3084
17   FuzzilliCli                        0x000055c58b3155b1 <unavailable> + 2192817
18   FuzzilliCli                        0x000055c58b426730 Fuzzer.fuzzOne() + 893
19   FuzzilliCli                        0x000055c58b426c7d <unavailable> + 3312765
20   FuzzilliCli                        0x000055c58b341a10 <unavailable> + 2374160
21   libdispatch.so                     0x00007efd81a03947 <unavailable> + 141639
22   libdispatch.so                     0x00007efd81a0f259 <unavailable> + 189017
23   libdispatch.so                     0x00007efd81a0fefe <unavailable> + 192254
24   libdispatch.so                     0x00007efd81a17b72 <unavailable> + 224114
25   libpthread.so.0                    0x00007efd81bd9609 <unavailable> + 38409
26   libc.so.6                          0x00007efd818ff250 clone + 67

I suspect it's an issue with the HybridEngine. There were quite a few issues with e.g. the way it currently instantiates Types, and I wouldn't be surprised if there are some left. I think the HybridEngine should be treated as experimental and have updated to documentation. Also see https://github.com/googleprojectzero/fuzzilli/issues/206.

Although what @WilliamParks described is also plausible, i.e. a program becoming so large that it requires more than 65536 variables. One solution would be to increase Variables to 32 bit integers, at the cost of additional memory consumption. Maybe that's overkill though, since IMO such huge programs shouldn't really be generated during "normal" operations. Maybe the best solution for that is just to fail gracefully, reject the program, and continue with the next fuzz iteration? Thoughts?