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
Comments
Original Redmine Comment 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. |
Original Redmine Comment Wilson Snyder wrote:
Thanks for the quick reply, 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. 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. |
Original Redmine Comment
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' |
Original Redmine Comment Wilson Snyder wrote:
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: 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? |
Original Redmine Comment Perhaps you didn't link with -ggdb? A test case would be appreciated. |
Original Redmine Comment 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. |
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.
The text was updated successfully, but these errors were encountered: