[Octave-bug-tracker] [bug #58004] [octave forge] (io) xmlread.m makes Octave crash

[Philip Nienhuis]

Follow-up Comment #20, bug #58004 (project octave):

Thanks for the tests, Mike.

First off, let's not forget that this is all about a mere demo that
occasionally causes a segfault. We haven't seen any bug reports about
functioning of xmlread.m itself, have we?

If a time delay fixes the issue I'd say it is the easiest solution. 

Mike, your hint that this issue might be related Java I/O may have some merit.
My experience is that it is rather XML files that have these issues. But those
are usually read using Java methods; so there you are.

In the io package there are spreadsheet I/O test scripts that do similar
things as xmlread, i.e., writing a file and immediately reading it back. Most
spreadsheet file formats are XML-based. Those test scripts have always
required some delays, generally with XML and esp. with zipped XML files,
otherwise errors (not segfaults) would occur. The more complicated the Java
code is, the longer the delays need to be; esp. invoking LibreOffice through
the Java-UNO bridge (a beast) would require .5 sec delays.
Now, xmlread.m and xmlwrite.m are contributed functions; until now I simply
didn't realize that the xmlread demo might need similar treatment as the
spreadsheet test scripts that I did author.
So I am not surprised that a delay mitigates the issue with xmlread as well.
Only that this took a while to trickle down :-)

What I'll do:
Add some delay in the xmlread demo and put the XML I/O files back. Since
io-2.6.1 a few other bugs have been fixed so I believe a new release might be
warranted anyway. If Olaf doesn't get any segfaults I think this bug can be
closed then.


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?58004>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/