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)
Change History (14)
by , 14 years ago
Attachment: | ModelTotal.mo added |
---|
comment:1 by , 14 years ago
comment:2 by , 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 , 14 years ago
About 20 seconds. Starts allocating lots of memory after about 15 seconds.
comment:4 by , 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 , 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 , 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 , 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 , 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 , 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 , 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 , 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).
comment:12 by , 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
MathCore TRAC ticket: #3127