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 |
Reporter | john | ||||
Assigned To | john | ||||
Priority | normal | Severity | minor | Reproducibility | have not tried |
Status | closed | Resolution | fixed | ||
Product Version | |||||
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 >> pygtk/symchar.cpp:25 >> #3 0xb7ad4972 in Instanc::getSymbolValue (this=0xaa65098) at >> pygtk/instance.cpp:437 >> #4 0xb7b3ea5b in _wrap_Instance_getSymbolValue () from >> /home/john/ascend/pygtk/_ascpy.so >> >> 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. >> >> Cheers >> JP >> >> 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. Hi John, 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. Cheers, Dip. On Wed, Jun 24, 2009 at 3:58 PM, John Pye <john@curioussymbols.com> wrote: Hi all 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 http://ascendcode.cheme.cmu.edu/viewvc.cgi?view=rev&revision=2375 I think that I'm probably overdue for a bit of a cleanup and rewrite of instance.cpp. Krishnan's example shows that the problem didn't arise unless the symbol_constant was unassigned. Cheers JP |
Date Modified | Username | Field | Change |
---|---|---|---|
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 22:45 | svn | ||
2009-06-25 23:01 | john | Relationship added | related to 0000408 |
2011-06-23 10:52 | john | Status | resolved => closed |