Project forums > Q-Gears
That #@&!! linux segfault is still there ;_;
halkun:
Updated code and still no joy with linux. It still segfaults on the draw command.
Here's my log info on my version of OpenGL
[03:00:37] SDL init begin
[03:00:37] SDL_INIT_VIDEO initialized
[03:00:37] SDL video mode set 640x480, 16 bit SDL_OPENGLBLIT | SDL_HWSURFACE
[03:00:37] Got 32 bpp (8888), 24 depth, 8 stencil
[03:00:37] SDL init complete
[03:00:37] OGL Vendor: Tungsten Graphics, Inc
[03:00:37] OGL Renderer: Mesa DRI Intel(R) 852GM/855GM 20021115 x86/MMX+/SSE2
[03:00:37] OGL Version: 1.2 Mesa 5.0.2
Mind you I'm using the default DRI mesa, which is not thread safe. Is this an issue? What pointers can you give me to track down why (*i) is going into la-la-land after the splash screen is cleared?
--- Code: ---void ScreenManager::Draw()
{
DISPLAY->BeginFrame();
/*
for (int i = 0; i < mScreens.size(); ++i)
{
mScreens[i]->Draw();
}
*/
for (std::vector<Screen*>::iterator i = mScreens.begin(); i != mScreens.end(); ++i)
{
(*i)->Draw(); //Segfaults here!
}
DISPLAY->EndFrame();
}
--- End code ---
What is *i pointing to? Where did it get it from? I can't trace back becuase I don't know where in the code *i was created and manipulated. Maybe some comments will help. is *I supposed to be the SDL surface? if you ++i, isn't that just moving up one memory address and not a whole structure, (object).. I don't get this.
Also, could you put the increment operater after the variable if it's not critical to have? That just looks wierd.
+++++++++++++
EDIT
+++++++++++++
On closer look it would seem that std::vector<Screen*> is going to lunch. Is there a way to test to see if this is holding a rational value (or *i for that matter) eariler on in the code?
Akari:
--- Quote ---Mind you I'm using the default DRI mesa, which is not thread safe. Is this an issue? What pointers can you give me to track down why (*i) is going into la-la-land after the splash screen is cleared?
--- End quote ---
I dont think that this is a reason, because we use single thread right now.
Try check if (*i) is NULL. If this is a reason (this is the most possible way) then we must understand where it set to NULL.
How Screen classes work.
First, when we create ScreenManager object constructor add SplashScreen to vector of Screens
ScreenSplash* screen = new ScreenSplash();
PushScreen(screen);
This vector is drawing correctly
Next thing happens after we press space. In the input method of SplashScreen we asq screen manager to delete SplashScreen and add new Screen.
SCREENMAN->PopTopScreen();
ScreenDisplayTest* screen = new ScreenDisplayTest();
SCREENMAN->PushScreen(screen);
I dont see any errors here. Pointer to screen just added to vector. It must be creared otherwise it crushed.
PopTopScreen add pointer of SplashScreen to mScreensToDelete vector - vector of screens that should be deleted at the next Update of screenmanager. It also remove pointer from usual screens vector. (Posible error - mScreens.pop_back() doesn't remove pointer)
if (mScreens.size() > 0)
{
mScreensToDelete.push_back(mScreens[mScreens.size() - 1]);
mScreens.pop_back();
}
At the Update we jusr delete all pointers and clear the vector of screens that should be deleted.
for (int i = 0; i < mScreensToDelete.size(); ++i)
{
delete mScreensToDelete;
}
mScreensToDelete.clear();
Thats all. I see only one posible error here, but still don't know why this happened.
--- Quote ---Also, could you put the increment operater after the variable if it's not critical to have? That just looks wierd.
--- End quote ---
I can't and there is reason. postfix increment and decrement orerators create temporary object that should be returned, but prefix operators not, so we all must use prefix operators if there is no reason. Look for example this http://www.devx.com/tips/Tip/12634, this is the first article that I found in google.
Cyberman:
--- Quote from: Akari on 2006-05-10 16:51:14 ---At the Update we jusr delete all pointers and clear the vector of screens that should be deleted.
for (int i = 0; i < mScreensToDelete.size(); ++i)
{
delete mScreensToDelete;
}
mScreensToDelete.clear();
Thats all. I see only one posible error here, but still don't know why this happened.
--- End quote ---
Akari ++i is a possible source of VERY bad things.
What will happen is I will reach mScreensToDelete.size() and I'm POSITIVE that will be a problem :)
Actually this whole bit of code doesn't look right.
I would check the behavior when you delete a screen in mScreensToDelete.
Generally what will happen here (and you should NEVER use a function for the termination this way really), is as it shrinks and I grows you'll end up reaching a point you are deleting things off in Limbo. (another likely source of the error).
A potentially safe way to do this ( it also eliminates an integer variable ;) )
while(mScreensToDelete.size() > 0)
{
delete mScreensToDelete[0];
}
That should delete the first element and shift all the screens unless mScreensToDelete is a semi static array that does not automatically shift everything down one position. At the very least change ++i (which is a preincrement and in this case a definate source for errors) to i++
If this doesn't help.. well DANG! :cry:
Cyb
Akari:
--- Quote from: Cyberman on 2006-05-11 05:13:18 ---Akari ++i is a possible source of VERY bad things.
What will happen is I will reach mScreensToDelete.size() and I'm POSITIVE that will be a problem :)
Actually this whole bit of code doesn't look right.
I would check the behavior when you delete a screen in mScreensToDelete.
Generally what will happen here (and you should NEVER use a function for the termination this way really), is as it shrinks and I grows you'll end up reaching a point you are deleting things off in Limbo. (another likely source of the error).
A potentially safe way to do this ( it also eliminates an integer variable ;) )
while(mScreensToDelete.size() > 0)
{
 delete mScreensToDelete[0];
}
That should delete the first element and shift all the screens unless mScreensToDelete is a semi static array that does not automatically shift everything down one position. At the very least change ++i (which is a preincrement and in this case a definate source for errors) to i++
If this doesn't help.. well DANG! :cry:
Cyb
--- End quote ---
There is three recomended way to handles vector
1) for (int i = 0; i < mScreens.size(); ++i) - array like
2) for (std::vector<Screen*>::iterator i = mScreens.begin(); i != mScreens.end(); ++i) - through iterators (safe way to all standart containers)
3) using algoritms, for example for_each(InputIterator first,InputIterator last, UnaryFunction f);
This won't do anything, just delete first pointer BUT doesn't remove element from std::vector
while(mScreensToDelete.size() > 0)
{
delete mScreensToDelete[0];
}
Read standart library documentation after all!!!
mScreensToDelete.clear(); - is the fastest way to clear vector.
++i and i++ are identical in this case, only difference is i++ creates temporary object and then deletes it but ++i does not. Why do you need temporary object???
First of all read this http://www.sgi.com/tech/stl/
This is vector docs http://www.sgi.com/tech/stl/Vector.html
Cyberman:
First you need to be careful about using some STL objects.
I don't believe all STL objects port well to embeded platforms.
Think PDA's and winPC's.
I'm going to be working on a Palm Cobalt OS port (regular palm OS is not going to be worth it due to platform limitations).
I due believe there is a difference between a post and a preincrement operator there :D
a post increment operator used in a for loop increments after the loop is executed.
a pre increment operator increments BEFORE the loop is executed this may be where the error is coming from.
in psuedo code think of it this way
for(i = 0; i < end; i++)
{ D=0;
}
becomes (Psuedo code wise)
DEF I,EBX
XOR I, I
XOR BL,BL
LOOP:
mov [SI + I],BL
INC I
CMP I, 124
JL LOOP
for(i = 0; i < end; ++i)
{ D=0;
}
becomes (Psuedo code wise)
DEF I,EBX
XOR I, I
XOR BL,BL
LOOP:
INC I
mov [SI + I],BL
CMP I, 124
JL LOOP
These are quite different as I will always be 1 greater if a preincrement operator is used then if a post increment operator is used as it iterates through the array.
Hmmm although probably it won't cause it to have an out of bounds error likely that I was worried about :D
Perhaps using the iterator or the clear() if that allows all objects referenced from the container class to be properly deleted.
The iterator should be safe no matter what. :D
Cyb
Navigation
[0] Message Index
[#] Next page
Go to full version