c++ vector ::size() nonzero before putting anything in the vector - ?!
I'm a n00b when it comes to c++, sorry if I did something dumb.
I have a vector Code:
class QOCC_DECLSPEC QoccApplication : public QApplication Code:
cout<<"argc "<<argc<<endl; Code:
cout<<"plugins: " << activePlugins.size() << endl; Code:
argc 1 I can fix this by uncommenting the line in green - but I thought that C++ initialized variables automatically. Am I expected to clear the vector, or not? I'm using Debian Lenny on AMD64, and GCC 4.2.2. Thanks |
No; the problem is somewhere else. Please post your backtrace.
ta0kira |
$ gdb ./debug/qOcc
GNU gdb 6.7.1-debian Copyright (C) 2007 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu"... Using host libthread_db library "/lib/libthread_db.so.1". (gdb) r Starting program: /home/mark/projects/occ-other/qtOccHarness-0.1/debug/qOcc [Thread debugging using libthread_db enabled] [New Thread 0x7f83977147c0 (LWP 11639)] argc 1 plugins: 1013170 Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7f83977147c0 (LWP 11639)] 0x000000000041677a in QoccApplication::registerPlugins (this=0x7fff9f86c8c0) at src/qoccapplication.cpp:77 warning: Source file is more recent than executable. 77 if(!activePlugins[p]->load()) (gdb) bt #0 0x000000000041677a in QoccApplication::registerPlugins (this=0x7fff9f86c8c0) at src/qoccapplication.cpp:77 #1 0x00000000004160e0 in main (argc=1, argv=0x7fff9f86c9d8) at src/main.cpp:37 (gdb) The source file warning is because I uncommented the line that clears the vector. |
$ grep -n activePlugins src/qoccapplication.cpp
56: activePlugins.clear(); 62: activePlugins.push_back(new QPluginLoader(pList.at(i))); 66: activePlugins.push_back(new QPluginLoader(pluginPath)); 75: cout<<"plugins: " << activePlugins.size() << endl; 76: for(uint p=0;p<activePlugins.size();p++){ 77: if(!activePlugins[p]->load()) 78: cout<<"Plugin "<<activePlugins[p]->fileName().toStdString()<<" failed to load. Continuing anyway."<<endl; $ grep -n activePlugins inc/qoccapplication.h 56: std::vector<QPluginLoader*> activePlugins; These are the only lines where activePlugins is used. |
There is not enough information to help you.
I think problem might be located at line 62 ("activePlugins.push_back(new QPluginLoader(pList.at(i)));") which isn't provided. Either give full function listings, or check size of activePlugins (print it to stdout/stderr) before and after parsing argc/argv, and especially around mysterious "doSomeStuff()" call. |
Quote:
Code:
void QoccApplication::checkArgs(int &argc, char **argv){ |
OK, something wierd is going on. I made it print the vector size when it prints argc. At that point it is zero. Because argc is 1, everything in the if() gets skipped.
argc 1 plugins: 0 plugins: 1013170 checkArgs() is called when the program loads. The function where the seg fault occurs, registerPlugins(), is called after the gui has initialized. Code:
int main(int argc, char *argv[]) Code:
QoccApplication::QoccApplication(int &argc, char **argv, int _internal ) : |
OK, shows how much of a newb I am, would it make a difference if I changed
Code:
QoccApplication app( argc, argv ); Code:
QoccApplication app = new QoccApplication( argc, argv ); I'm modifying an old version of someone else's code (http://qtocc.sourceforge.net/). What are the implications of using the second line in place of the first (if that's not too difficult to explain)? Thanks map250r |
You should try to debug your program with "gdb"(or another debugger), in step-by-step mode, but you'll have to find/read some tutorials about debugging if you are a newbie. advancedlinuxprogramming.com should explain debugging on linux. If haven't done this before, then you'll need some time to get used to gdb.
Right now I don't see what causes this problem. Is this a complete implementation of "registerPlugins()":? Code:
cout<<"plugins: " << activePlugins.size() << endl; Anyway, right now debugging program is your best bet. To my opinion, at least. And this: Quote:
|
One serious problem in your code:
Quote:
Doing something similar in other places might be cause of your problem. |
Quote:
I have changed to a static cast, but have yet to compile it. |
I don't see the error in any of the code you have posted. What you have described hints at a couple possibilities:
1) The QoccApplication destructor is being called on that object and then you continue to use it, causing the seg fault. 2) The seg fault occurs on a different QoccApplication object. I couldn't tell if anyone answered your original question unambiguously: You are not required to clear the vector. The constructor for the vector clears it and that constructor is called automatically by the constructor for the containing class even if you don't do that explicitly. I don't really trust gdb in C++ code, so I would use some cout's to investigate the two ideas I mentioned above. You could do the same with breakpoints more quickly if you trust gdb. In each of the following places show the value of the current QoccApplication pointer ("this" if you are in a method of that class): QoccApplication constructor QoccApplication destructor The place you were checking argc The place right before the seg fault. Those should tell you whether it is all the same object or not and it should tell you if the construction or destruction is occurring out of correct sequence. |
Quote:
Quote:
QoccApplication *app = ... but this could not make a difference? gcc didn't like the static_casts, so I just put 0 in place of (QWidget *)this in both places. |
Ugggh. I'm leaning towards stale .o files causing this.
I tried to debug from kDevelop. It complained that it couldn't find the program, even after a clean build (errrm, "Rebuild Project"). I selected "debug" in QMake Manager and did a clean build. Tried to debug again, and now the program works. I imported this project into kdevelop, and kdevelop had trouble parsing the .pro file IIRC. I get .o files all over the place, and now I'm wondering if it's been using a stale one. I have been using "Rebuild Project" instead of "Build Project", thinking that rebuild would delete any .o files, but now I wonder if it might only delete .o files where it expected to find them, then for some reason link against one elsewhere. How likely is that? Thanks for the help. |
Quote:
I still don't get why the problem went way earlier, when I had the clear() line uncommented... Thanks map250r |
All times are GMT -5. The time now is 05:53 PM. |