New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[qubes-os] "Merging new testcases failed:" #681

Closed
paraschetal opened this Issue Jun 18, 2017 · 6 comments

Comments

Projects
None yet
4 participants
@paraschetal
Contributor

paraschetal commented Jun 18, 2017

I am unable to access the performance report and coverage statistics for the libqubes-rpc-filecopy fuzz target. Based on the logs, I think it might be because the fuzz targets are not being executed.

Command: /mnt/scratch0/clusterfuzz/slave-bot/builds/clusterfuzz-builds_qubes-os_dba2089d23e7b835b08c68a02d4a2dca7a3c102b/revisions/libqubes-rpc-filecopy -max_len=10240 -timeout=25 -rss_limit_mb=2048 -artifact_prefix=/ -max_total_time=2950 -print_final_stats=1 /new /qubes-os_libqubes-rpc-filecopy
Bot: oss-fuzz-linux-zone1-pre-qubes-os-6vdq
Time ran: 0.117007

INFO: Seed: 525719240
INFO: Loaded 1 modules (126 guards): [0x883530, 0x883728),
Loading corpus dir: /new
Loading corpus dir: /qubes-os_libqubes-rpc-filecopy
INFO: A corpus is not provided, starting from an empty corpus
#0	READ units: 1
EOF
Merging new testcases failed:

I have tested running the fuzz targets locally using the infra/helper.py script, and that does works fine.

user@work ~/p/oss-fuzz> python infra/helper.py run_fuzzer qubes-os libqubes-rpc-filecopy                                                              qubes-linux-utils
Running: docker run --rm -i --cap-add SYS_PTRACE -e FUZZING_ENGINE=libfuzzer -v /home/user/projects/oss-fuzz/build/out/qubes-os:/out -t gcr.io/oss-fuzz-base/base-runner run_fuzzer libqubes-rpc-filecopy
/out/libqubes-rpc-filecopy -rss_limit_mb=2048 -timeout=25 -max_len=10240
INFO: Seed: 662960318
INFO: Loaded 1 modules (126 guards): [0x8865f0, 0x8867e8), 
INFO: A corpus is not provided, starting from an empty corpus
#0	READ units: 1
#1	INITED cov: 29 ft: 27 corp: 1/1b exec/s: 0 rss: 30Mb
#10	NEW    cov: 29 ft: 28 corp: 2/126b exec/s: 0 rss: 30Mb L: 125 MS: 4 CMP-CMP-CopyPart-InsertRepeatedBytes- DE: "\x00\x00\x00\x00\x00\x00\x00 "-"handle_ill"-
#51	NEW    cov: 30 ft: 33 corp: 3/10366b exec/s: 51 rss: 31Mb L: 10240 MS: 5 CopyPart-CMP-CMP-ShuffleBytes-CrossOver- DE: "\x00\x00\x00\x00\x00\x00\x00\x07"-"rss_l"-
...
@oliverchang

This comment has been minimized.

Member

oliverchang commented Jun 19, 2017

Will take a closer look today. In the meantime, please take a look https://github.com/google/oss-fuzz/blob/master/docs/fuzzer_environment.md in case there's something obvious here.

@oliverchang

This comment has been minimized.

Member

oliverchang commented Jun 23, 2017

Sorry for the delay, but I finally got around to taking a look at this.

If I do:

./libqubes-rpc-filecopy < /dev/null

Then the fuzz target exits instantly. This is similar to how we run the target on our infrastructure.

Is target expecting input on stdin?

oliverchang added a commit that referenced this issue Jun 23, 2017

base-runner run_fuzzer: pipe /dev/null to stdin
Targets could be incorrectly reading from stdin (e.g. #681).
@paraschetal

This comment has been minimized.

Contributor

paraschetal commented Jun 26, 2017

Hmm, weird...It shouldn't be expecting any input. I'll check what's wrong.

@paraschetal

This comment has been minimized.

Contributor

paraschetal commented Jun 27, 2017

It should be fixed now. Still, let's just wait till the changes are reflected in the clusterfuzz logs.

@inferno-chromium

This comment has been minimized.

Collaborator

inferno-chromium commented Jun 28, 2017

@Dor1s - can you confirm if things look ok and then close this tmrw.

@Dor1s

This comment has been minimized.

Collaborator

Dor1s commented Jun 28, 2017

Confirmed, the most recent version works fine.

@Dor1s Dor1s closed this Jun 28, 2017

robertswiecki added a commit to robertswiecki/oss-fuzz that referenced this issue Dec 18, 2017

base-runner run_fuzzer: pipe /dev/null to stdin
Targets could be incorrectly reading from stdin (e.g. google#681).

tmatth added a commit to tmatth/oss-fuzz that referenced this issue Oct 22, 2018

base-runner run_fuzzer: pipe /dev/null to stdin
Targets could be incorrectly reading from stdin (e.g. google#681).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment