Opened 14 years ago

Last modified 14 years ago

#1466 closed defect (fixed)

Attached model crashes the compiler during instantiation phase.

Reported by: dhedberg Owned by: dhedberg
Priority: high Milestone:
Component: Instantiation Version: MathCore Branch
Keywords: Cc: dhedberg,

Description

The attached model crashes the compiler if calling instantiateModel(Model). The compiler memory allocation peaks at around 1.4Gb and then crashes with the following error messages:

$ omc Model.mos 
returning NULL (not enough memory) from rml_major_collection!
returning NULL (not enough memory) from rml_minor_collection!
returning NULL (not enough memory) from rml_prim_gcalloc!

FYI: I have a 8Gb machines and had approx. 6Gb free when starting this process.

Attachments (3)

Model.mos (75 bytes ) - added by dhedberg 14 years ago.
ModelTotal.mo (1.6 MB ) - added by dhedberg 14 years ago.
Model-trace-bug-1466.txt (9.2 MB ) - added by Adrian Pop 14 years ago.
Trace of running Model.mos

Change History (14)

by dhedberg, 14 years ago

Attachment: ModelTotal.mo added

comment:1 by dhedberg, 14 years ago

MathCore TRAC ticket: #3127

comment:2 by Martin Sjölund, 14 years ago

How long does it take before this fails?
13870 marsj 20 0 461m 256m 5552 R 100 3.3 32:16.34 omc
Growing at a rate of <2MB/minute

comment:3 by dhedberg, 14 years ago

About 20 seconds. Starts allocating lots of memory after about 15 seconds.

comment:4 by Martin Sjölund, 14 years ago

I'll assume this is on the branch and not the trunk then (I'm now up to 38 minutes)

comment:5 by dhedberg, 14 years ago

Correct, it is on the branch. Is it stuck on the trunk? 38min seems like an awful lot of time to instantiate the model.

comment:6 by Martin Sjölund, 14 years ago

I don't think it's stuck. It is probably just displaying quadratic behaviour when connecting 5294 ThermalConductor to components.

The sad thing is if I wait another 8 hours for the result, since I did not pipe to any output file...
488 MB / 50 minutes now

We could possibly run the bootstrapped compiler through a profiler to see where it's stuck, but that's at roughly 100x overhead, so we would have to kill the test early.

comment:7 by Adrian Pop, 14 years ago

Daniel, note that even if you have 8GB in Windows the MinGW or VS compiled 32bit process
can only allocate ~2GB. If you compile with LARGE_ADDRESS_AWARE, then it can allocate ~3GB.

comment:8 by Martin Sjölund, 14 years ago

  ...
  FixedTemp008.port.T = TC_8_0.port_b.T;
  TC_7_0.port_b.Q_flow + FixedTemp007.port.Q_flow = 0.0;
  FixedTemp007.port.T = TC_7_0.port_b.T;
  TC_6_0.port_b.Q_flow + FixedTemp006.port.Q_flow = 0.0;
  FixedTemp006.port.T = TC_6_0.port_b.T;
  TC_5_0.port_b.Q_flow + FixedTemp005.port.Q_flow = 0.0;
  FixedTemp005.port.T = TC_5_0.port_b.T;
  TC_4_0.port_b.Q_flow + FixedTemp004.port.Q_flow = 0.0;
  FixedTemp004.port.T = TC_4_0.port_b.T;
  TC_3_0.port_b.Q_flow + FixedTemp003.port.Q_flow = 0.0;
  FixedTemp003.port.T = TC_3_0.port_b.T;
  TC_2_0.port_b.Q_flow + FixedTemp002.port.Q_flow = 0.0;
  FixedTemp002.port.T = TC_2_0.port_b.T;
  TC_1_0.port_b.Q_flow + FixedTemp001.port.Q_flow = 0.0;
  FixedTemp001.port.T = TC_1_0.port_b.T;
end Model;
"
""
real	77m30.470s
user	76m24.570s
sys	0m38.990s

So it works perfectly well in the trunk. Seems like a good candidate to do some performance improvements though.

Sadly I didn't run time -v, so I don't know the maximum memory usage, but it was never higher than 800MB (550 + 50% for allocating a new region to compact to?) when I checked. (It could have been slightly higher near the end though)

comment:9 by Adrian Pop, 14 years ago

I think i found the problem in Inst.addConnectionCrefs

was:
  crs_1 = listAppend(crs, {cr1_1,cr2_1});
i changed it to:
  crs_1 = cr1_1::cr2_1::crs;

and now it seems to be working (still running the model thou). Check the SCM commit tab.

comment:10 by Martin Sjölund, 14 years ago

That should take care of quadratic memory consumption. Only thing left is remove duplicate elements take quadratic time to compute?

comment:11 by Adrian Pop, 14 years ago

Seems to work with my changes (see also the trace in the attachments):

adrpo@ida-liu050 ~/dev/OpenModelicaNoChanges/build/bin
$ time ./omc -bench Model.mos > Model-trace-bug-1466.txt 2>&1

[BENCH:	4037.76 seconds total from which 22.82 seconds GC, 13739 minor collections, 67 major collections]

real    67m17.806s
user    0m0.015s
sys     0m0.000s

It used about 400MB (with jumps to 800 when major collecting).

by Adrian Pop, 14 years ago

Attachment: Model-trace-bug-1466.txt added

Trace of running Model.mos

comment:12 by Adrian Pop, 14 years ago

Fixed in revisions:

Revision: 8460
Author: adrpo
Date: 19:43:40, den 1 april 2011
Message:
- fail early on SCode.equationEqual, don't bother to do all then check the boolean list.
----
Modified : /branches/OpenModelica-1.5.1-Maintenance/Compiler/SCode.mo

Revision: 8459
Author: adrpo
Date: 18:24:54, den 1 april 2011
Message:
Fixes for bug: #1466
- replaced inside Inst.addConnectionCrefs the call to listAppend with list cons.
----
Modified : /branches/OpenModelica-1.5.1-Maintenance/Compiler/Inst.mo
Note: See TracTickets for help on using tickets.