error: memory exhausted or requested size too large

[Jim Langston]

Hi Jaroslav,

Here is config.log from my last try. I have tried a lot of different 
variations, this
last was without any 64bit options. You are correct in that after 
compiling, my
next step is always to run gmake check, which is this case exits 
immediately on
the first test.

Also, I tried your suggestion of running ./run-octave, the result was 
octave did not
start, and my cpu utilization went to 100% and stayed there, never 
bringing up the
Octave prompt.

Jim

/////////////////////////////

Jaroslav Hajek wrote:
> On Mon, Aug 11, 2008 at 9:04 PM, Jim Langston <Jim.Langston at sun.com> wrote:
>   
>> John W. Eaton wrote:
>>     
>>> On 11-Aug-2008, Jim Langston wrote:
>>>
>>> | Sorry for taking awhile to get back - I introduced three changes and
>>> | been trying to work
>>> | my way through. The changes, upgrading my OS to OpenSolaris B86, changed
>>> | my compilers
>>> | to Sun Studio 12 0708, and changed Octave to version 3.0.1.
>>> |
>>> | - Changed my version of Octave to 2.9.13, leaving the compilers the same
>>> | and the OS the same.
>>> |    And I still get the same error when running the check after compilation.
>>> |
>>> | - Changed my compiler to Sun Studio 12 0404, leaving 2.9.13, and still
>>> | get the error.
>>> |
>>> | What would cause the error to get generated ?
>>> |
>>> | - I'm running 64bit
>>> | - I recompiled using 64bit, same error
>>> | - I re-configure using --enable-64 and 64bit compiler options, same error.
>>>
>>> Did you notice the configure warning about the --enable-64 option?
>>> Are you sure you want to use --enable-64?  If so, then you'll need to
>>> ensure that all numerical libraries that you are using are built to be
>>> compatible with the 64-byte indexing that Octave expects.
>>>
>>> Have you tried building without --enable-64?
>>>
>>>       
>> Yes, noticed the warning, I did not use the --enable-64 until I hit the
>> error as I had not used it before. I had not used
>> any of the 64bit compiler options either. The options did not make a
>> difference and I'm back to where I was when
>> I did compile and run on the older versions of Octave.
>>
>>     
>
> This looks like some fatal configuration problem. It seems that not
> even a single test was started - did you try running octave in place
> (./run-octave) and doing some computations?
> Octave generally issues this error when it receives a std::bad_alloc
> exception. Given that you have so much RAM, something is utterly
> wrong.
> Also, can you please share your config.log file? Preferably for the
> 3.0.1 version, that's more relevant.
>
> regards,
>
>
>   
>>> jwe
>>>
>>>       
>> --
>> /////////////////////////////////////////////
>>
>> Jim Langston
>> Sun Microsystems, Inc.
>>
>> (877) 854-5583 (AccessLine)
>> AIM: jl9594
>> jim.langston at sun.com
>>
>> _______________________________________________
>> Help-octave mailing list
>> Help-octave at octave.org
>> https://www.cae.wisc.edu/mailman/listinfo/help-octave
>>
>>     
>
>
>
>   


-- 
/////////////////////////////////////////////

Jim Langston
Sun Microsystems, Inc.

(877) 854-5583 (AccessLine)
AIM: jl9594
jim.langston at sun.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www.cae.wisc.edu/pipermail/help-octave/attachments/20080812/7f206f4e/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: config.log.gz
Type: application/x-gzip
Size: 38040 bytes
Desc: not available
Url : https://www.cae.wisc.edu/pipermail/help-octave/attachments/20080812/7f206f4e/attachment-0001.bin