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

Segmentation Fault when tracing is enabled #1377

Closed
veripoolbot opened this issue Dec 15, 2018 · 6 comments
Closed

Segmentation Fault when tracing is enabled #1377

veripoolbot opened this issue Dec 15, 2018 · 6 comments
Assignees
Labels
area: wrong runtime result Issue involves an incorrect runtine result from Verilated model resolution: abandoned Closed; not enough information or otherwise never finished

Comments

@veripoolbot
Copy link
Contributor


Author Name: Aaron Kelly
Original Redmine Issue: 1377 from https://www.veripool.org

Original Assignee: Wilson Snyder (@wsnyder)


Hi all,

First off let me thank you for this amazing software - I have compiled a 250k gate design with some of the more exotic system verilog constructs without any issue.

I have however ran into an issue when compiling a static library with tracing turned on that is used within another program. On smaller designs this is fine however on this larger design it seems to not like one of the files. Is there a way of bisect debuggging this by changing verilators scope when tracing? I have applied a /verilator tracing_off/ at the top level module and for packages but it seems like just having the switch turned on causes a memeory error.

I looked into __trace__slow.cpp and see all the signals are commented out.

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2018-12-15T00:43:04Z


Thanks.

There's numerous trace control methods, probably --trace-depth is the first to try, see others in the manual.

If you're getting a core dump, I'd however instead suggest compiling with debug and running under gdb, then doing a backtrace. Usually it gets very close to the problem.

Good luck, please post back what the problem is, even if something outside Verilator.

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Aaron Kelly
Original Date: 2018-12-15T02:36:28Z


Wilson Snyder wrote:

Thanks.

There's numerous trace control methods, probably --trace-depth is the first to try, see others in the manual.

If you're getting a core dump, I'd however instead suggest compiling with debug and running under gdb, then doing a backtrace. Usually it gets very close to the problem.

Good luck, please post back what the problem is, even if something outside Verilator.

Thanks for the quick reply,
I've tried setting --trace-depth to 1 and 0. The files compiles and simulates fine in my test bench without the --trace switch but --trace/--trace-depth 0 cause a segmentation error. I have also tried it on other projects and it dumps the waves it just seems to be this bigger project with interface files.

I tried activating the --debug switch, do I need the --gdb switch too?

I'm not an expert in GDB but I got back a very obscure message back

Program received signal SIGSEGV, Segmentation fault.
0x0000000000026816 in ?? ()

I just saw the configuration files section mentioning

tracing_on [-file "" [-lines [ - ]]]

tracing_off [-file "" [-lines [ - ]]]

I might try that and see which file is crashing when it gets traced.

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2018-12-15T13:15:30Z


Program received signal SIGSEGV, Segmentation fault. 0x0000000000026816 in ?? ()

You need to compile with debug on. Depends on your compiler, but with GDB it's something like --ggdb. Add that to your makefile, or

verilator ... -CFLAGS '-DVL_DEBUG -ggdb'

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Aaron Kelly
Original Date: 2018-12-15T23:22:31Z


Wilson Snyder wrote:

Program received signal SIGSEGV, Segmentation fault. 0x0000000000026816 in ?? ()

You need to compile with debug on. Depends on your compiler, but with GDB it's something like --ggdb. Add that to your makefile, or

verilator ... -CFLAGS '-DVL_DEBUG -ggdb'

The symbols seems to get stripped out somewhere along my flow I tried adding -ggdb to each step but couldn't get it working.

I have however got it working to trace the file now but it required me to go into the generated ventilator code and change some stuff. It seems with this project it has dumped extra files

V_.cpp/h

V_.cpp/h

and within them they seem to reference

public:
static void traceInit(VerilatedVcd* vcdp, void* userthis, uint32_t code);
static void traceFull(VerilatedVcd* vcdp, void* userthis, uint32_t code);
static void traceChg(VerilatedVcd* vcdp, void* userthis, uint32_t code);

When I remove this from unit.cpp and V<interface1/2>.cpp it traces correctly, is a pointer maybe getting overwritten?

The difference in this project is that I have used -top-module.

Would it be worth sending a testcase?

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2018-12-16T00:26:38Z


Perhaps you didn't link with -ggdb?

A test case would be appreciated.

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2019-03-10T18:21:52Z


Sounds like you got this working a while ago.

Closing due to not getting a test case or patch, if you have one please feel free to post it and we'll look at it, thanks.

@veripoolbot veripoolbot added area: wrong runtime result Issue involves an incorrect runtine result from Verilated model resolution: abandoned Closed; not enough information or otherwise never finished labels Dec 22, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: wrong runtime result Issue involves an incorrect runtine result from Verilated model resolution: abandoned Closed; not enough information or otherwise never finished
Projects
None yet
Development

No branches or pull requests

2 participants