- From: lpsmith at spod-central.org (Lucian Smith)
- Subject: [cellml-dev] segfault in Telicems
- Date: Tue, 23 Aug 2011 18:29:09 +0100
Just a note to say thanks for the suggestions--I've been out of town
again, but hope to be able to check them out soon.
-Lucian
* Andrew Miller <ak.miller at auckland.ac.nz> [2011-08-17 01:39] writes:
>
On 11/08/11 09:25, Lucian Smith wrote:
>
>I am getting an odd segfault in Telicems when I have compiled CellML on
>
>red hat linux to have a 32-bit runtime (-m32). I don't have the problem
>
>at all on ubuntu.
>
>
Hi Lucian,
>
>
It is hard to work out what is going on there from the information you
>
have given.
>
>
A few possible things to try:
>
* This type of issue can occasionally happen if some headers change
>
between parts of the code being compiled, and so expect different
>
structures - it is possible you compiled, updated your C++ headers (or
>
mixed platforms somehow) and then did a partial compile; have you tried
>
a completely clean build to see if the problem still happens?
>
* Are you sure your libstdc++ matches the headers you compiled with?
>
I note you mention using -m32, so I'm assuming you needed to do this
>
because you are building on a 64 bit system? However, you are loading
>
/usr/lib/libstdc++.so.6, which is usually the location for the 64-bit
>
libstdc++ on 64 bit systems - are you running this in a separate system
>
/ container, possibly with a different version of libstdc++?
>
* There is the possibility of a compiler bug, especially if you are
>
using an old gcc; does this happen at different optimisation levels
>
(e.g. try going from -O2 to -O0 and see if it is still a problem)?
>
>
If you still don't get it working, a bit more information would help
>
track this issue down:
>
>
* What distribution version exactly are you using? Can we have an
>
account on the system to debug the problem?
>
* What program are you using to call into the CellML API, and if it
>
is complex, can you reproduce this problem with a very simple program?
>
* What gcc / libstdc++ version are you using for this test?
>
>
If you still can't get this working, I'd also suggest filing a tracker
>
item at https://tracker.physiomeproject.org so this doesn't get forgotten.
>
>
Best wishes,
>
Andrew
>
>
>
>
>Here's the gdb stack trace from the segfault:
>
>
>
>(gdb) bt
>
>#0 0x00c04919 in __gnu_cxx::__exchange_and_add(int volatile*, int) ()
>
> from /usr/lib/libstdc++.so.6
>
>#1 0x00be7f9e in std::basic_string<char, std::char_traits<char>,
>
>std::allocator<char> >::_M_mutate(unsigned int, unsigned int, unsigned
>
>int) ()
>
> from /usr/lib/libstdc++.so.6
>
>#2 0x00be800a in std::basic_string<char, std::char_traits<char>,
>
>std::allocator<char> >::_M_replace_safe(unsigned int, unsigned int, char
>
>const*, unsigned int) () from /usr/lib/libstdc++.so.6
>
>#3 0x00be80a5 in std::basic_string<char, std::char_traits<char>,
>
>std::allocator<char> >::assign(char const*, unsigned int) () from
>
>/usr/lib/libstdc++.so.6
>
>#4 0x00be8225 in std::basic_string<char, std::char_traits<char>,
>
>std::allocator<char> >::operator=(char const*) () from
>
>/usr/lib/libstdc++.so.6
>
>#5 0xf78b4e32 in TeLICeMSLValue::release_storage (this=0xf78d3a88)
>
> at /user3/lpsmith/cellml-api/TeLICeMS/sources/TeLICeMStateScan.hxx:94
>
>#6 0xf78b4fc9 in TeLICeMSLValue::string (this=0xf78d3a88, aStr="g_init")
>
> at /user3/lpsmith/cellml-api/TeLICeMS/sources/TeLICeMStateScan.hxx:168
>
>#7 0xf78b427e in TeLICeMStateScan::yylex (this=0xffffceb8)
>
> at TeLICeMS/sources/TeLICeMScan.l:286
>
>#8 0xf789d226 in telicem_lex (aLValue=0xffffc99c, aLexer=0xffffceb8)
>
> at /user3/lpsmith/cellml-api/TeLICeMS/sources/TeLICeMSImpl.cpp:1268
>
>#9 0xf78bb9d9 in telicem_parse (aLexer=0xffffceb8,
>
>aParseTarget=0xffffcf40)
>
> at /user3/lpsmith/cellml-api/TeLICeMParse.gen.cpp:2361
>
>#10 0xf78aa002 in CDA_TeLICeMService::parseMaths (this=0x805edc8,
>
> aDoc=0x8060c3c, aMathText=0x8059acc L"g_init = 3 * x")
>
> at /user3/lpsmith/cellml-api/TeLICeMS/sources/TeLICeMSImpl.cpp:102
>
>#11 0xf7f78971 in Module::AddCellMLMathTo (this=0x8055260, formula=
>
> Traceback (most recent call last):
>
> File "/usr/share/gdb/python/libstdcxx/v6/printers.py", line 469, in
>
>to_string
>
> return self.val['_M_dataplus']['_M_p'].string (encoding, length = len)
>
>Runtime
>
>
>
>The 'AddCellMLMathTo' function is mine; the source code is:
>
>
>
> RETURN_INTO_OBJREF(ts, iface::cellml_services::TeLICeMService,
>
>CreateTeLICeMService());
>
> std::wstring wform(makeUTF16(formula));
>
> RETURN_INTO_OBJREF(tmr, iface::cellml_services::TeLICeMMathResult,
>
> ts->parseMaths(doc, wform.c_str()));
>
> // XXX it would be good to check tmr->errorMessage() and log the error
>
> - Andrew Miller
>
> RETURN_INTO_OBJREF(math, iface::mathml_dom::MathMLElement,
>
> tmr->mathResult());
>
>
>
>(the offending line is the 'RETURN_INTO_OBJREF(tmr,[...]);' bit.)
>
>
>
>Running it through valgrind gives an error at the exact same moment, but
>
>perhaps it's helpful:
>
>
>
>==25453==
>
>==25453== Process terminating with default action of signal 11 (SIGSEGV)
>
>==25453== Bad permissions for mapped region at address 0x662D43D
>
>==25453== at 0xC04919: __gnu_cxx::__exchange_and_add(int volatile*,
>
>int) (in /usr/lib/libstdc++.so.6.0.8)
>
>
>
>(and then the same back trace as gdb)
>
>
>
>The problem seems to be, weirdly enough:
>
>
>
>(gdb) frame 5
>
>#5 0xf78b4e32 in TeLICeMSLValue::release_storage (this=0xf78d3a88)
>
> at /user3/lpsmith/cellml-api/TeLICeMS/sources/TeLICeMStateScan.hxx:94
>
>94 mString = "";
>
>
>
>So there has to be something weird with memory management going on.
>
>
>
>It doesn't seem to matter what string I'm asking Telicems to parse; they
>
>all crash at the same point.
>
>
>
>-Lucian
>
>_______________________________________________
>
>cellml-tools-developers mailing list
>
>cellml-tools-developers at cellml.org
>
>http://lists.cellml.org/mailman/listinfo/cellml-tools-developers
>
>
_______________________________________________
>
cellml-tools-developers mailing list
>
cellml-tools-developers at cellml.org
>
http://lists.cellml.org/mailman/listinfo/cellml-tools-developers
Archive powered by MHonArc 2.6.18.