Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Problems allocating memory

Reply
Thread Tools

Problems allocating memory

 
 
Neclepsio
Guest
Posts: n/a
 
      03-09-2007
Hi everyone.
I've made a class Matrix, which contains a pointer to the data and some
methods which all return a copy of the matrix modified in some way. The
program works quite well for small matrices, but as matrix dimension
grows up it crashes in deterministic locations depending on data,
machine and OS.
In particular, this happens when I test it with 3000x3000 matrices
(which take up more than 30MB) under three different machines/OSes. The
crash happens when much memory is still available (for example, under
cygwin, more than 1GB of virtual memory available), and I cannot think
there is no contiguous space for allocating the matrix.
I always use references and never pointers to matrices, so Matrix
objects are not dynamically allocated (the data, however, is allocated
by the constructor). Could this be a problem with stack/heap limitations?
Can someone help me with some idea on how to further investigate the
problem?

Thank you,
Ignazio
 
Reply With Quote
 
 
 
 
Ivan Vecerina
Guest
Posts: n/a
 
      03-09-2007
"Neclepsio" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
: Hi everyone.
: I've made a class Matrix, which contains a pointer to the data and
some
: methods which all return a copy of the matrix modified in some way.
The
: program works quite well for small matrices, but as matrix dimension
: grows up it crashes in deterministic locations depending on data,
: machine and OS.
: In particular, this happens when I test it with 3000x3000 matrices
: (which take up more than 30MB) under three different machines/OSes.
The
: crash happens when much memory is still available (for example, under
: cygwin, more than 1GB of virtual memory available), and I cannot think
: there is no contiguous space for allocating the matrix.
: I always use references and never pointers to matrices, so Matrix
: objects are not dynamically allocated (the data, however, is allocated
: by the constructor). Could this be a problem with stack/heap
limitations?
: Can someone help me with some idea on how to further investigate the
: problem?

The first thing to check is that you have provided correct
implementations of the destructor, the copy-constructor, and the
copy-assignment operators.

But to make your life easier in the first place, you should consider
using std::vector instead of a raw pointer to store the matrix data.

hth -Ivan
--
http://ivan.vecerina.com/contact/?subject=NG_POST <- email contact form
Brainbench MVP for C++ <> http://www.brainbench.com



 
Reply With Quote
 
 
 
 
Neclepsio
Guest
Posts: n/a
 
      03-09-2007
Thank you for replying.

Ivan Vecerina wrote:
> The first thing to check is that you have provided correct
> implementations of the destructor, the copy-constructor, and the
> copy-assignment operators.


Everything is ok. The second?

> But to make your life easier in the first place, you should consider
> using std::vector instead of a raw pointer to store the matrix data.


I needed raw pointers to use the BLAS library.

Thank you,
Ignazio
 
Reply With Quote
 
John Harrison
Guest
Posts: n/a
 
      03-09-2007
Neclepsio wrote:
> Hi everyone.
> I've made a class Matrix, which contains a pointer to the data and some
> methods which all return a copy of the matrix modified in some way. The
> program works quite well for small matrices, but as matrix dimension
> grows up it crashes in deterministic locations depending on data,
> machine and OS.
> In particular, this happens when I test it with 3000x3000 matrices
> (which take up more than 30MB) under three different machines/OSes. The
> crash happens when much memory is still available (for example, under
> cygwin, more than 1GB of virtual memory available), and I cannot think
> there is no contiguous space for allocating the matrix.
> I always use references and never pointers to matrices, so Matrix
> objects are not dynamically allocated (the data, however, is allocated
> by the constructor). Could this be a problem with stack/heap limitations?


The fact that it crashes under three different platforms suggests not.

> Can someone help me with some idea on how to further investigate the
> problem?


If you can reproduce the problem in a small program then post the code
here. Plently will be willing to take a look.

>
> Thank you,
> Ignazio


john
 
Reply With Quote
 
Jacek Dziedzic
Guest
Posts: n/a
 
      03-09-2007
Neclepsio wrote:
> Hi everyone.
> I've made a class Matrix, which contains a pointer to the data and some
> methods which all return a copy of the matrix modified in some way. The
> program works quite well for small matrices, but as matrix dimension
> grows up it crashes in deterministic locations depending on data,
> machine and OS.
> In particular, this happens when I test it with 3000x3000 matrices
> (which take up more than 30MB) under three different machines/OSes. The
> crash happens when much memory is still available (for example, under
> cygwin, more than 1GB of virtual memory available), and I cannot think
> there is no contiguous space for allocating the matrix.
> I always use references and never pointers to matrices, so Matrix
> objects are not dynamically allocated (the data, however, is allocated
> by the constructor). Could this be a problem with stack/heap limitations?


There is no "heap limitation", unless you impose it yourself
(hint: try "ulimit -a"). The stack is definitely limited, in
the order of a few MB usually (try "ulimit -s") -- but you only
hit this limitation if you allocate too many/much _local_ variables.

> Can someone help me with some idea on how to further investigate the
> problem?


If this is an x86 platform, I highly recommend valgrind,
this a utility that will point out many bugs to you, and does
not require a recompile. Other than that you may try
electric fence ("efence"), though this requires a recompile
and is not as useful as valgrind.

And the obvious way out -- recompile your code with debug
information on (usually the -g option), run it under a
debugger (like gdb), let it crash, then backtrace and
check where the problem occurs. Put tons of debug printouts
there and hopefully all will become clear.

HTH,
- J.
 
Reply With Quote
 
John Harrison
Guest
Posts: n/a
 
      03-09-2007
>
>> But to make your life easier in the first place, you should consider
>> using std::vector instead of a raw pointer to store the matrix data.

>
>
> I needed raw pointers to use the BLAS library.
>


std::vector does not prevent you from getting a raw pointer to the data.

john
 
Reply With Quote
 
Neclepsio
Guest
Posts: n/a
 
      03-09-2007
Jacek Dziedzic wrote:
> The stack is definitely limited, in
> the order of a few MB usually (try "ulimit -s") -- but you only
> hit this limitation if you allocate too many/much _local_ variables.


Yes, I know. In my despair, I was wondering if something like:

Matrix A(3000, 3000);
Matrix B(3000, 3000);
Matrix C(3000, 3000);

or

Matrix B = A.Transpose() * B.SubMatrix(Vector::All, Vector::All);
//(each method returns a new Matrix object)

Would take up much stack space... Anyway, since I get a bad_alloc in
Matrix constructor (which dynamically allocates the space), I don't
think it's the point.

> If this is an x86 platform, I highly recommend valgrind,
> this a utility that will point out many bugs to you, and does
> not require a recompile. Other than that you may try
> electric fence ("efence"), though this requires a recompile
> and is not as useful as valgrind.


Thank you, I'm downloading it.

> And the obvious way out -- recompile your code with debug
> information on (usually the -g option), run it under a
> debugger (like gdb), let it crash, then backtrace and
> check where the problem occurs. Put tons of debug printouts
> there and hopefully all will become clear.


Yes, I've done... On the cygwin machine (the most accessable for me) it
crashes on the line:

Matrix temp = P.Transpose();

which just allocates and fills a new Matrix with the same dimensions as
caller (just swapped).



Thank you,
Ignazio



 
Reply With Quote
 
Neclepsio
Guest
Posts: n/a
 
      03-09-2007
John Harrison wrote:
> If you can reproduce the problem in a small program then post the code
> here. Plently will be willing to take a look.


I'll try to write it as small as I can.

Thank you,
Ignazio
 
Reply With Quote
 
Neclepsio
Guest
Posts: n/a
 
      03-09-2007
John Harrison wrote:
> std::vector does not prevent you from getting a raw pointer to the data.


So, if new can't allocate the memory, why should std::vector be able to?

Thank you,
Ignazio
 
Reply With Quote
 
Alf P. Steinbach
Guest
Posts: n/a
 
      03-09-2007
* Neclepsio:
> John Harrison wrote:
>> std::vector does not prevent you from getting a raw pointer to the data.

>
> So, if new can't allocate the memory, why should std::vector be able to?


The std::vector code is more likely to be correct.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Allocating vector of strings seem to crash. Allocating array ofstrings seems to be ok . Rakesh Kumar C++ 5 12-21-2007 10:42 AM
segmenatation fault while allocating memory Sameer C++ 2 11-03-2003 09:24 AM
allocating memory for std::string? Axel C++ 1 10-27-2003 12:35 PM
basic allocating memory question soni29 C++ 6 09-05-2003 05:45 PM
Pushing memory allocating objects into a vector. hall C++ 4 08-20-2003 09:24 PM



Advertisments