09-06-2018 03:48 PM - edited 11-13-2018 08:52 AM
I'm using Xilinx 2018.2 and it just will randomly exit without any error messages. I'm using it on Windows 10, x64. It's a pretty new Windows installation and there's plenty of available memory. I noticed that in workspace/metadata/.log, it has this as the last entry, and I'm assuming that it's the cause. Is there a work around for this? I've tried running it both with admin and non-admin privileges.
!ENTRY org.eclipse.cdt.core 4 0 2018-09-06 15:43:36.294 !MESSAGE Error !STACK 0 java.lang.NullPointerException at org.eclipse.cdt.internal.core.ConsoleOutputSniffer.processLine(ConsoleOutputSniffer.java:178) at org.eclipse.cdt.internal.core.ConsoleOutputSniffer.access$0(ConsoleOutputSniffer.java:174) at org.eclipse.cdt.internal.core.ConsoleOutputSniffer$ConsoleOutputStream.checkLine(ConsoleOutputSniffer.java:99) at org.eclipse.cdt.internal.core.ConsoleOutputSniffer$ConsoleOutputStream.write(ConsoleOutputSniffer.java:58) at java.io.OutputStream.write(OutputStream.java:75) at org.eclipse.cdt.core.CommandLauncher.printCommandLine(CommandLauncher.java:287) at org.eclipse.cdt.core.CommandLauncher.waitAndRead(CommandLauncher.java:250) at org.eclipse.cdt.internal.core.BuildRunnerHelper.build(BuildRunnerHelper.java:273) at org.eclipse.cdt.make.core.MakeBuilder.invokeMake(MakeBuilder.java:219) at org.eclipse.cdt.make.core.MakeBuilder.build(MakeBuilder.java:108) at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:735) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:206) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:246) at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:301) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:304) at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:360) at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:383) at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:144) at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:235) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
Edit: I resolved the issue by installing Xilinx SDK to a Linux distro since the Windows version is unusable.
11-01-2018 03:51 PM
I had the same issue. A quiet 2018.2 SDK crash on start.
I went to the .sdk directory and deleted the .metadata and the .sdk directories. Then I was able to restart the SDK with no crash.
Hope this helps,
11-09-2018 01:53 AM
It doesn't make any difference. The problem is not the start, the problem is the handling with the projects. And by the way, it think SDK has a bigger problem: In my installation it is not only the silent crash, but SDK is not able to import new parts. iE: i remove an IP named "wave2" and add a new IP named wave3. Vivado compiles correct, everything works, but SDK is not able to import the new files. It keeps "wave2" and regenerating of BSP doesn't help.....So we hopefully wait for a new version....
11-25-2018 03:13 PM - edited 11-28-2018 05:12 AM
I'm a new user trying to get started with a simple Arty S7 board from digilent by following their guide on working with microblaze, and I'm also suffering from the SDK crashing on launch.
Trying to launch it from the command line gives no problems but when trying to "Launch SDK" from vivado it only worked the first time:
I was able to make it to step 7.4 in this guide https://reference.digilentinc.com/vivado/getting-started-with-ipi/start which is creating a new hello world C application, but clicking finish crashed the SDK and it no longer starts when invoked from vivado, even if I delete my .xilinx folder.
I'm going to contact digilent support about this as their product is little use to people trying to learn if the tools are flaking out.
Edit: After working more on this simple example, XSDK refuses to start even from the start menu. If I delete the .Xilinx folder after every run I can get it to start from the command line. This is frighteningly unstable software.
11-29-2018 12:22 AM
Further poking around leads me to believe that at least a part of the problem is related to improper handling of file and folder permissions by XSDK.
I tried two more approaches to following the digilent guide but varied where I put the folder that XSDK creates on its first launch for storing intermediate work. I first tried putting it under the same folder as where I was keeping my XSDK projects (no spaces or special symbols in path but it would crash on just about every action). After deleting .Xilinx, the created folders and starting again with the folder in the default selected location the number of crashes was reduced substantially though not eliminated.
From this observation I conclude that file and folder permissions aren't being handled properly as otherwise the location of the folder wouldn't have an impact. I have to imagine that some of the remaining crashes are due to file permission issues when the project folder is under the user folder in windows 10.
07-26-2019 11:27 AM
Even i had the exact same issue of SDK getting closed as soon as i select a workspace. But got this resolved by deletin the .Xilinx folder.
But have another issue where in it do not load any files and shows a error with red cross icon. If i restart the SDK, it will work fine.
10-27-2020 06:24 AM
I had a problem that XSDK was crashing at startup. Deleting the *.snap file in <SDK-Workspace>\.metadata\.plugins\org.eclipse.core.resources fixed this for me.
04-02-2021 11:30 PM
I encountered a similar problem when the Xilinx SDK in Vivado 2018.2 is closed forcefully in windows 10(shutting down the computer without closing the SDK). After this happened, whenever I opened the project, I cannot open any file from the project. A list of Java errors is shown in the windows. I resolved this by deleting the <project>.sdk folder from the Vivado project. Then go to Vivado and export hardware again and launch sdk. This resolved those Java errors and the unresponsiveness of SDK.