Skip to content
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

Fuzzer: Segfault on parameter as generate condition #1590

Closed
veripoolbot opened this issue Nov 4, 2019 · 5 comments
Closed

Fuzzer: Segfault on parameter as generate condition #1590

veripoolbot opened this issue Nov 4, 2019 · 5 comments
Assignees

Comments

@veripoolbot
Copy link
Contributor

@veripoolbot veripoolbot commented Nov 4, 2019


Author Name: Eric Rippey
Original Redmine Issue: 1590 from https://www.veripool.org

Original Assignee: Wilson Snyder (@wsnyder)


Running the attached testcase with:

verilator_bin --lint-only 8.sv

On version:

Verilator 4.020 devel rev v4.020-56-gbcb766b

Produces:

%Error: 8.sv:1: Parameter without initial value is never given value (IEEE 1800-2017 6.20.1): 'P'
               : ... In instance m
module m#(parameter P);
                     ^
%Warning-WIDTH: 8.sv:4: Logical Operator GENFOR expects 1 bit on the For Test Condition, but For Test Condition's VARREF 'P' generates 32 bits.
                       : ... In instance m
     for(j=0;P;j++)
     ^~~
                 ... Use "/* verilator lint_off WIDTH */" and lint_on around source to disable this message.
%Error: 8.sv:4: Non-genvar used in generate for: 'j'
               : ... In instance m
     for(j=0;P;j++)
     ^~~
Segmentation fault (core dumped)

@veripoolbot
Copy link
Contributor Author

@veripoolbot veripoolbot commented Nov 4, 2019


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2019-11-04T20:04:51Z


I'll look at this and the others starting tonight.

In the interest of best use of time, I'd recommend we only look for crashes where there's a crash and no earlier error message. (Versus also ones with errors and crashes before.)

@veripoolbot
Copy link
Contributor Author

@veripoolbot veripoolbot commented Nov 5, 2019


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2019-11-05T00:33:38Z


Fixed in git towards 4.022.

@veripoolbot veripoolbot closed this Nov 5, 2019
@veripoolbot
Copy link
Contributor Author

@veripoolbot veripoolbot commented Nov 6, 2019


Original Redmine Comment
Author Name: Eric Rippey
Original Date: 2019-11-06T23:10:49Z


Regarding only crashes with no output, that's easier said than done. I don't know of any fuzzer capable of doing that out of the box. And fuzzers tend to find many different ways to get to the same problem when a problem stays in the program.

If you still wanted to automatically find bugs effectively under that sort of constraint, you might have to go about this in completely the opposite direction where you start out with known-valid input the way that something like Csmith (https://embed.cs.utah.edu/csmith/) works. That's kind of a major project though because I don't know of an equivalent for Verilog.

@veripoolbot
Copy link
Contributor Author

@veripoolbot veripoolbot commented Nov 7, 2019


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2019-11-07T00:18:35Z


Perhaps I'm missing some detail, but can't you just tweak actual_fail to not be interesting if there was %Error printed?

@veripoolbot
Copy link
Contributor Author

@veripoolbot veripoolbot commented Dec 9, 2019


Original Redmine Comment
Author Name: Eric Rippey
Original Date: 2019-12-09T18:55:30Z


Yes, that change can be made. Unfortunately though, this makes it unlikely to find anything. The fuzzer itself tends to find things that print lots of errors, and then in the process of reducing the testcase the number tends to go down, sometimes to 0, sometimes not. The test reduction is partially automatic but also partially manual, which makes this expensive in terms of person time since for any given failure you don't know if it's going to get to 0 errors when starting.

It also seems like it would be nice to know that the program won't segfault regardless of input, but I suppose that could be said of the other sorts of internal faults too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.