[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: c++ question: alloc'ing and free'ing arrays
From:       David Leimbach <leimbacd () bellsouth ! net>
Date:       2002-08-06 20:05:12
[Download RAW message or body]

I would post this to the comp.lang.c++.moderated newsgroup as it is WAY 
offtopic here.

Dave
On Saturday, August 3, 2002, at 01:05 PM, Marcos Dione wrote:

>
>   a friend of mine is developing a class that has lots of arrays of
> different types (POD and non-POD types), and the class must resize
> those arrays (some are even matices) on runtime.
>
>   so, when using a POD type, she uses
>
>   array= NULL;
>
> in the default constructor,
>
>   array= new int[size];
>
> in other constructors (ones that already know which is the size the 
> array should be),
>
>   delete[] array;
>
> in the destructor and
>
>   if (array!=NULL)
>     delete[] array;
>   array= new int[size]
>
> in the resize method. with non-POD types, she uses
>
>   npt **npa;
>
>   npa= NULL;
>
>   npa= new npt* [size]
>   for (int i= 0; i<size; i++)
>     npa[i]= new npt;
>
>   for (int i= 0; i<size; i++)
>     delete npa[i];
>   delete[] npa;
>
>   if (npa!=NULL) {
>     for (int i= 0; i<size; i++)
>       delete npa[i];
>     delete[] npa;
>   }
>   npa= new npt* [size]
>   for (int i= 0; i<size; i++)
>     npa[i]= new npt;
>
>   in the same places respectively.
>
>   now, the problem is that in certain circumstances the resize methods
> segfault in the new (!!!) statement. using gdb, running the test
> program I get this backtrace:
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x400fdaae in free () from /lib/libc.so.6
> (gdb) bt
> #0  0x400fdaae in free () from /lib/libc.so.6
> #1  0x400fd77a in malloc () from /lib/libc.so.6
> #2  0x400fcf54 in malloc () from /lib/libc.so.6
> #3  0x400588f9 in __builtin_new () from 
> /usr/lib/libstdc++-libc6.2-2.so.3
> #4  0x40058adf in __builtin_vec_new () from 
> /usr/lib/libstdc++-libc6.2-2.so.3
> #5  0x0804aa83 in Network::create_errores (this=0x8054938, 
> num_neurons_output=1) at Network.cpp:388
> #6  0x0804c140 in operator>> (s=@0xbffffcb8, ntk=@0x8054938) at 
> Network.cpp:657
> #7  0x0804900b in main ()
> #8  0x400a814f in __libc_start_main () from /lib/libc.so.6
>
> (the create_errores method is a resize method that resizes a POD array
> with size= num_neurons_output which is 1). also, looking @ kde's code
> for reference, I find that a lot of new statements that alloc arrays
> that are not deleted later (examples includes some noatun plugins in
> the kdeaddons module, like synaescope.cpp in tippercanoe), or even
> arrays that I think are bad deleted, like the cr array in
> kdebase/kcontrol/crypto/crypto.cpp:KCryptoConfig::slotCAImport (I
> think it should be delete[] instead of delete)
>
>   also, I don't guess *why* new (actually, malloc) is calling free! is
> it a libc bug? I don't think so. what's more strange is that the same
> code works on other circumstances, like in the constructor. I hope you
> can give me a hint on what's going on... also, I would like to know
> about any lib that can store and retrieve objects to/from disk. as you
> can see, she's trying to parse a Network from an istream.
>
>   thanks in advance
>
>>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to 
>>> unsubscribe <<
>

 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]