help-octave
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: audio check?


From: John W. Eaton
Subject: Re: audio check?
Date: Wed, 05 Sep 2007 12:53:26 -0400

On  5-Sep-2007, Jim Langston wrote:

| It looks like a loop:
| 
| (dbx) cont
| ^Cdbx: warning: Interrupt ignored but forwarded to child.
| address@hidden (address@hidden) signal INT (Interrupt) in 
std::char_traits<char>::eof at 
| 0xfbef0124
| 0xfbef0124: eof       : movl     $0xffffffff,%eax
| Current function is c_file_ptr_buf::underflow_common
|    72         if (! bump
| (dbx) list
|    72         if (! bump
|    73   #if defined (CXX_ISO_COMPLIANT_LIBRARY)
|    74             && c != traits_type::eof ())
|    75   #else
|    76             && c != EOF)
|    77   #endif
|    78           ungetc (c, f);
|    79  
|    80         return c;
|    81       }
| (dbx) cont
| ^Cdbx: warning: Interrupt ignored but forwarded to child.
| address@hidden (address@hidden) signal INT (Interrupt) in 
c_file_ptr_buf::underflow at line 53 
| in file "c-file-ptr-stream.h"
|    53     int_type underflow (void) { return underflow_common (false); }
| (dbx) list
|    53     int_type underflow (void) { return underflow_common (false); }
|    54  
|    55     int_type uflow (void) { return underflow_common (true); }
|    56  
|    57     int_type pbackfail (int_type);
|    58  
|    59     std::streamsize xsputn (const char*, std::streamsize);
|    60  
|    61     std::streamsize xsgetn (char *, std::streamsize);
|    62  
| (dbx) cont
| ^Cdbx: warning: Interrupt ignored but forwarded to child.
| address@hidden (address@hidden) signal INT (Interrupt) in _ungetc_unlocked at 
0xfbe151d1
| 0xfbe151d1: _ungetc_unlocked+0x0011:    addl     $0x00069e30,%ebx
| Current function is c_file_ptr_buf::underflow_common
|    78           ungetc (c, f);
| (dbx)

The next question is why is it looping?  Is it at the end of the file?
Are we incorrectly trying to put EOF back on the input stream?  If so,
what is the source of that error?  It looks like this must be
happening in one of the calls to fread in wavread.m.  Can you
determine which call to fread it is, and whether the data that has
been read up to that point is correct?

jwe


reply via email to

[Prev in Thread] Current Thread [Next in Thread]