help-octave
[Top][All Lists]
Advanced

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

Re: Memory exaustion or size too large for index


From: Jaroslav Hajek
Subject: Re: Memory exaustion or size too large for index
Date: Thu, 25 Feb 2010 15:06:55 +0100

On Thu, Feb 25, 2010 at 2:22 PM, Jaroslav Hajek <address@hidden> wrote:
> On Thu, Feb 25, 2010 at 2:11 PM, Carlo de Falco <address@hidden> wrote:
>>
>> On 25 Feb 2010, at 14:08, Jaroslav Hajek wrote:
>>
>>> Ah. So you need the -m64 option for building Octave.
>>
>> do I need to rebuild also dependecies?
>> what if some of them are built without -m64?
>
> I suppose so. Anything that accepts pointers will probably need a
> rebuild, which I think is just about anything we use.
> Given that the -m64 option affects even sizeof(long), I would deem it
> generally unsafe to combine the binaries w/w/o this option.
>
> I see we need an additional check for the case where sizeof(size_t) ==
> sizeof(octave_idx_type) and you want to operate on the edge of the
> pointer address range. That's going to be dangerous anyway (and I
> wouldn't be surprised if something failed) but at least we can give a
> proper error here.
>

I've pushed a change that implements additional check for this weirdo behavior.
http://hg.savannah.gnu.org/hgweb/octave/rev/ec05728ce7f0

However, I still think this is a bug on your platform, I think new
double[INT_MAX/2] should throw a bad_alloc if pointers are 32-bit,
because then the result is not even fully addressable. operator new[]
signature accepts a plain size_t argument, hence the total size
*should* really fit into size_t.

Doing the check just at the allocation time won't hurt performance
significantly though. Besides, for the complex and integer types we
need to safeguard the computation anyway, because we're allocating via
char[].

regards

-- 
RNDr. Jaroslav Hajek, PhD
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz


reply via email to

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