Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
8 years ago

out of memory in 17.0 compiler

Dear All,

I have a Nallatech 385A board and both SDKs 16.0 and 17.0. I was always successful to compile my kernels with SDK 16.0, but when I move to 17.0 I get out of memory error:

*** Fatal Error: Segment Violation at (nil)
Module: quartus_syn
Stack Trace:
    0x61383: google::protobuf::FileDescriptorTables::~FileDescriptorTables() + 0x43 (protobuf)
    0x3c5ea: __cxa_finalize + 0x9a (c)
End-trace
Error (114016): Out of memory in module quartus_syn (2069 megabytes used)
Error: Failed to synthesize partition
Info: Saving post-synthesis snapshots for 1 partition(s)
*** Fatal Error: Segment Violation at (nil)
Module: quartus_syn
Stack Trace:
    0x61383: google::protobuf::FileDescriptorTables::~FileDescriptorTables() + 0x43 (protobuf)
    0x3c5ea: __cxa_finalize + 0x9a (c)
End-trace

I have 64GB of memory and I'm compiling Bloom Filter design. Does SDK 17.0 requires more memory than SDK 16.0?

Thanks,

Saman

18 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    This looks very strange, to be honest; the process is just crashing and it is clearly saying it was because of lack of memory. Maybe try installing the 17.0.2 update?

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    I really have no other ideas. Unless some other process is running on your machine and using all of your RAM, leaving no room for the compilation process, I cannot think of any other reasons why this could be happening.

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    This one is failing because Nallatech's 17.1 BSP is not compatible with Quartus v17.1.2 and is made for v17.1.0. They have a note on their support lounge that you need to manually add a line to the BSP so that it becomes compatible with v17.1.1 and v17.1.2; however, in my experience, adding the note didn't also work either. You can try with Quartus v17.1.0 first. If it worked, then you can add the extra line and try with 17.1.2 and see if it works for you.

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    This is interesting. Here I have tried several things and here are the issues:

    1) when I try fast-compile option it works all fine and finishes properly (version 17.1.2)

    2) When I try v17.1.2 with default compile mode it fails with the same error above.

    3) Switching to version 17.1.0 gives me out of memory error.

    I'm really frustrated and confused. Is this whole set of Intel OpenCL toolkit that unstable? Without giving proper error messages?

    We basically have one machine with FPGAs, and a cluster of machines with Ubuntu on it. I'm using the cluster to compiler kernels in parallel. Without that, I cannot really proceed fast enough. The current issues with v17 and above completely blocked my progress. What do you could be solution for all these?
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Too be honest, you probably are encountering a very rare problem. I have been using the toolchain for three years now on both Stratix V and Arria 10, starting from v15.0, and despite the numerous problems I have had, I have not had this particular issue. I have encountered "out of memory" crashes, but that is because I run multiple compilations in parallel and I am using a cluster that is shared between everyone in my lab and sometimes the memory fills due to multiple people using the machine at the same time. Your cases seems to be running out of memory without the memory actually being full, which does not seem right. I have one final suggestion: try increasing your swap size and see what happens. You can also try to find an automated way to periodically log the memory usage of the machine (or do it manually using top/htop) and see how the memory usage changes during compilation and if it fails again, figure out what situation it fails in.

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Try using the 64bit switch in the quartus command:

    Launch the Quartus II software with the --64bit command line option:

    quartus --64bit

    From the logs, it still looks like quartus is invoked in the 32-bit mode