06-28-2017 10:55 AM
I recently upgraded to Vivado 2017.2. It worked great for a few days.
Now, upon opening my project, the 'srcscanner' executable runs away and uses all of my system memory (and then some). See this excerpt from 'top':
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ TIME COMMAND 16895 elindbe+ 20 0 37.574g 0.022t 38080 R 105.5 93.7 0:21.38 0:21 srcscanner 12643 elindbe+ 20 0 10.132g 292844 24060 S 7.0 1.2 101:30.43 101:30 vivado
My system has 24GB of RAM. Normally that is enough to handle many Vivado instances.
Vivado doesn't crash; the system just grinds to a halt due to all the pagefile swapping. So I'm not able to provide a log or anything.
1. Is there additional data I can gather, or logging features I can enable, to debug this further?
2. Any tips on a workaround? The reason I switched to 2017.2 was that 2016.3 was sometimes crashing while updating the project hierarchy. This seemed to be resolved for the first few days I was using 2017.2, but perhaps this is the same underlying issue coming up again (though manifesting in a different way).
Disclaimer: I'm using an "unsupported" Linux host, Debian 8.
06-28-2017 11:07 AM
06-28-2017 11:11 AM
It is always recommended to use supported OS with the particular Vivado version you use. With unsupported OS you generally see such undeterministic results. Please refer the below link,page 8 for list of supported OS for 2017.2:
Check these below links which talks about the memory recommendations for various devices:
I strongly have the feeling that the issue is due to unsupported OS as rightly said by you 24 GB is enough to run Vivado instances.
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.
Give Kudos to a post which you think is helpful and reply oriented.
06-28-2017 11:52 AM
Reproduces on CentOS 6.9 as well, although this system only has 8GB of ram:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ TIME COMMAND 2949 elindber 20 0 9875m 3.6g 1448 D 1.0 46.4 0:05.98 0:05 srcscanner 2948 elindber 20 0 9875m 3.6g 1448 D 1.0 46.3 0:06.00 0:06 srcscanner
I cannot easily downgrade to 6.7 or 6.8, as they are not longer supported by CentOS.
06-28-2017 12:42 PM
Can you try with Centos 7.2 or 7.3 and see if you reproduce the same issue? Please make sure the about memory requirements with the link I provided.
06-28-2017 12:44 PM
@elindberg I had a big problem with this scrscanner as well - but on Windows. Looks like some bad code in there that Xilinx needs to fix.
In my case, it failed when creating the HDL wrapper. Srcscanner would fail and the files would be rejected from the build.
Same as you, it worked for a couple weeks and then failed.
I spent almost a couple of months trying to migrate from 2016.4 to 2017.1 without success. Then I went the radical way and reinstalled a ton of software and removed Oracle Java and everything from my PATH. It finally made the problem go away.
06-28-2017 01:46 PM
I am not able to easily test a CentOS upgrade.
But I did manage to narrow this down to a minimal test case, which I've attached. The issue seems to be dependent on there being a specific syntax error in the file (a missing "end if", you can see is commented out).
To reproduce (2017.2, Linux)
* create a new project targeting the xc7k70tfbv676-1
* add the test.vhd file
* watch srcscanner take all your system's memory
09-06-2017 03:47 AM
Thank you @elindberg for narrowing this down.
I have a different problem, probably the same cause while running vivado 2017.2.
no memory issue, but the scrscanner runs continuously at 100% of one processor.
It continues to run for several minutes after Vivado is closed.
I am editing a large, but unfinished vhdl file in the built in editor, and I guess it is getting hung up on a missing end.
09-14-2017 09:33 PM
I have same error with @skeptonomicon.
I just opened the microblaze example project of xilinx after install the vivado 2017.2.
It couldn't found the top file and couldn't made the wrapper also.
It was always comming that there was no operation of "srcscaner" processor from windows 7.1 task manager.
Finally I erase this vivado 2017.2 version. I didn't saw this problem at vivado 2017.1.
I think this vivado 2017.2 version has some problem.
09-18-2017 01:47 AM
I have observed the same issue in 2017.1. The "srcscanner" process consumes ~3.5GB from 4GB assigned to a virtual machine. When it happens it's usually faster to kill entire VM than trying to type "pkill vivado".
I am using Ubuntu 16.04 LTS, although its a customized version (Ubuntu Mini installation + xinit + LXDE/LXDM).
It looks like the issue is triggered by some specific VHDL constructs (syntactically incorrect). In my case it was:
if some_std_logic_type_signal then -- I missed "= '1'"
I was unable to narrow it down to simple VHD example like@elindberg did, but I can confirm that his test.vhd also runs system out of memory.
09-26-2017 03:20 AM
I've got this same problem on Vivado 2017.1, Windows 10 Pro and 16 GB RAM. It happened when I missed semicolon in line with assignment of state of one of state machines. I also confirm the test with "test.vhd" works.
Have anyone found a solution? So far I guess best way is to set 'Hierarchy update' on 'no update, manual compile order'.
10-09-2017 09:27 AM
same issue here.
srcscanner mem usage goes to 100% of available system memory, practically making everything very slow.
10-09-2017 11:32 AM
To overcome of Vivado GUI crash without any log files produced and halting ( hang) of vivado you may try below mentioned workaround.
- Delete the .Xilinx directory in your User Home and reboot the machine.
10-24-2017 10:19 AM
I have also hit this problem of 20+G srcscanner blowups with code like (work-around follows):
... case some_signal is => when x"00" => <do something>; when x"01" => <do something else>; ... whex x"10" => <do another thing>; -- see how easy a syntax error like this might be????
... when x"FF" => <last thing to do>;
when others => null;
end case; ...
Very deterministic: When I fix the syntax error the problem disappears and if I put the syntax error back in srcscanner once again consumes all available memory. Srcscanner's behavior suggests that it contains a recursive-descent parser that missed some cases (that include mine and the previous poster's test case) where invalid syntax fails to bail out and instead proceeds into infinite recursion.
So now I keep a console open with "killall -9 srcscanner" on hotkey to kill srcscanner whenever it starts bugging out like this which Murphy's Law says will be quite often particularly since the probability of syntax errors occurring is high as code is typed in to begin with.
However with srcscanner killed the syntax highlighting also won't reflect the current code (I.E.: the display of errors in the code will be inaccurate as it will be from the last time srcscanner ran correctly). To find errors in code one must now run a simulate (or elaborate) pass to trigger the VHDL compiler which will then display errors from the code in the TCL output pane. Fix any errors reported (so srcscanner will be sane) then save (which triggers srcscanner to restart).
10-24-2017 10:30 AM
*** Saving (CTRL+S) causes srcscanner to spawn so as long as the syntax error causing srcscanner to bug out remains in the source file do not save.
10-27-2017 09:01 AM
Right click on Source/Hierarchy view and select "Hierarchy Update"->"No Update, Manual Compile Order" to turn off srcscanner
or execute this Tcl command to same thing
set_property source_mgmt_mode None [current_project]
12-30-2018 04:35 AM
Disappointing to see this problem is still present in Vivado 2018.2.2.
I saw 2 srcscanner processes, each chewing up 7.2GB of RAM.
In my case the problem was I had incorrectly ended a for loop with "end for;" instead of the correct "end loop;".
10-22-2019 08:14 AM
It's even more disappointing to see that the problem is not fixed in 2019.1. I have a fairly large design. It uses about half of a XCZU9EG. Before reopening the project after the last time I built, I closed all of the design files. All I did was scroll down in the project overview window and scrscanner started four processes completely using four cores and about 3.8GB each. It's been chugging away for about an hour now. The project still says write_bitstream complete, so I know I didn't change anything. I have to admit, 2019.1 is better than 2017.2. That one usually opened six copies of srcscanner.