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

[Philip Nienhuis]

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

Thanks very much Mike and Dmitri.

Correction:
Please use this link for xmlread/xmlwrite download:
http://hg.code.sf.net/p/octave/io/file/a31d38568851/inst/
(because I now see and only then remembered I had already commented out the
demos before finally removing the XML functions).

@Dmitri: both xercesImpl.jar and xml-apis.jar are required for xmlread.m /
xmlwrite.m. Maybe xmlread.m can invoke your files too, I'd say it merely needs
an (any) XML parser, but that's up to Pantxo (author of the XML functions). 

Meanwhile, on my laptop I'm running this:
ii = 0;

while 1
  print ("%d\n", ++ii);
  demo xmlread
endwhile


... and Octave is happily plowing along, count at 600+ now.
Mageia-7, xercesImpl.jar and xml-apis.jar from Nov 26 2010, version 2.11.0,
OpenJDK 1.8.0.252

Because AFAICS there's nothing wrong with the xmlread.m code and I can't
imagine widely used code like Xerces being at fault, I'm wondering if we're
hit by the old elusive issue on fast systems with SSD of trying to read from a
file before the low-level system process creating it has completely finalized
its operation?
Could easily be tested by inserting a 'pause (0.25)' statement in the demo
section immediately before or after the comment line:
'## Read the svg file and check the root node is named "svg"'
(I think (just a WAG) that a .25 sec. delay should do)
Could any of you please try that and report back?

FWIW, my laptop (counter now at 800+) is a 4+ yr old core i5 X230 Thinkpad (w.
SSD). No issues there with being too fast :-)


    _______________________________________________________

Reply to this item at:

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

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