View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000407||ascend||pygtk gui||public||2009-06-25 00:27||2011-06-23 10:52|
|Priority||normal||Severity||minor||Reproducibility||have not tried|
|Target Version||0.9.6||Fixed in Version||0.9.7|
|Summary||0000407: Crash when creating models with unassigned symbol_constants|
|Description|| Jose Zapata wrote:|
> Does this mean that Krishnan's modification works because an
> assignment is considered a relation? (Dipak's models do provide
> variables, t1 and t2 respectively)
> just curious.
> John Pye wrote
>> Hi all
>> Couple of observations:
>> 1. when using the Tcl/Tk GUI, I get the following output, suggesting
>> that something strange happens with system_build:
>> scendIV% ascend/compiler/module.c:1006 (ModuleSearchPath): File
>> '/home/john/test-dipak.a4c' opened directly, without path search
>> ascend/compiler/module.c:430 (FindModuleFile): Duplicate module named
>> 'system.a4l' was found
>> ascend/compiler/scanner.l:829 (Asc_ScannerPushBuffer): REQUIREd module
>> "system.a4l" already PROVIDEd
>> ascend/compiler/bintoken.c:149 (BinTokenSetOptions): ...
>> ascend/compiler/instantiate.c:12361 (NewInstantiateModel): starting...
>> ascend/compiler/instantiate.c:12174 (Pass2InstantiateModel): starting...
>> g_instlist initialized
>> PROGRAM ERROR: ascend/system/analyze.c:1840:analyze_make_solvers_lists:
>> Problem should contain at least one variable and one relation.
>> PROGRAM ERROR: Nothing to make lists from (solver's lists)
>> ERROR: Models sent to solver:
>> 1 cannot have any pending parts
>> 2 cannot have NULL or unfinished relations.
>> 3 must have at least one variable.
>> 4 must have at least one objective or relation.
>> 5 must have at all WHEN-controlling values initialized.
>> Check pendings and problem structure.
>> system_build returned NULL.
>> 2. When I run with the PyGTK GUI through GDB, I get this:
>> Program received signal SIGSEGV, Segmentation fault.
>> [Switching to Thread 0xb7d486c0 (LWP 16020)]
>> 0xb7dc1613 in strlen () from /lib/tls/i686/cmov/libc.so.6
>> (gdb) where
>> #0 0xb7dc1613 in strlen () from /lib/tls/i686/cmov/libc.so.6
>> #1 0xb71ae7d7 in AddSymbol (c=0x0) at ascend/compiler/symtab.c:264
>> #2 0xb7ad1627 in SymChar (this=0xbfb3fb80, name=0x0) at
>> #3 0xb7ad4972 in Instanc::getSymbolValue (this=0xaa65098) at
>> #4 0xb7b3ea5b in _wrap_Instance_getSymbolValue () from
>> Here it is clear that Instanc object has been created somehow with a
>> NULL 'name'. Perhaps this is happening as a result of ignoring an error
>> return code from system_build.
>> The underlying cause appears to be that you wrote a syntactically
>> correct ASCEND model that actually contains no relations or variables.
>> Obviously that situation should be caught and return an error.
>> Hope to come up with a solution shortly.
>> Dipak Chirmade wrote:
>>> Dear all,
>>> I'm facing a small problem with 'symbol_constant' variable.
>>> Please find the attachment for 'test.a4c'. Whenever I'm trying to
>>> load model 'test2', I'm getting segmentation fault. To add more
>>> information here
>>> I'm using PyGTK interface.
|Tags||No tags attached.|
Fixed in changeset 2375.
Cool! [:)] Now I don't have any problem regardless of assignment/Initialisation where I originally faced the
problem with symbol_constants.
Thanks for fixing the bug/issue.
On Wed, Jun 24, 2009 at 3:58 PM, John Pye <email@example.com> wrote:
The bug here was that the Python wrappers weren't dealing properly with
the case of unassigned symbol_constants when presenting the model tree.
I made a fix for the crash here
I think that I'm probably overdue for a bit of a cleanup and rewrite of
Krishnan's example shows that the problem didn't arise unless the
symbol_constant was unassigned.
|2009-06-25 00:27||john||New Issue|
|2009-06-25 00:27||john||Status||new => assigned|
|2009-06-25 00:27||john||Assigned To||=> john|
|2009-06-25 00:27||john||Target release||=> 0.9.6|
|2009-06-25 00:28||john||Note Added: 0000563|
|2009-06-25 00:28||john||Resolution||open => fixed|
|2009-06-25 00:28||john||Fixed in Version||=> 0.9.7|
|2009-06-25 00:28||john||Target Version||=> 0.9.6|
|2009-06-25 00:28||john||Description Updated|
|2009-06-25 00:29||john||Status||assigned => resolved|
|2009-06-25 23:01||john||Relationship added||related to 0000408|
|2011-06-23 10:52||john||Status||resolved => closed|