View Issue Details

IDProjectCategoryView StatusLast Update
0000406ascendgeneralpublic2013-02-26 13:39
Assigned Tojohn 
PrioritynormalSeveritycrashReproducibilityhave not tried
Status confirmedResolutionopen 
Product Version0.9.6 
Target Version0.9.9Fixed in Version 
Summary0000406: crash while instantiating conditional model
DescriptionWhile instantiating heatex2 from the attached model file, I get a crash:;

PROGRAM FATAL ERROR: ascend/compiler/instantiate.c:9890:Pass2ExecuteForStatements: Assertion failed: return_value
TagsNo tags attached.



2009-06-22 13:22


heatex2.a4c (4,054 bytes)


2012-04-05 04:48

developer   ~0000847

segmentation fault on reloading


2012-04-05 05:08

administrator   ~0000849

Please run via GDB and confirm whether this is a duplicate of bug 0000537.


2012-04-05 05:35

administrator   ~0000851

I do get this error with a previous version of ASCEND. The stack trace is:

ascend/compiler/module.c:1008 (ModuleSearchPath): File 'Desktop/heatex2.a4c' opened directly, without path search
Note: Module heatex2.a4c<0>: Module for 'Desktop/heatex2.a4c' created OK.
ascxx/library.cpp:117 (load): Beginning parse of heatex2.a4c<0>
ascend/compiler/scanner.l:837 (Asc_ScannerPushBuffer): REQUIREd module "atoms.a4l" already PROVIDEd
ascend/compiler/scanner.l:837 (Asc_ScannerPushBuffer): REQUIREd module "atoms.a4l" already PROVIDEd
ascend/compiler/scanner.l:837 (Asc_ScannerPushBuffer): REQUIREd module "system.a4l" already PROVIDEd
ascend/compiler/statio.c:742 (WriteStatementErrorMessage): Unverifiable name or illegal type in a relation
ascxx/library.cpp:141 (load): 3 library entries loaded from Desktop/heatex2.a4c
/usr/lib/python2.7/dist-packages/ascend/ GtkWarning: IA__gdk_window_get_width: assertion `GDK_IS_WINDOW (window)' failed
/usr/lib/python2.7/dist-packages/ascend/ GtkWarning: IA__gdk_window_get_height: assertion `GDK_IS_WINDOW (window)' failed
/usr/lib/python2.7/dist-packages/ascend/ GtkWarning: gdk_window_invalidate_rect_full: assertion `GDK_IS_WINDOW (window)' failed
Relation sharing set to True
Binary compilation set to False

 Pass1RealExecuteFOR called

 Pass1RealExecuteFOR called

 Pass1RealExecuteFOR called
ascend/compiler/statio.c:742 (WriteStatementErrorMessage): COND not allowed inside a FOR. Try FOR inside COND

PROGRAM FATAL ERROR: ascend/compiler/instantiate.c:10082:Pass2ExecuteForStatements: Assertion failed: return_value

Program received signal SIGABRT, Aborted.
0xb7fdf424 in __kernel_vsyscall ()
(gdb) where
#0 0xb7fdf424 in __kernel_vsyscall ()
#1 0xb7c1ac8f in __GI_raise (sig=6)
    at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#2 0xb7c1e2b5 in __GI_abort () at abort.c:92
#3 0xb58a81bb in asc_panic_line (status=100,
    filename=0xb59ebd80 "ascend/compiler/instantiate.c", line=10082,
    function=0xb59f0ee9 "Pass2ExecuteForStatements",
    fmt=0xb59ebd6b "Assertion failed: %s") at ascend/general/panic.c:146
#4 0xb5907f32 in Pass2ExecuteForStatements (inst=0x95bbb88, sl=0x91d6908)
    at ascend/compiler/instantiate.c:10082
#5 0xb5909add in Pass2RealExecuteFOR (inst=0x95bbb88, statement=0x91d6918)
    at ascend/compiler/instantiate.c:10725
#6 0xb590b36e in Pass2ExecuteFOR (inst=0x95bbb88, statement=0x91d6918)
    at ascend/compiler/instantiate.c:11389
#7 0xb590b669 in Pass2ExecuteStatement (inst=0x95bbb88, statement=0x91d6918)
    at ascend/compiler/instantiate.c:11492
#8 0xb590bd28 in Pass2ExecuteRelationStatements (blist=0x922a148,
    work=0x95bbb88, changed=0xbfffe5f4) at ascend/compiler/instantiate.c:11700
#9 0xb590c2ad in Pass2ProcessPendingInstancesAnon (result=0x95bbb88)
    at ascend/compiler/instantiate.c:11981
#10 0xb590da92 in Pass2InstantiateModel (result=0x95bbb88, pcount=0xbfffe67c)
    at ascend/compiler/instantiate.c:12685
#11 0xb590df44 in NewInstantiateModel (def=0x95877c0)
---Type <return> to continue, or q <return> to quit---
    at ascend/compiler/instantiate.c:12899
#12 0xb590e367 in NewRealInstantiate (def=0x95877c0, intset=0)
    at ascend/compiler/instantiate.c:13081
#13 0xb590e513 in NewInstantiate (type=0x956e410, name=0x956e5fc, intset=0,
    defmethod=0x0) at ascend/compiler/instantiate.c:13130
#14 0xb5959d4b in SimsCreateInstance (type=0x956e410, name=0x956e5fc,
    format=e_normal, defmethod=0x0) at ascend/compiler/simlist.c:156
#15 0xb62e8827 in Type::getSimulation (this=0x9587fc0, sym=...,
    rundefaultmethod=@0xbfffe8ee) at ascxx/type.cpp:156
#16 0xb636ba65 in _wrap_Type_getSimulation__SWIG_0 ()
   from /usr/lib/python2.7/dist-packages/ascend/
#17 0xb636c191 in _wrap_Type_getSimulation ()
   from /usr/lib/python2.7/dist-packages/ascend/
#18 0x080fb53d in PyEval_EvalFrameEx ()
#19 0x080f7e20 in PyEval_EvalFrameEx ()
#20 0x080fd804 in PyEval_EvalCodeEx ()
#21 0x0808c512 in ?? ()
#22 0x0805dc31 in PyObject_Call ()
#23 0x080738bd in ?? ()
#24 0x0805dc31 in PyObject_Call ()
#25 0x080f704e in PyEval_CallObjectWithKeywords ()
#26 0x08077a76 in PyInstance_New ()
#27 0x0805dc31 in PyObject_Call ()
---Type <return> to continue, or q <return> to quit---
#28 0x080f81c1 in PyEval_EvalFrameEx ()
#29 0x080fd804 in PyEval_EvalCodeEx ()
#30 0x080fe177 in PyEval_EvalCode ()
#31 0x0811acd0 in ?? ()
#32 0x0811b8e9 in PyRun_FileExFlags ()
#33 0x0811c4cc in PyRun_SimpleFileExFlags ()
#34 0x0812c7c6 in Py_Main ()
#35 0x0805da0b in main ()


2012-04-05 05:38

administrator   ~0000852

Last edited: 2012-04-05 05:39

View 2 revisions

The key issue seems to be the message "COND not allowed inside a FOR. Try FOR inside COND" so this model contains illegal syntax. I know! I probably wrote it. Bad me.

To fix this we need to ensure the error message is returned safely to the user, without a crash being produced.

Confirmed at changeset 4059 (trunk) on Ubuntu 11.10.


2012-04-06 09:10

administrator   ~0000856

This problem seems to go away when line instantiate.c:10076 is commented out (at r4059). Will check with Ben if there are side effects from that.


2012-04-06 09:45

manager   ~0000857

Email from: Ben Allan <>

if indeed cond is not allowed inside for (wouldn't surprise me, but
added after I left cmu), this should be checked for (it's easy) in
typedef.c/typelint.c where other statement types are being checked for
appearing only in correct contexts.

On Thu, Apr 5, 2012 at 4:01 PM, Mantis Bug Tracker <> wrote:
> The following issue has been UPDATED.
> [EmailReporting -> Removed part identified as reply]


2012-04-06 09:50

manager   ~0000858

Email from: Ben Allan <>

normally, the offending statement(s) should be marked
bad/uncompilable/completed and the rest of compilation continues
uninterrupted. The crash is happening because an assert is violated;
ascend (as a policy) does not depend on assert() for correctness.
production compilers are built with -DNDEBUG to disable assert. the
assert is in the right place because the parser/typechecks are
supposed to stop this assert ever failing.

On Thu, Apr 5, 2012 at 4:01 PM, Mantis Bug Tracker <> wrote:
> The following issue has been UPDATED.
> [EmailReporting -> Removed part identified as reply]


2012-04-07 02:39

administrator   ~0000859

OK so this bug is really a missing test in the typelint process, which should have marked the statement as invalid earlier in the instantiation sequence.

Issue History

Date Modified Username Field Change
2009-06-22 12:46 john New Issue
2009-06-22 12:46 john File Added: heatex2.a4c
2009-06-22 12:46 john Target release => 0.9.6
2009-06-22 13:22 john File Deleted: heatex2.a4c
2009-06-22 13:22 john File Added: heatex2.a4c
2009-06-28 01:38 john Target Version => 0.9.7
2012-04-05 04:48 sreenatha Note Added: 0000847
2012-04-05 05:08 john Note Added: 0000849
2012-04-05 05:35 john Note Added: 0000851
2012-04-05 05:38 john Note Added: 0000852
2012-04-05 05:39 john Note Edited: 0000852 View Revisions
2012-04-05 05:40 john Assigned To => john
2012-04-05 05:40 john Status new => confirmed
2012-04-06 09:01 john Target Version 0.9.7 => 0.9.8
2012-04-06 09:10 john Note Added: 0000856
2012-04-06 09:45 ben Note Added: 0000857
2012-04-06 09:50 ben Note Added: 0000858
2012-04-07 02:39 john Note Added: 0000859
2012-04-11 06:19 john Target Version 0.9.8 => 1.0
2013-02-26 13:39 john Target Version 1.0 => 0.9.9