With Sun/Studio, when the stream is read, initially it is empty, because
it is empty, underflow() is called to fill it, this is different than
Linux/GNU.
After that, underflow() is called when a character is needed or is
empty.
The algorithm in the underflow method getting overridden by Octave
is going into an infinite loop because it does an fgetc and an ungetc
but never reports an eof.
I think that a setg must be called in order to correctly handle the
underflow.
Does anyone know who has written the overflow method an can give
me a pointer? I created a test case which initially looked just like
the
current method, and indeed, went into an infinite loop, changing it to
do a setg:
streambuf::int_type FILE_buffer::underflow()
{
if (fptr_)
{
int_type c = fgetc (fptr_);
if (c != traits_type::eof ())
{
printf( "int_type %c\n", c );
buffer_[0] = c;
setg( &buffer_[0], &buffer_[0], &buffer_[1] );
}
return (streambuf::int_type) c;
}
else
return traits_type::eof ();
}
took care of the infinite loop and allowed the read to get the data
it needs. What I need to do, and haven't looked at yet, is correctly
handling the buffer which is built for the read (ie. u.buf)
Jim
////////////////////////////
Jim Langston wrote:
I think I have created a test case which is doing something similar
to what Octave is doing with the reading of the .wav file. My only
problem is that it will read a character and not loop. Anyone want
to enhance or shoot down?
Jim
//////////////////////////////
Jim Langston wrote:
Hi all,
Pursuing further - in oct-stream.cc
is.read (u.buf, sizeof (typename
octave_type_traits<READ_T>::val_type));
The size is 1
This call is made and never returns, what is happening is that
underflow is getting
called and goes into a continuous loop calling the logic in
underflow_common.
underflow_common resides in c-file-ptr-stream.cc
on Linux, the read gets called with a size of 1 as well, and returns
after the read, underflow
and, hence, underflow_common are never called.
It would be helpful for me if someone could break the logic down and
create a smaller program
doing the same thing, ie. create a streambuf, open a .wav file, read
into the buffer with size one
and return, while overriding the underflow method.
Any help, thoughts, ideas ?
Jim
////////////////////////////////////////////////////
Jim Langston wrote:
Hi John,
Maybe you can give me a pointer, on the audio read
error I've been having, I think I have it isolated down,
it looks like it is in the underflow_common method and in
particular the ungetc function.
On Solaris, in the manpage:
The ungetc() function pushes the byte specified by c (con-
verted to an unsigned char) back onto the input stream
pointed to by stream. The pushed-back bytes will be returned
by subsequent reads on that stream in the reverse order of
their pushing. A successful intervening call (with the
stream pointed to by stream) to a file-positioning function
( fseek(3C), fsetpos(3C) or rewind(3C)) discards any
pushed-back bytes for the stream. The external storage
corresponding to the stream is unchanged.
Four bytes of push-back are guaranteed. If ungetc() is
called too many times on the same stream without an inter-
vening read or file-positioning operation on that stream,
the operation may fail.
If the value of c equals that of the macro EOF, the opera-
tion fails and the input stream is unchanged.
A successful call to ungetc() clears the end-of-file indica-
tor for the stream. The value of the file-position indicator
for the stream after reading or discarding all pushed-back
bytes will be the same as it was before the bytes were
pushed back. The file-position indicator is decremented by
each successful call to ungetc(); if its value was 0 before
a call, its value is indeterminate after the call.
Whereas w/ Fedora, from manpage:
ungetc() pushes c back to stream, cast to unsigned char, where
it is
available for subsequent read operations. Pushed-back
characters will
be returned in reverse order; only one pushback is guaranteed.
Calls to the functions described here can be mixed with each
other and
with calls to other input functions from the stdio library for
the same
input stream.
Does anything with the extra work that the function on the Solaris side
is doing
going to keep the logic from completing correctly?
Jim
////////////////////
Jim Langston wrote:
John W. Eaton wrote:
On 6-Sep-2007, Jim Langston wrote:
| Isolating down a little the old fashion way
|
| In oct-stream.cc
|
| printf("Getting ready to read\n") ;
| is.read (u.buf, sizeof (typename
| octave_type_traits<READ_T>::val_type));
| printf("Done Reading\n") ;
|
| This method never returns
|
|
| octave:1> A = [1:10; 1:10]/10;
| octave:2> wavwrite("a.wav", A);
| octave:3> [B, samples_per_sec, bits_per_sample] = wavread("a.wav");
| Getting ready to read
| ^C^CPress Control-C again to abort.
| ^Cpanic: Interrupt -- stopping myself...
| attempting to save variables to `octave-core'...
| save to `octave-core' complete
OK, but which call to fread in wavread is hanging? That should be
fairly easy to determine as wavread is a .m file. It would be helpful
to isolate this to a single call to fread rather than a call to
wavread. Also, since it seems you are the only one who can trigger
this problem, I think you are going to have to narrow it down to
something very specific, like "fread is called and it attempts to read
the following data and it fails to return because it is looping here,
because ...".
Also, perhaps this should be on the bug list?
I'm working with the thought that all problems I encounter are mine
since Octave has not been
compiled and run under this env. (OpenSolaris, Sun Studio 12 compilers)
- any pointers are
great as I dig them out. I changed wavread.m to include printf's around
the fread's, I get:
octave:1> [B, samples_per_sec, bits_per_sample] = wavread("a.wav");
Getting ready to read
^C^CPress Control-C again to abort.
^Cpanic: Interrupt -- stopping myself...
Opening File
Opened File - OK: 5
First fread RIFF/WAVE signature
attempting to save variables to `octave-core'...
save to `octave-core' complete
I'm not getting past the first fread encountered in the wavread.m file
Debugging output shows the call to iostream, and then calls to
c_file_ptr_buf and
in particular, the underflow method. I'm not sure what is triggering
this, but the bump
value is always false and the value of c never varies from 82. My
initial thought is
that the stream buffer is not getting read and cleaned out.
wavread.m snippet
......
printf("Opening File\n");
# open file for binary reading
[fid, msg] = fopen (filename, "rb");
if (fid < 0)
error ("wavread: %s", msg);
endif
#
#
printf("Opened File - OK: %d\n", fid);
## check for RIFF/WAVE header
printf ("First fread RIFF/WAVE signature\n");
ck_id = char (fread (fid, 4))';
printf ("First fread - OK - RIFF/WAVE signature\n");
fseek (fid, 4, SEEK_CUR);
printf ("Second fread RIFF/WAVE signature\n");
wave_id = char (fread (fid, 4))';
if (ck_id != "RIFF" || wave_id != "WAVE")
fclose (fid);
error ("wavread: file contains no RIFF/WAVE signature");
endif
.....
jwe
_______________________________________________
Help-octave mailing list
address@hidden
https://www.cae.wisc.edu/mailman/listinfo/help-octave
--
/////////////////////////////////////////////
Jim Langston
Sun Microsystems, Inc.
(877) 854-5583 (AccessLine)
AIM: jl9594
address@hidden
_______________________________________________
Help-octave mailing list
address@hidden
https://www.cae.wisc.edu/mailman/listinfo/help-octave
--
/////////////////////////////////////////////
Jim Langston
Sun Microsystems, Inc.
(877) 854-5583 (AccessLine)
AIM: jl9594
address@hidden
_______________________________________________
Help-octave mailing list
address@hidden
https://www.cae.wisc.edu/mailman/listinfo/help-octave
--
/////////////////////////////////////////////
Jim Langston
Sun Microsystems, Inc.
(877) 854-5583 (AccessLine)
AIM: jl9594
address@hidden
_______________________________________________
Help-octave mailing list
address@hidden
https://www.cae.wisc.edu/mailman/listinfo/help-octave
--
/////////////////////////////////////////////
Jim Langston
Sun Microsystems, Inc.
(877) 854-5583 (AccessLine)
AIM: jl9594
address@hidden
|