Forum Discussion
Quartus II keeps crashing on Ubuntu 14.10
Quartus II will start on Ubuntu 14.10. And I've successfully programmed .sof file to Cyclone V. But, if idle for a few minutes, it crashes with the following report:
problem details Error: *** Fatal Error: Segment Violation at 0xffffffff00000000 Module: quartus Stack Trace: 0x214ed: addbyter + 0xd (curl.so.4) 0x22403: dprintf_formatf + 0xd33 (curl.so.4) 0x22a45: curl_mvsnprintf + 0x25 (curl.so.4) 0x216c2: curl_msnprintf + 0x82 (curl.so.4) 0x12646: Curl_failf + 0x126 (curl.so.4) 0x910f: Curl_resolv_timeout + 0x12f (curl.so.4) End-trace Executable: quartus Comment: None system information Platform: linux64 OS name: Ubuntu 14.10 OS version: 14 quartus ii information Address bits: 64 Version: 14.1.0 Build: 186 Edition: Web Edition Anyone having similar problems? Any solutions?22 Replies
- Altera_Forum
Honored Contributor
This past weekend I migrated a 14.0 project into 14.1 -- I'm running ubuntu 14.04 (has been very stable with 14.0 tools for me for many months).
I had a few crashes at first -- couldn't complete a compile. I've seen this before, no idea why, but the same sort of crashes initially working with an upgrade (I don't have any specifics stored). It seemed to blow chunks at different stages then for some reason the project will start compiling again (I even archived the project and brought it into 14.1 cleanly, I thought). In any case, I successfully compiled on Centos then moved back to Ubuntu with the project and it seemed to be behaving. Everything seemed to be working fine, but TimeQuest was crashing for me still (both on Centos and Ubuntu after testing). I'm working with the plain cyclone V on the arrow bemicroCV board and the DDR3 pin assignment tcl script doesn't execute successfully on 14.1 for me. This is the second time I tried to get up and running with 14.1 and I've gone back to 14.0.2 or whatever the last was. The two issues I had in the end (TimeQuest crashing and the DDR3 pin assignment script failures) happend on Centos6.5/6.6, I decided to bail. If it were a Ubuntu problem I would have maybe stuck it out a little longer and tried to narrow it down. I'm using the full version, FWIW. Good luck, Lance - Altera_Forum
Honored Contributor
I'm seeing the same crash on both Ubuntu 12.04.5 and CentOS 7. I tried contacting Altera support, but they only referred me to the supported OS list, which lists RHEL5 and RHEL6 as the only supported Linux distributions. In fairness, I tried installing Quartus 14.1 on CentOS 6.6, and it didn't crash.
- Altera_Forum
Honored Contributor
Per Lance's suggestion, I ran Quartus 14.0 all day yesterday on Ubuntu 14.10 -- NO CRASHES. So it does seem the Altera move to Quartus 14.1 is indeed causing the problem on Ubuntu. Thanks for the help Lance.
I'm planning to run and monitor stability of 14.0 base for awhile longer, and then eventually try to install Update 2 to 14.0 andersm, have you sent the crash report to Altera? I did. It would be nice to get this fixed. -- Jeff - Altera_Forum
Honored Contributor
--- Quote Start --- andersm, have you sent the crash report to Altera? I did. It would be nice to get this fixed. --- Quote End --- I did, and received this reply: --- Quote Start --- We don’t actually support Ubuntu. http://www.altera.com/download/os-support/oss-index.html I’ll contact the factory and see if they can suggest anything but I don’t think we have any Unbuntu machines for us to try to replicate this problem. --- Quote End --- - Altera_Forum
Honored Contributor
Please update the thread if you figure out what is going on.
There have been some external tutorials I've found for hacking things to get modelsim to run properly under ubuntu, getting the USB blaster to work, etc, but usually the basic software and other core stuff would run. The clock domain stuff in Qsys would be nice to be able to use...along with any other updates behind the scenes to IP and such. The other real plus of 14.1 is that it seemed like the built in help links worked on ubuntu for the first time (pulling up a browser and not failing). That stuff worked fine under CentOS/Redhat -- but I can't make myself run Centos as a main OS on my laptops due to hardware support; just too painful. I keep VM's up to date on all the ubuntu boxes with Centos 6.6 if I really need to run stuff there. Lance - Altera_Forum
Honored Contributor
I received an update from Altera support:
--- Quote Start --- The Curl library shipped with Quartus II is not thread-safe and this causes the error you have seen. You can work around this problem by creating an environment variable to set CURLOPT_NOSIGNAL to 1 with the following command: For csh-style shells: setenv CURLOPT_NOSIGNAL 1 For sh-style shells export CURLOPT_NOSIGNAL=1 If you could let me know if this resolves your problem then I can confirm this solution with the factory. --- Quote End --- The suggested workaround did not work for me. - Altera_Forum
Honored Contributor
--- Quote Start --- I received an update from Altera support: The suggested workaround did not work for me. --- Quote End --- In the altera/14.1/quartus/linux64 folder, rename libcurl.so.4 to libcurl.so.4.bak. Then, restart Quartus. This will cause the runtime library loader to fall back to the system's own libcurl, which is hopefully compatible. This worked on RHEL 7, no crashes for a couple of hours when it used to crash after every compilation. - Altera_Forum
Honored Contributor
--- Quote Start --- In the altera/14.1/quartus/linux64 folder, rename libcurl.so.4 to libcurl.so.4.bak. Then, restart Quartus. This will cause the runtime library loader to fall back to the system's own libcurl, which is hopefully compatible. This worked on RHEL 7, no crashes for a couple of hours when it used to crash after every compilation. --- Quote End --- Thanks! That seems to have worked for me. Been running over an hour now and no crashes. That is much longer than the minute or two I would get before. I should also note that I haven't just done the fix Pinhedd described. All three of these things I have done to make it work, but not necessarily needing numbers 1 and 2. I could try reverting the change made in number 1, and rebooting to revert number 2. It would be real nice if Altera would add proper support for Debian based linux distros, such as Ubuntu. Ubuntu is so much more useful and easier to use than RHEL based. I don't want to spend time tinkering to get things working - I want to get down to work.- Make certain 127.0.0.1 is set to resolve to localhost.localdomain localhost:
mikeon84@mikes-laptop:~$ cat /etc/hosts | head -1 127.0.0.1 localhost.localdomain localhost - Set env variable
export CURLOPT_NOSIGNAL=1 - Most likely the real fix, noted by Pinhedd. There are many libraries in that folder, which many are already included in the OS - so are probably not necessary?
mikeon84@mikes-laptop:~/$ sudo mv /altera/14.1/quartus/linux64/libcurl.so.4 /altera/14.1/quartus/linux64/libcurl.so.4.bak password for mikeon84: mikeon84@mikes-laptop:~/$
- Make certain 127.0.0.1 is set to resolve to localhost.localdomain localhost:
- Altera_Forum
Honored Contributor
--- Quote Start --- Thanks! That seems to have worked for me. Been running over an hour now and no crashes. That is much longer than the minute or two I would get before. I should also note that I haven't just done the fix Pinhedd described. All three of these things I have done to make it work, but not necessarily needing numbers 1 and 2. I could try reverting the change made in number 1, and rebooting to revert number 2. It would be real nice if Altera would add proper support for Debian based linux distros, such as Ubuntu. Ubuntu is so much more useful and easier to use than RHEL based. I don't want to spend time tinkering to get things working - I want to get down to work.- Make certain 127.0.0.1 is set to resolve to localhost.localdomain localhost:
mikeon84@mikes-laptop:~$ cat /etc/hosts | head -1 127.0.0.1 localhost.localdomain localhost - Set env variable
export CURLOPT_NOSIGNAL=1 - Most likely the real fix, noted by Pinhedd. There are many libraries in that folder, which many are already included in the OS - so are probably not necessary?
mikeon84@mikes-laptop:~/$ sudo mv /altera/14.1/quartus/linux64/libcurl.so.4 /altera/14.1/quartus/linux64/libcurl.so.4.bak password for mikeon84: mikeon84@mikes-laptop:~/$
- Make certain 127.0.0.1 is set to resolve to localhost.localdomain localhost:
- Altera_Forum
Honored Contributor
yes, this set of solutions seems to be working for me as well.
I think I am interpreting the results a little differently than before (I misinterpreted some warning messages that were labelled as errors as being more severe, and I had some other things project related that were not due to 14.1 that were fixed since the last time I tried it). I only did a couple compiles today but saw no crashes. Lance