Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#2778 closed defect (fixed)

OMEdit often can't parse xml output

Reported by: Adam Dershowitz <dersh@…> Owned by: Adeel Asghar
Priority: high Milestone: 1.9.2
Component: OMEdit Version: trunk
Keywords: Cc:

Description

Very often, when I run a simulation in OMEdit, on my Mac, it works fine. But, it seems that the output results don't get parsed properly. Everything else works, and I can see the actual data. It is just the output log stats. So, what I see in the Output window looks like this:

/private/var/folders/s4/0j3cshj161126ygbpbzsdkmd4h24dl/T/OpenModelica_adershowitz/OMEdit/Modelica.Mechanics.MultiBody.Examples.Elementary.DoublePendulum -port=63007 -logFormat=xml -w -lv=LOG_STATS
Error while parsing message xml tag mismatch 15:7
<message stream="LOG_STATS" type="info" text="### STATISTICS ###" />
<message stream="LOG_STATS" type="info" text="timer">
<message stream="LOG_STATS" type="info" text="    0.045562s          reading init.xml" />
<message stream="LOG_STATS" type="info" text="   0.0506857s          reading info.xml" />
<message stream="LOG_STATS" type="info" text="  0.00264133s          pre-initialization" />
<message stream="LOG_STATS" type="info" text="  0.00040838s [  2.4%] initialization" />
<message stream="LOG_STATS" type="info" text="   1.277e-05s [  0.1%] steps" />
<message stream="LOG_STATS" type="info" text="  0.00785925s [ 46.4%] creating output-file" />
<message stream="LOG_STATS" type="info" text="  4.4513e-05s [  0.3%] event-handling" />
<message stream="LOG_STATS" type="info" text=" 0.000625647s [  3.7%] overhead" />
<message stream="LOG_STATS" type="info" text="  0.00535942s [ 31.6%] simulation" />
<message stream="LOG_STATS" type="info" text="   0.0169513s [100.0%] total" />
</message>
<message stream="LOG_STATS" type="info" text="events">
Error while parsing message xml tag mismatch 3:10
<message stream="LOG_STATS" type="info" text="    0 state events" />
<message stream="LOG_STATS" type="info" text="    0 time events" />
</message>
<message stream="LOG_STATS" type="info" text="solver: DASSL">
<message stream="LOG_STATS" type="info" text="  350 steps taken" />
<message stream="LOG_STATS" type="info" text="  535 calls of functionODE" />
<message stream="LOG_STATS" type="info" text="   37 evaluations of jacobian" />
<message stream="LOG_STATS" type="info" text="   21 error test failures" />
<message stream="LOG_STATS" type="info" text="    0 convergence test failures" />
</message>
<message stream="LOG_STATS" type="info" text="### END STATISTICS ###" />

I would estimate that this happens about half the time. And, I have not yet figured out when it does or doesn't happen. It just seems somewhat random. But, to be clear, even when it happens the actual results are fine, it is just the displayed stats that end up showing all of the XML markup, and the error that it can't be parsed.
Note that everything starting with Error is red, so it clearly shows as an error.

Change History (7)

comment:1 by Martin Sjölund, 10 years ago

I talked with Adeel regarding this. The problem is that OMEdit needs to use a streaming xml reader. It does not at the moment.

comment:2 by Adam Dershowitz <dersh@…>, 10 years ago

The odd part is that it does sometimes work. And, the same model on the same computer sometimes works and sometimes doesn't. So, it seems like it could be a subtle timing issue that does allow the current xml reader to work half of the time.

comment:3 by Martin Sjölund, 10 years ago

Basically, OMEdit will query the output stream of the executable. It will then do something like:
"<root>" + output + "</root>", and try to parse the string as XML.

This is usually fine because the stream is flushed on newlines, and the </message> tag will be there. But sometimes, the stream is flushed at other positions.

A streaming XML reader solves this quite nicely.

comment:4 by Martin Sjölund, 10 years ago

Milestone: 1.9.11.9.2

This ticket was not closed for 1.9.1, which has now been released. It was batch modified for milestone 1.9.2 (but maybe an empty milestone was more appropriate; feel free to change it).

comment:5 by Adeel Asghar, 10 years ago

Resolution: fixed
Status: newclosed

Fixed in r23595.

I never has that problem so I can't really test. But now since we are using a incremental parser I hope you won't even face this problem anymore.

comment:6 by Adam Dershowitz <dersh@…>, 10 years ago

Since this fix I have yet to see it either. Looks like the incremental parser solved it.

comment:7 by Adeel Asghar, 10 years ago

Great!

Note: See TracTickets for help on using tickets.