octave-3.0.3 crashes while executing 'expfit' ("free(): invalid pointer")

[Sergei Steshenko]

--- On Wed, 12/24/08, John W. Eaton <jwe at octave.org> wrote:

> From: John W. Eaton <jwe at octave.org>
> Subject: Re: octave-3.0.3 crashes while executing 'expfit' ("free(): invalid pointer")
> To: sergstesh at yahoo.com
> Cc: bug-octave at octave.org
> Date: Wednesday, December 24, 2008, 6:08 PM
> On 24-Dec-2008, Sergei Steshenko wrote:
> 
> | A probably better guess would be that it's some kind
> of integer index overflow.
> | 
> | I.e. the index is integer and not unsigned, and when it
> crosses the 2G
> | limit it becomes negative.
> 
> Octave's Array class contains code to prevent
> allocations that can't
> be indexed.  What happens on your system if you try
> 
>   ones (1, 1024*1024*256);
> 
> (i.e., 2GB of memory)?  I see
> 
>   octave:1> ones (1, 1024*1024*256);
>   error: memory exhausted or requested size too large for
> range of Octave's index type -- trying to return to
> prompt
> 
> even on my 64-bit system since I'm not compiling with
> --enable-64, and
> so octave_idx_type is a 32-bit signed integer.
> 
> However, it is possible that some allocation of a temporary
> workspace
> variable in some linear algebra function does not check,
> and is
> allocating something that is too large to index.  But I
> don't see how
> that could happen, since I think all of those quantities
> should be at
> least 32 bits wide.  So attempting to allocate more than
> 2^31 elements
> would fail as the block to be allocated would be greater
> than 2GB.
> 
> | My wild guess there is 'new'/'malloc'
> somewhere which doesn't check pointer
> | for NULL; on a 64 bits system memory allocation error is
> less likely than
> | on a 32 bits system.
> 
> With very few exceptions, all allocation in Octave should
> use new, not
> malloc.  So checking for new returning 0 is not necessary
> since
> operator new will throw an exception if the allocation
> fails.
> 
> jwe

John,

I saw a lot of 

"
error: memory exhausted or requested size too large for
range of Octave's index type -- trying to return to
prompt
"

messages playing with the example I sent - with different parameters,
of course, and such 'octave' behavior is quite correct - it issues a
meaningful error message and dies.

The "vicious beauty" of the example I sent is that it manages to crash 
'octave' in a manner 'octave' doesn't issue such an out of range message.

Actually, I once abandoned the problem. This is because I was running
something heavy on my machine in parallel and thought that I wanted to
much from my OS/machine - nobody is perfect, especially under load.

But then I was hit by the problem again on the same machine with no load.
This time I remembered the parmeters causing it and created a small test
case I sent.

As I said, may thoughts about the root cause were only wild guesses.

We need somebody with 32 bits 'octave' preferably on Linux in order to
try to reproduce the failure first.

Thanks,
  Sergei.