OMEdit segfaults when trying to parse part of a library

[Ravi Saripalli <ravi.saripalli@…>]

Attached please find a small library that I used to use without much problems earlier (upto 1.9). But since moving to 1.9.2+dev (r23815). When I use Open Model/Library files option and
point to the package.mo in the root of the package, I see the tree of the package on the left
window, but when I try to access "Uops" branch OMEdit crashes with segfault.

When I tried to trace the problem with "gdb" I get the OMEdit banner but nothing else happens.
Therefore I am unable to debug this issue.

However, I tried to run a sample simulation at command level with omc, where I could get some trace. It appears to be some parsing issue. (I made sure all my files are of UTF-8 type) but with no joy. Here is the trace of gdb session.(attached simulation sample files along with the library)

* gdb trace *
gdb omc
GNU gdb (GDB) Fedora 7.7.1-21.fc20
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <​http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<​http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<​http://www.gnu.org/software/gdb/documentation/>.
---Type <return> to continue, or q <return> to quit---
Type "apropos word" to search for commands related to "word"...
Reading symbols from omc...done.
(gdb) set args /home/ravi/DSTO/projects/Om/testing/heater/plant.mos ThermoS Modelica ModelicaServices
(gdb) run
Starting program: /home/ravi/software/om/bin/omc /home/ravi/DSTO/projects/Om/testing/heater/plant.mos ThermoS Modelica ModelicaServices
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[New Thread 0x7ffff4571700 (LWP 20697)]
[New Thread 0x7ffff3d70700 (LWP 20698)]
[New Thread 0x7ffff356f700 (LWP 20699)]
[New Thread 0x7ffff2d6e700 (LWP 20700)]
[New Thread 0x7ffff256d700 (LWP 20701)]
[New Thread 0x7ffff1d6c700 (LWP 20702)]
[New Thread 0x7ffff156b700 (LWP 20703)]
[New Thread 0x7fffea841700 (LWP 20704)]
[New Thread 0x7fffea040700 (LWP 20705)]
[New Thread 0x7fffe983f700 (LWP 20706)]
[New Thread 0x7fffe903e700 (LWP 20707)]
[New Thread 0x7fffdbfff700 (LWP 20708)]
[New Thread 0x7fffdb7fe700 (LWP 20709)]
[New Thread 0x7fffdaffd700 (LWP 20710)]
[New Thread 0x7fffda7fc700 (LWP 20711)]
[Thread 0x7fffea841700 (LWP 20704) exited]
[Thread 0x7fffe903e700 (LWP 20707) exited]
[Thread 0x7fffdb7fe700 (LWP 20709) exited]
[Thread 0x7fffe983f700 (LWP 20706) exited]
[Thread 0x7fffdbfff700 (LWP 20708) exited]
[Thread 0x7fffda7fc700 (LWP 20711) exited]
[Thread 0x7fffea040700 (LWP 20705) exited]
[Thread 0x7fffdaffd700 (LWP 20710) exited]
[New Thread 0x7fffda7fc700 (LWP 20712)]
[New Thread 0x7fffdaffd700 (LWP 20713)]
[New Thread 0x7fffdb7fe700 (LWP 20714)]
[New Thread 0x7fffdbfff700 (LWP 20715)]
[New Thread 0x7fffea841700 (LWP 20716)]
[New Thread 0x7fffea040700 (LWP 20717)]
[New Thread 0x7fffe983f700 (LWP 20718)]
[New Thread 0x7fffe903e700 (LWP 20719)]

Program received signal SIGPWR, Power fail/restart.
[Switching to Thread 0x7fffe903e700 (LWP 20719)]
lll_lock_wait ()

at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135

135 2: movl %edx, %eax
(gdb) bt
#0 lll_lock_wait ()

at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135

#1 0x00000035ca60a11b in _L_lock_812 ()

from /lib64/libpthread.so.0

#2 0x00000035ca609fe8 in GI_pthread_mutex_lock

(mutex=0x7ffff77639e0 <GC_allocate_ml>)
at ../nptl/pthread_mutex_lock.c:79

#3 0x00007ffff7517db0 in GC_generic_lock (

lock=0x7ffff77639e0 <GC_allocate_ml>)
at pthread_support.c:1872

#4 0x00007ffff7517df4 in GC_lock ()

at pthread_support.c:1954

#5 0x00007ffff7508df1 in GC_core_malloc_atomic (

lb=96) at malloc.c:238

#6 0x00007ffff751462e in GC_malloc_atomic (

bytes=96) at thread_local_alloc.c:209

#7 0x00007ffff62cca2e in mmc_alloc_words_atomic (
---Type <return> to continue, or q <return> to quit---

nwords=12)
at ../SimulationRuntime/c/meta/gc/mmc_gc.h:96

#8 0x00007ffff62ccac9 in mmc_mk_scon (

s=0x7fffe4002cd0 "/home/ravi/software/om/lib/omlibrary/Modelica 3.2.1/Electrical/QuasiStationary/Types.mo")
at ../SimulationRuntime/c/meta/meta_modelica.h:354

#9 0x00007ffff62cd7b6 in parseStream (

input=0x7fffe40008c0, langStd=32,
runningTestsuite=0) at parse.c:279

#10 0x00007ffff62ce0a2 in parseFile (

fileName=0x89dbd8 "/home/ravi/software/om/lib/omlibrary/Modelica 3.2.1/Electrical/QuasiStationary/Types.mo",
infoName=0x89dbd8 "/home/ravi/software/om/lib/omlibrary/Modelica 3.2.1/Electrical/QuasiStationary/Types.mo", flags=0, encoding=0x7d14e8 "UTF-8",

---Type <return> to continue, or q <return> to quit---

langStd=32, runningTestsuite=0) at parse.c:439

#11 0x00007ffff62ce10f in ParserExt_parse (

filename=0x89dbd8 "/home/ravi/software/om/lib/omlibrary/Modelica 3.2.1/Electrical/QuasiStationary/Types.mo",
infoname=0x89dbd8 "/home/ravi/software/om/lib/omlibrary/Modelica 3.2.1/Electrical/QuasiStationary/Types.mo", acceptedGrammar=1, langStd=32,
encoding=0x7d14e8 "UTF-8", runningTestsuite=0)
at Parser_omc.c:42

#12 0x00007ffff5f4140d in omc_ParserExt_parse (

threadData=0x7fffe903dca0, _filename=0x89dbd3,
_infoFilename=0x89dbd3, _acceptedGram=1,
_encoding=0x7d14e3, _languageStandardInt=32,
_runningTestsuite=0 '\000')
at /home/ravi/software/om/src/Compiler/FrontEnd/ParserExt.mo:45

#13 0x00007ffff5f42488 in omc_Parser_parsebuiltin (
---Type <return> to continue, or q <return> to quit---

threadData=0x7fffe903dca0, _filename=0x88d773,
_encoding=0x7d14e3)
at /home/ravi/software/om/src/Compiler/FrontEnd/Parser.mo:94

#14 0x00007ffff5f4261f in omc_Parser_parse (

threadData=0x7fffe903dca0, _filename=0x88d773,
_encoding=0x7d14e3)
at /home/ravi/software/om/src/Compiler/FrontEnd/Parser.mo:63

#15 0x00007ffff5f417e8 in omc_Parser_loadFileThread

(threadData=0x7fffe903dca0,
_inFileEncoding=0x893dc3)
at /home/ravi/software/om/src/Compiler/FrontEnd/Parser.mo:190

#16 0x00007ffff626e44c in System_launchParallelTasksThread (in=0x7fffffffc640) at System_omc.c:737
#17 0x00007ffff75161bb in GC_inner_start_routine (

sb=0x7fffe903dea0, arg=0x86b140)

---Type <return> to continue, or q <return> to quit---

at pthread_start.c:57

#18 0x00007ffff7510457 in GC_call_with_stack_base (

fn=0x7ffff7516114 <GC_inner_start_routine>,
arg=0x86b140) at misc.c:1860

#19 0x00007ffff7517a88 in GC_start_routine (

arg=0x86b140) at pthread_support.c:1666

#20 0x00000035ca607ee5 in start_thread (

arg=0x7fffe903e700) at pthread_create.c:309

#21 0x00000035c9ef4b8d in clone ()

at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

(gdb)

[Ravi Saripalli <ravi.saripalli@…>]

Correct Version of "plant.mo"

[Ravi Saripalli <ravi.saripalli@…>]

Correct version of "plant.mos"

[Ravi Saripalli <ravi.saripalli@…>]

Added correct version of mo and mos files for the plant. (apologies for the confusion)

[Martin Sjölund]

Which C-compiler and flags are you using? How much RAM in the machine?

[Martin Sjölund]

Note that the signal in gdb is an expected one. You need to continue or ignore SIGPWR to get to the seg.fault.

[Ravi Saripalli <ravi.saripalli@…>]

Replying to sjoelund.se:

Which C-compiler and flags are you using? How much RAM in the machine?

gcc (GCC) 4.8.3 20140911 (Red Hat 4.8.3-7)
CFLAGS = "-g O0"
8GB Memory

[Ravi Saripalli <ravi.saripalli@…>]

Debug Trace File

[Ravi Saripalli <ravi.saripalli@…>]

I have explored the problem further after updating my sources to Rev: 23866
and compiling with debug and -O0 swithches.

Attached find the debug trace (gdb-omc.txt.gz) for running omc under gdb with the following script.
Hope this helps.

scriptloadFile("ThermoS/package.mo");
loadFile("plant.mo");
ans:=checkModel(plant);
getErrorString();

[Ravi Saripalli <ravi.saripalli@…>]

Please note that I used the following options in gdb execution.

-ex 'handle SIG33 pass nostop noprint' \

-ex 'handle SIGPWR pass nostop noprint' \
-ex 'handle SIGXCPU pass nostop noprint' \
-ex 'set pagination 0' \
-ex 'run' \
-ex 'backtrace full' \
-ex 'info registers' \
-ex 'x/16i $pc' \
-ex 'thread apply all backtrace' \

[Martin Sjölund]

You should have gotten a stack overflow if you did not run it through gdb. Anyway, this is a duplicate of #2881.

[Ravi Saripalli <ravi.saripalli@…>]

Replying to sjoelund.se:

You should have gotten a stack overflow if you did not run it through gdb. Anyway, this is a duplicate of #2881.

Yes I did get stack overflow.
OK. What does this mean? I see that #2881 is reopened. Is there a way I can work around this problem?
Can you please suggest a way forward for me.

[Dietmar Winkler]

Sorting away the closed as invalid, won't fix and duplicate tickets from Future.