Menu
▾
▴
#241 Race condition check fails due to a memory allocation issue
Trevor,
I get the following error message when I run one of my testbenches:
covered: util.c:1199: malloc_safe1: Assertion `size <= (65536 * 2)' failed.
Seems like it is not able to allocate sufficient memory. I tried running this on a machine that has 4GB SRAM also, but it still showed the same error. Not sure what the issue is.
Is this much data sufficient or would you need some files?
Thanks!!
FYI. I increased the MAX_MALLOC_SIZE to 65536 * 4 and that had no effect.
FYI. I increased the MAX_MALLOC_SIZE to 65536 * 4 and that had no effect.
Doug,
Would it be possible to get the files to recreate this assertion error? The malloc_safe1 routine allocates memory no greater than a given value (MAX_MALLOC_SIZE as you have figured out) in cases where that much memory should not need to be allocated. Most likely you have proven a case to be incorrect, but I will need to know what that is for me to make the correct memory allocation call.
Thanks,
Trevor
Trevor,
I understand that giving you more data on the problem would help, but I am running this on a block of IP and we are legally not allowed to give you that entire suite of RTL. However I am trying to narrow down the issue to a sub-module and then create a simple test suite like I have in the past.
Is there anything else that can help you with this besides the actual test suite?
Understandable. A stack trace of the failure might prove to be helpful. Also, if you could provide the output of running the score command, that would be helpful as well. You can use the -B global option (i.e., covered -B score ...) which will obfuscate filenames and anything else that might output sensitive information.
Output of score command
Attached is a copy of the output generated when running the score command. I am not aware of how to generate the stack trace. Can you guide me through it?
File Added: tmp.txt
Fixes unrelated issue with obfuscation (but is necessary to debug this issue)
I have attached a patch that will fix the obfuscation error that occurred with the first output file. Could you please apply it and regenerate the output file?
As far as creating a stack trace is concerned, do the following (the initial '>' symbol represents the prompt):
At the prompt, type:
When the assertion fires, you will get a prompt. Type:
and provide me all of the information that appears after that command.
Thanks,
Trevor
Trevor,
I was able to narrow down the problem. I am attaching an example test setup where you can recreate the problem.
To run, execute the following command: covered score -t testMod -i testMod -f vlog.f -g 2 -vpi
You will see a segmentation error with this setup. The same segmentation error I believe causes the malloc error above.
The strange thing is in the top level file testMod.v there is a comment on the first like that starts with "$Id". If I remove the "$" sign from this comment, the segmentation fault goes away. This comment is generated as we use CVS for revision control.
Let me know if this works.
File Added: test_setup.tar
Test setup for segmentation fault
Bug fix to correct segmentation fault with $Id$ handling
I have attached another bug fix patch to correct the segmentation fault. The submitted test files now run without error. So I believe that I have fixed the segmentation fault in this case, but the problem with the assertion error still exists (the segfault was not due to memory allocation).
Please apply the new patch and let's see where that gets us.
I have applied this patch to the next release of Covered.
Trevor,
You are correct the seg fault does not cause the memory allocation failure. I followed the steps you gave to create the stack trace and below is the output
0 0x00138cdf in raise () from /lib/tls/libc.so.6
1 0x0013a4e5 in abort () from /lib/tls/libc.so.6
2 0x00132609 in __assert_fail () from /lib/tls/libc.so.6
3 0x080a7ae8 in malloc_safe1 (size=20564488, file=0x80e7d82 "vector.c", line=216, profile_index=0) at util.c:1220
4 0x080a94cc in vector_create (width=164515889, type=1, data_type=0, data=5141122) at vector.c:216
5 0x080b1ed5 in vsignal_create_vec (sig=0x9ce5078) at vsignal.c:174
6 0x0807beca in funit_size_elements (funit=0x9ce1e68, inst=0x9ab55b8, gen_all=FALSE, alloc_exprs=FALSE) at func_unit.c:458
7 0x08095b07 in race_check_modules () at race.c:754
8 0x08093636 in parse_design (top=0x9687068 "top454", output_db=0x9688620 "cov.cdd") at parse.c:172
9 0x080a0052 in command_score (argc=12, last_arg=2, argv=0xbfffc314) at score.c:1119
10 0x0808d9db in main (argc=12, argv=0xbfffc314) at main.c:189
Please let me know if you still need anything else for this bug. Thanks!
Doug,
Could you rerun gdb and after the 'run' command (and assertion error), perform the following commands:
The output from these two 'display' commands will be the name of the module and the name of the file that the signal causing the problem is located in.
This output from the 'display' command will be the name of the wire/reg that is causing the problem.
Could you provide me the Verilog line that instantiates this wire/reg in the given module/file?
Thanks,
Trevor
Trevor,
The verilog file it points to is the equivalent of modA.v from the earlier test_setup directory I attached.
The signal causing the problem in that is "rd_data", instantiated as follows:
output wire [DWIDTH-1:0] rd_data, (please check line 6 of modA.v)
Let me know if you need anything else. Thanks for the quick response!!
What is the value of DWIDTH is when this module is compiled? The reason why I ask is that the width of this signal (according to Covered when the signal vector is being created) is a really, really large number. This width would seem to me to be a bogus number (I highly doubt that you have an output signal that is 164515889 bits in length, correct?
If that is the case, it appears to me that the problem is not with the use of the byte-limiting assertion in the malloc_safe1 function, but rather a bug in Covered somewhere.
If you could confirm that this is the case, we'll need to do some different type of debugging. I think we should start with getting the output from using the -D global option (covered -D score ...).
Doug,
Nevermind the previous e-mail. Using your example code, I was able to reproduce the exact problem on my end. I'll start debugging this ASAP.
Thanks,
Trevor
Patch to fix assertion error
I have attached a third patch which addresses the assertion error. The problem was a bug in Covered's handling of parameters within modules whose instantiations were handled by a generate block. The bug fix will be applied to the next release of Covered.
Test setup for 2nd assertion error
Trevor,
That bug was fixed. But I still the same assertion error in a similar testbench. Attached is the test setup.
Run: covered score -t top -i top -f vlog.f -g 2 -vpi
Thanks!!
File Added: test_setup2.tar
Patch for second issue associated with this bug.
I have attached another bug patch for this second issue. I will apply this patch to the next release of Covered.
Thanks for the work of setting up the example files -- it really helped track this bug down.
Trevor
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).