[Top][All Lists]

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

Re: Seg-fault [[];[]]

From: David Bateman
Subject: Re: Seg-fault [[];[]]
Date: Mon, 19 Jul 2004 18:56:57 +0200
User-agent: Mutt/1.4.1i

According to John W. Eaton <address@hidden> (on 07/15/04):
> On 15-Jul-2004, David Bateman <address@hidden> wrote:
> | Does anyone have a recent CVS of octave that they can try "[[];[]]"
> | and see if it seg-faults. I get a seg-fault in my patched version, but
> | not with 2.1.57 and rather than have to back patches out and rebuild
> | (slow), I'd hoped someone might be able to run the above test to at least
> | give me another data-point...
> I don't see this problem on a Debian x86 system with gcc 3.3.3.

Ok, I figured it out. What was happening was that in the function
tm_row_const::tm_row_const_rep::do_init_element, the empty matrix
values weren't being added to the list of matrices to be parsed. 
In the old behaviour, this was fine and saved a tiny amount of time.
However, with the new concatenation code this isn't ok for several

Firstly I was using the arguments in the tree_matrix to determine the
return value, and as [[];[]] resulted in no values being appended to
the list, I got the seg-fault when I tried to figure out the return value.

The second reason, why even the empty matrices need to be pushed to the
list is imagine something like "[gf([]),gf([])]", or "[sparse([]),sparse([])]"
or even for that matter "[1,gf([])]". You can't drop the empty matrices
as their mere existence determines the type of the return value!!

John, I've fixed this up and tested my solution. As I'm in contact with you
over other patches, I'll send the fix for this off-line


David Bateman                                address@hidden
Motorola CRM                                 +33 1 69 35 48 04 (Ph) 
Parc Les Algorithmes, Commune de St Aubin    +33 1 69 35 77 01 (Fax) 
91193 Gif-Sur-Yvette FRANCE

The information contained in this communication has been classified as: 

[x] General Business Information 
[ ] Motorola Internal Use Only 
[ ] Motorola Confidential Proprietary

reply via email to

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