[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
- Re: Memory exaustion or size too large for index, (continued)
- Re: Memory exaustion or size too large for index, Jaroslav Hajek, 2010/02/25
- Re: Memory exaustion or size too large for index, Carlo de Falco, 2010/02/25
- Re: Memory exaustion or size too large for index, Jaroslav Hajek, 2010/02/25
- Re: Memory exaustion or size too large for index, Carlo de Falco, 2010/02/25
- Re: Memory exaustion or size too large for index, Jaroslav Hajek, 2010/02/25
- Re: Memory exaustion or size too large for index, Carlo de Falco, 2010/02/25
- Re: Memory exaustion or size too large for index, Carlo de Falco, 2010/02/25
- Re: Memory exaustion or size too large for index, Jaroslav Hajek, 2010/02/25
- Re: Memory exaustion or size too large for index, Carlo de Falco, 2010/02/25
- Re: Memory exaustion or size too large for index, Jaroslav Hajek, 2010/02/25
- Re: Memory exaustion or size too large for index,
Jaroslav Hajek <=
- Re: Memory exaustion or size too large for index, Jaroslav Hajek, 2010/02/25
- Re: Memory exaustion or size too large for index, Carlo de Falco, 2010/02/25
- Re: Memory exaustion or size too large for index, Jaroslav Hajek, 2010/02/25
- Re: Memory exaustion or size too large for index, José Luis García Pallero, 2010/02/25
- Re: Memory exaustion or size too large for index, Jaroslav Hajek, 2010/02/25
- Re: Memory exaustion or size too large for index, Jaroslav Hajek, 2010/02/25
Re: Memory exaustion or size too large for index, Carnë Draug, 2010/02/25