21 users logged in
Proud partner of GDC 2025
Before posting, review our community guidelines.
Support GameDev.net with a monthly GDNet+ subscription!
Problem using vector in linux.
July 16, 2004 10:55 AM
I'm writing a cross-platform app using SDL and I'm havine an interesting problem. Under windows the app runs fine, but under linux it crashes almost instantly. I've traced the problem back and this code is what is causing the problem: fprintf(fp1, "%d ", vImages[nWorldGrid[j]]); vImages is an STL vector, nWorldGrid is a 2D array full of ints. The code still crashed if I use 0 as the index rather than what is in nWorldGrid. I know that vImages has data in it and can't figure out what it is crashing under linux and not windows.
"The paths of glory lead but to the grave." - Thomas GrayMy Stupid BlogMy Online Photo Gallery
1,658
July 16, 2004 11:16 AM
Have you examined your core dump? Is fp1 valid? What is vImages a vector of?
One line taken in isolation will not help find the problem. Can you turn that into a minimal example that will compile, while still crashing?
One line taken in isolation will not help find the problem. Can you turn that into a minimal example that will compile, while still crashing?
"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." — Brian W. Kernighan
145
July 16, 2004 11:53 AM
Make sure the indexes i and j aren't out of bounds
July 16, 2004 01:03 PM
If I were to turn this into an example that can compile then it wouldn't really match my situation. The function is pretty deep in my game code and can't easily be seperated and still work.
fp1 is a valid FILE *, but it doesn't matter because if I comment out that line and replace it with this one:
sdl->surface_manager.CopyTo(vImages[nWorldGrid[j]], 0, (j-xstart)*16-xdrawstart, (i-ystart)*16-ydrawstart);
I get the same error.
i and j are not out of bounds, they are well withing the acceptable values.
This is the code that inits everything and sets up the vector.
fp1 is a valid FILE *, but it doesn't matter because if I comment out that line and replace it with this one:
sdl->surface_manager.CopyTo(vImages[nWorldGrid[j]], 0, (j-xstart)*16-xdrawstart, (i-ystart)*16-ydrawstart);
I get the same error.
i and j are not out of bounds, they are well withing the acceptable values.
This is the code that inits everything and sets up the vector.
void CWorld::initWorld(char *sWorldFile){ FILE *fp = fopen(sWorldFile, "r"); FILE *fp1 = fopen(".//debug.txt", "w"); char sTemp[256] = " "; fscanf(fp, "%d %d", &nWorldWidth, &nWorldHeight); fread(&sTemp[255], 1, 1, fp); //for the newline while(sTemp[0] != '\n') { for(int i=0; (int)sTemp[i-1] != 10; i++) { fread(&sTemp, 1, sizeof(char), fp); if(sTemp == '\n' && i != 0) { sTemp = '\0'; break; } } if(sTemp[0] != '\n') { vImages.push_back(sdl->surface_manager.LoadImage(sTemp)); sdl->surface_manager.ConvertSurface(vImages[vImages.size() - 1]); fprintf(fp1, "%s - %d\n", sTemp, vImages[vImages.size()-1]); memset(sTemp, 0, 255); } } nWorldGrid = new int*[nWorldHeight]; for(int j=0; j < nWorldHeight; j++) { nWorldGrid[j] = new int[nWorldWidth]; } for(int k=0; k < nWorldHeight; k++) { for(int l=0; l < nWorldWidth; l++) { fscanf(fp, "%d", &nWorldGrid[k][l]); fprintf(fp1, "%d ", nWorldGrid[k][l]); } fprintf(fp1, "\n"); } nWorldPixelWidth = nWorldWidth * 16; nWorldPixelHeight = nWorldHeight * 16; fclose(fp); fclose(fp1);}
"The paths of glory lead but to the grave." - Thomas GrayMy Stupid BlogMy Online Photo Gallery
1,658
July 16, 2004 01:32 PM
The copy constructor for the data type (which you haven't revealed) stored in the vector might be messed up, and clobber the vector's bookkeeping structures.
Without knowing anything more, that's the only guess I can make.
Oh, and vImages[vImages.size()-1] can be replaced with vImages.back() [wink]
Without knowing anything more, that's the only guess I can make.
Oh, and vImages[vImages.size()-1] can be replaced with vImages.back() [wink]
"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." — Brian W. Kernighan
193
July 16, 2004 01:37 PM
1) Why use c file i/o if you are using c++?
2) Is vImages a vector of (SDL_Surface *) ?
3) If so, why are you trying to write a surface to a file?
2) Is vImages a vector of (SDL_Surface *) ?
3) If so, why are you trying to write a surface to a file?
--monkey
July 16, 2004 01:40 PM
Sorry, the vector is of type int. I'm writing it to a file so I know what tile it's trying to copy.
"The paths of glory lead but to the grave." - Thomas GrayMy Stupid BlogMy Online Photo Gallery
1,658
July 16, 2004 01:53 PM
Have you tried running your program through a debugger?
Here's how you'd go about doing a postmortem on the crash:
ulimit -c unlimited # core dumping is often disabled by default
./myprogram # run the program
Message --> Segmentation Fault (core dumped)
gdb myprogram core # run the debugger (gdb) over the core dump.
(gdb) bt # backtrace (shows the call stack)
(gdb) up # (or u) goes up one level
(gdb) down # (or d) goes down one level
(gdb) info locals # prints local variables (try info on its own for more options)
(gdb) p expression # prints the value of the expression (variable, etc.)
Here's how you'd go about doing a postmortem on the crash:
ulimit -c unlimited # core dumping is often disabled by default
./myprogram # run the program
Message --> Segmentation Fault (core dumped)
gdb myprogram core # run the debugger (gdb) over the core dump.
(gdb) bt # backtrace (shows the call stack)
(gdb) up # (or u) goes up one level
(gdb) down # (or d) goes down one level
(gdb) info locals # prints local variables (try info on its own for more options)
(gdb) p expression # prints the value of the expression (variable, etc.)
"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." — Brian W. Kernighan
July 16, 2004 02:10 PM
I have been running the programing with strace and gdb (actually kdbg). However for some reason I cant watch the value of vImages.
strace prints a ton of crap that I think is internal SDL stuff, but I don't see anything that would give a clue as to what is crashing.
strace prints a ton of crap that I think is internal SDL stuff, but I don't see anything that would give a clue as to what is crashing.
"The paths of glory lead but to the grave." - Thomas GrayMy Stupid BlogMy Online Photo Gallery
1,692
July 16, 2004 02:11 PM
Don't try to post-mortem debug if you can run the program under the debugger already.
Run the program under the normal debugger until the point it crashes, you can then inspect the stack and see i and j. That should work (provided the memory corruption hasn't trashed the stack).
But don't debug a full-screen exclusive mode program, you might render the console unusable :)
Almost certainly, your program is equally broken in win32, but for some random reason the error doesn't make it crash.
Mark
Run the program under the normal debugger until the point it crashes, you can then inspect the stack and see i and j. That should work (provided the memory corruption hasn't trashed the stack).
But don't debug a full-screen exclusive mode program, you might render the console unusable :)
Almost certainly, your program is equally broken in win32, but for some random reason the error doesn't make it crash.
Mark
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
Recommended Tutorials
Advertisement