Another Java related Segmentation violation on WinXP

[Michael Goffioul]

On Jan 25, 2008 9:40 AM, John W. Eaton <jwe at bevo.che.wisc.edu> wrote:
> | d = readtext('data.txt')
> | d = readtext('data.txt')
> | d = readtext('data.txt')
> | d = readtext('data.txt')
> | d2 = readtext('data.txt')
>
> If you notice some problem with Octave's debug features, then I think
> you'll need to provide a precise description of what you are doing,
> what you see happening, and what you expect to happen before anyone
> will be able to help with the problem.

John, I could trace down the problem with VC debugger and it reveals a
problem with the scanf methods in oct-stream.cc (at least with MSVC).
The call is coming from the m-file (input string is "0.00000"):

     sscanf(s,'%1[ij] %1[+-] %f',3);

Following code execution, you reach octave_base_stream::do_scanf
at the cases '[' and '^' (line 1888). The expansion of the macro
BEGIN_CHAR_CLASS_CONVERSION lead to an octave_scan call
(line 1555, note that width == 1):

    OCTAVE_SCAN (is, *elt, tbuf);

As width is 1, tbuf is a 2-elements char array. I think now comes the
problem: it seems MSVC chose the execute the octave_scan specialized
version around line 1138, which simply does a "is >> valptr", without
taking care of the limited size of the valptr array. Looking at the code,
I have the impression that it is expected that the octave_scan generic
version around line 1111 is used instead (this version takes care of the
limited width of the output buffer).

You probably have a better understanding of what is the exact expected
behavior. Could you have a look?

(Note: this part of the code is only used on non-GCC compiler).

Michael.