Jump to content
  • Advertisement
Sign in to follow this  

std::vector size limit?

This topic is 4774 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Well the problem I'm having is this. I have a vector set up that holds references to sprites and particles. I do this so I can calculate collisions between every object in my game. The problem I'm having is I just did some testing and every cycle I add a new reference. It seems to work for a while. Possibly 6-10 seconds. Then it crashes. Gives an SDL segmentation fault. Which leads me to believe I'm reaching a limit or somethin. Anyways, What are yall's thoughts on this? toXic1337

Share this post


Link to post
Share on other sites
Advertisement
I doubt its the vector reaching any limit. The only thing I can think of is, are you storing a pointer to the sprite/particle or making a copy when you place in the vector?

Have you tried commenting out the adding the new referance line out to check if it is the vector that is causing theproblems? I assume you have but if you haven't its worth a try.

Could you post your referance assignment code?

Share this post


Link to post
Share on other sites
All STL containers have a max_size() member function. I expect it'll give a value of 34359738367 ( the usual max of an int on modern x86 ). For a vector<int>, that's 8 GB of data ( assuming 4-byte ints ). It's also enough to push_back() one element once per millisecond for over a year.

In short: I doubt that's the problem.

Share this post


Link to post
Share on other sites
I would expect something along the lines of 2,147,483,648. An integer is limited to 4 billions, on Win32 the upper 2 GB of a process' memory space is used for memory mapping of operating system resources.

Doing collision detection between anything and everything in a vector is not a good idea, as the speed will reduce exponentially to the amount of objects stored in the vector. A vector is probably also the worst choice of an STL container you could have made, since deleting elements from the vector will require it to copy any elements after the deleted one, adding an element to the vector when its size() == capacity() will lead to a copy of every element in the vector being made, then deleting the original elements.

In short, it's probably not the vector's size limit, and due to the delay you're reporting I would suspect a stack overflow of some sorts. Just run in debug mode and look where your debugger puts you when the program crashes.

-Markus-

Share this post


Link to post
Share on other sites
As others have said, exteremly unlikely.

Do a backtrace to find out exactly where you're crashing. If you're using the GNU toolset or similar, here's an example:

panda@industry:~$ echo "void crash( void )
{
int *data = 0;
*data = 4;
}

int main ( int argc , char ** argv )
{
crash();
}
" > buggy.cc

panda@industry:~$ g++ buggy.cc -o buggy
panda@industry:~$ gdb ./buggy
...
(gdb) run
Starting program: /home/panda/buggy

Program received signal SIGSEGV, Segmentation fault.
0x08048394 in crash ()
(gdb) bt
#0 0x08048394 in crash ()
#1 0x080483b1 in main ()
(gdb) quit
The program is running. Exit anyway? (y or n) y
panda@industry:~$ _


We now know the program crashed in crash(), which was called from main. If we want line information, compile the program using -g3:

panda@industry:~$ g++ -g3 buggy.cc -o buggy
panda@industry:~$ gdb ./buggy
...
(gdb) run
Starting program: /home/panda/buggy

Program received signal SIGSEGV, Segmentation fault.
0x08048394 in crash () at buggy.cc:4
4 *data = 4;


At this point we know it crashed on line 4, attempting to assign *data to 4.

(gdb) bt
#0 0x08048394 in crash () at buggy.cc:4
#1 0x080483b1 in main (argc=1, argv=0xbffffdf4) at buggy.cc:9
(gdb) quit
The program is running. Exit anyway? (y or n) y
panda@industry:~$ _


We now also know that crash() was called from main in buggy.cc, line 9.

Share this post


Link to post
Share on other sites
I remember that it actually was a bug in either SGI's or MS's implementation of vector (can't remember which one, cause we were using both), but that was 3 or 4 years ago and was fixed later. I was pushing back a little over a 1000 (prob. 1024) objects and it crashed. The working solution was to use 'reserve'.

Anyway...if you have an up-to-date STL impl. it should not be a problem...

Share this post


Link to post
Share on other sites
Yeah thats what It seems mine is doing. It gets about (what seems like 1000) particles and then it crashes.

Ill check the debugger.

Well, I should probably change the way my vectors work anyway. See, the current setup is as follows:

1) My engine class has a "Sprite" vector setup to handle sprite collisions and updating, etc etc.

2) My particle class has a separate "ParticlePool" setup for particles.

The problem arises out of the separate-ness. I need to check collisions out of the two. So what I was doing is adding sprite information from the particlepool to the "sprite" pool every time a new particle is pushed_back() into the particlepool...

In essence, the particle-sprites weren't getting deleted from the "sprite" vector. I've fixed that but it still crashes. And I think something like this would eat cpu up:


for (std::vector<Sprite*>::iterator i=SpritePool.begin(); i!=SpritePool.end(); i++)
{
for(std::vector<Particle*>::iterator j=ParticlePool.begin(); j!=ParticlePool.end(); j++)
{
//update particles / sprite-particle collision
//kill particles when necessary
}

//update sprites / sprites-sprite collision
//kill sprites when necessary

}



Wouldn't that be terribly inefficient?

Thanks,
toXic1337

[Edited by - toXic1337 on April 25, 2005 7:09:07 AM]

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!