I'm trying to simulate my VHDL code using Xilinx ISim.
When I try to generate the testbench for the simulation, the simulator throws up the following error:
FATAL_ERROR:Simulator:Fuse.cpp:500:1.133 - Failed to compile generated C file isim/
I tried to simulate it on an 32-bit Ubuntu 12.04 using ISE 14.3, a 32-bit Windows XP SP3 also ISE 14.3 and a 64-bit Windows 7 SP1 same ISE version as before.
The Xilinx support provided a reinstall as solution, but that didn't solve the problem.
Maybe the community on Stack Overflow has an idea?
That is a tool crash and it's going to be hard to get an answer here on stackoverflow, at least without providing some code and the steps that cause the problem. I would get back with Xilinx support and open a case -- this is something they need to fix in the tool. Can you provide your code as a testcase to them? Potentially cutting it down so it's as simple as possible while still causing the problem.
I can never provide production code to EDA vendors as a testcase due to confidentiality. Quite often I find that while creating a smaller testcase that I can send that I'm able to also find a workaround to the original problem. Try a binary search procedure -- remove or black box half of your design and see if the crash still happens.
And -- can you find the particular C file that fails to compile? Looking at it may give a clue as to what in your design may be causing the problem.
Related
I have tried all the solutions which found on stack overflow, but still not able to resolve it. Somehow its not open the simulator and gives me error "unable to boot simulator".
I have reinstall 2 times xcode and also remove all simulator and add again. also change "DYLD_INSERT_LIBRARIES" to ZZ but no solution.
Please help me, Thanks in Advance!
Try to turn off System Integrity Protection http://www.imore.com/el-capitan-system-integrity-protection-helps-keep-malware-away - it helped me.
Problems:
As I also faced the same problem as below..
--"Unable to boot simulator"
--Storyboard designs/views completely invisible and showing only blue lines.
--CoreTelephony Trace File Error ... failed to create \tmp
Solutions
Don't do any SIP (Disable/Enable)settings its just temp solutions & it may harms to other applications in the mac as well as may affecting on secure data in the mac.
Best way to do upgrade your iMac to macOS "Sierra". It will solve all your problems.
Finally I am able to work on my project by solving above strange problems.
Happy coding.. happy Development...!!!
Assuming the error message was actually "Unable to boot the Simulator.", this error indicates an error starting up launchd_sim when booting the simulated device. In and of itself, it does not indicate the actual cause. You can look in ~/Library/Logs/CoreSimulator/CoreSimulator.log for more information about the error (including the error reason).
Possible causes:
On OSX 10.9 and earlier, DYLD_INSERT_LIBRARIES could be set by 3rd party applications. On later versions, invalid DYLD_INSERT_LIBRARIES are ignored instead of resulting in an error.
Usage of older simulator runtime DLC with Xcode 7 betas. Newer versions of Xcode ignore these older DLC.
If you need additional help, please provide that additional datum.
Also see my answer in the related question: Please see my answer on launchd_sim crashing: could not create temporary state directory regarding data you can collect to help further triage the problem.
Though I have enough memory(RAM -> ~3.5 GB and Hard Disk - > 60 GB)
I am still getting this error again and again while creating chm file using DoxyWizard.
Is there any setting I need to do to fix this?
Even if I do this from the html help compiler from the command prompt using command hhc <index.hhp> inside the html folder I get the same error.
Please remember, HTMLHelp (CHM's) is nearly 20 years old and Microsoft's Windows based help system is in "maintenance mode" only. No new features and support are expected. As far as I know there is no new help systems being developed at Microsoft.
So, the CHM Compiler (written in C++ 1996 by Ralph Walden) has some limits - it's a HH compiler problem not a Doxygen error.
See also: https://superuser.com/questions/330418/file-size-limits-for-chm-html-help-format-files
Please try to compile without 'Index', try to reduce the number of topics, try to compile on a single PC (I think you are working in a server Environment).
I see a small chance for a solution only because there are about 1106 files in your snap above.
I have a simple batch program that works on 2 CentOS 6.6 machines ( a 32 bit machine and a 64 bit machine ), but not on a third CentOS 6.6 machine ( a 64 bit machine ). So how can the exact same executable work on 2 machines, but not work on the third machine?
Note that I am not asking how to fix this issue, I am asking how the same exact executable can behave differently on 3 different machines. I actually have 3 or four different C programs that match this behavior, but I am choosing the simplest one to troubleshoot the issue. My theory is that something is setup differently at the OS level between the 3 machines ( maybe I forgot to install some library or set some environmental variable ). I just need help narrowing down where to look, what OS type things to look at.
This probably should go onto serverfault, as it is more a server related question, but I was afraid people there would see my reference to C programs and ask me to come here, so I am going to start here.
Note that valgrind does not help. I would just fix the issue in my code if that were the case, but it revealed no memory issues. When I say it is simple, I mean it. It just reads some records from the database, massages them, and then prints them to the screen.
Thanks for any help you can provide.
Generally the stack smashing warnings / errors are caused by buffer overflow type issues.
I don't know enough about CentOS / Linux to know the exact way this gets configured (my main experience with this type of issue is when running on OpenBSD). Usually this stack smashing detection feature is enabled at compile time.
GDB may be able to help here if you compile your program with the debugging symbols enabled (-g) and load up the resulting core file to look at the backtrace.
For instance, in a simple test program on OpenBSD I see the following backtrace in GDB:
(gdb) bt
#0 0x00001e13837081ea in kill () at <stdin>:2
#1 0x00001e1383745b2c in __stack_smash_handler (func=0x1e117f400ebf "test_smash", damaged=Variable "damaged" is not available.
) at /usr/src/lib/libc/sys/stack_protector.c:61
#2 0x00001e117f300e91 in test_smash () at test.c:10
#3 0x0000000000000000 in ?? ()
where test_smash() is a function that intentionally overflows the stack.
Using this method should allow you to quickly determine which function is causing the stack overflow, and allow you to fix it in the source code.
Ok, it was sort of an OS related issue, peripherally. Basically, when I was installed my needed shared libraries, I installed the wrong version of my ODBC library ( a newer version then my code is used to and was compiled against ). Once I got the older version installed correctly, the error went away. So for anyone else having this problem with the same executable on one machine but not other machines, check your shared libraries, making sure the versions match. Your executable may not like newer or older versions of a given library, for whatever reason.
I'm writing plugin for the MITK framework using Qt-Creator with gdb on Linux-Mint 15.
Resuming after halting at any breakpoint doesn't work, or seems to take upwards of 30 minutes (every time). My project is not very big however, so there's no way I've got the debugger set up correctly.
I've got the Qt 4.8 and 5.01 packages installed. MITK requires Qt4 and I believe to have it specified everywhere in the makefiles.
I do get the following output when starting to debug:
&"warning: GDB: Failed to set controlling terminal: Unpassender IOCTL (I/O-Control) f\303\274r das Ger\303\244t\n"
no loadable sections found in added symbol-file system-supplied DSO at 0x7ffff7ffa000
From other answers on this site I get that the first line can be ignored...
Can anyone say if the second line is related to my problem and possibly how?
I wonder if this could have to do with there being two versions of Qt installed on my pc - I dont know how to get Qt5 completely off the system with all its packages though...
One user mentioned this: https://stackoverflow.com/a/17256365/2561709
Its all I could really find but I dont understand it, any clues?
I'd appreciate any hint at a possible cause of the problem. Please tell me what other relevant information I could provide, thanks!
I've recently had a horrible problem with QTCreator. After the first time of running the program, ALL debugging instances segfault upon constructing the MainWindow object. Even if i make a blank QTwidget project and run in debug (without editing a single bloody thing), i get a segfault.
This persists after dozens of reinstalls. I have tried both the SDK as well as the IDE and library seperately. The version of the library is irrelevant, i always get the seg fault and its only on my tower. My laptops work just fine.
Does anyone have any possible solutions? Any help will be appreciated.
I needed to run QtCreator in admin mode in order for GDB to function properly.
Without knowing more (please answer to cbamber85's comment), such issues are known to be caused by uberprotectious anti-virus solutions or other software that hooks into places where GDB would usually hook in (Vendor OS-'enhancement' tools are infamous for doing that). This is a known Problem with GDB.
You could try to disable your virus scanner or remove/unload/remove from autostart the vendor tools and try again.
If that doesn't work, the content of the debugger output log pane (Windows > Views > Debugger Log) would be interesting.