From: Damon R. <dam...@be...> - 2008-06-28 12:15:04
|
I have been working on a relatively simple gtkmm program that reads info from a configuration key file. The problem I had was that if the file isn't present, the program would crash with "This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information." I tried to use a try-catch but still the program crashes without getting caught. Someone in the gtkmm mail list pointed me to a demo app http://svn.gnome.org/viewvc/glibmm/trunk/examples/keyfile/main.cc?view=markup I tried the example anyway and it worked on my work computer. Later I tried it at home and it crashed so I realized that the work and home PCs are not setup the same. I have another development PC at work so I set it up with msys/MinGW just as I had done at home. The demo app crashed on that one. Now that I have the working and non-working computers side by side, I started trying to figure out why one works and one doesn't. The gtk and gtkmm were identical. As far as I could tell the environment vars were the same. The only thing I could find that is any different is the msys and MinGW setup. On the working and non-working PC I did uname -a, g++ --version and make --version. This is what I got on the working and non-working PC MINGW32_NT-5.1 AER1WB54103V2 1.0.11(0.46/3/2) 2004-04-30 18:55 i686 unknown MINGW32_NT-5.1 C130DEV1 1.0.10(0.46/3/2) 2004-03-15 07:17 i686 unknown g++.exe (GCC) 3.4.2 (mingw-special) g++.exe (GCC) 3.4.5 (mingw-vista special r3) GNU Make version 3.79.1, by Richard Stallman and Roland McGrath. GNU Make version 3.79.1, by Richard Stallman and Roland McGrath. The setup that doesn't work is what I get if I go to the MinGW site, get and install the current version. The working setup was done by someone else at work who had my PC before me more than a year ago. I even tried an experiment where I copied the MinGW folder from the non-working PC to the working PC and my demo app crashes. I also copied the working MinGW to the non-working PC and my demo app works. Can anyone please give me suggestions how to investigate this? I attempted searching the archive but didn't have a lot of luck. Might this be a known bug? Damon Register |
From: Greg C. <gch...@sb...> - 2008-06-28 13:27:15
|
On 2008-06-28 12:13Z, Damon Register wrote: [probable segfault with gtk demo program] > http://svn.gnome.org/viewvc/glibmm/trunk/examples/keyfile/main.cc?view=markup > > I tried the example anyway and it worked on my work > computer. Later I tried it at home and it crashed [...] > The gtk and gtkmm were identical. [...] > g++.exe (GCC) 3.4.2 (mingw-special) > g++.exe (GCC) 3.4.5 (mingw-vista special r3) Are the gtk libraries C, or C++? If you're linking to any C++ library, then the problem may be that it was built with a different compiler version than the library. See: http://mingw.org/MinGWiki/index.php/MixingCompilers Otherwise, you could use 'gdb' to try to figure out where and how it's crashing. It's not uncommon, though, for a segfault to "disappear" when you run in a debugger. If that fails, I would try inserting extra print statements in the demo program that'll tell you where it crashed. For example, I'd insert lines marked with an initial '+' below: int main(int argc, char** argv) { + std::cout << __LINE__ << std::endl; // This example should be executed like so: // ./example the_ini_file.ini Glib::init(); + std::cout << __LINE__ << std::endl; and similarly around each step that could possibly fail. I'd also add "catch(...)" clauses to make sure all C++ exceptions are trapped, not just the anticipated ones. |
From: Damon R. <dam...@be...> - 2008-06-28 14:41:01
|
Greg Chicares wrote: > Are the gtk libraries C, or C++? If you're linking to any C++ They are C++ libraries. > library, then the problem may be that it was built with a > different compiler version than the library. See: Considering the troubles I have had in the past with using a prebuilt C++ library in Borland, I should have thought of that. I am using prebuilt gtkmm, glibmm libraries. Another good reason to not like prebuilt binaries. I will see if I can get the build instructions so I can build them myself. > http://mingw.org/MinGWiki/index.php/MixingCompilers thanks for the link > Otherwise, you could use 'gdb' to try to figure out where and I don't have that > I would try inserting extra print statements in the demo > program that'll tell you where it crashed. For example, I'd I know exactly where it crashes. If you look at http://svn.gnome.org/viewvc/glibmm/trunk/examples/keyfile/main.cc?view=markup it is the first try const bool loaded = keyfile.load_from_file(filepath); If the file does not exist, it is supposed to throw an exception that will be caught. Instead it just dies > and similarly around each step that could possibly fail. > I'd also add "catch(...)" clauses to make sure all C++ > exceptions are trapped, not just the anticipated ones. I tried that but it seems that segfaults aren't caught. It is too late for that I guess. Thanks for helping me with this Damon Register |
From: Damon R. <dam...@be...> - 2008-06-29 22:00:12
|
Damon Register wrote: > Greg Chicares wrote: >> Are the gtk libraries C, or C++? If you're linking to any C++ > They are C++ libraries. I downloaded all the gtkmm components that were contained in the pre-built binary. I found that most built ok with no trouble. One of the glibmm examples didn't compile so I just removed the examples. I was able to build the demo app that had failed before. Now the app runs as expected. Thanks to Greg Chicares. Damon Register |
From: Earnie B. <ea...@us...> - 2008-06-28 14:18:20
|
Quoting Damon Register <dam...@be...>: > > The gtk and gtkmm were identical. As far as I could tell the > environment vars were the same. The only thing I could find that > is any different is the msys and MinGW setup. On the working and > non-working PC I did uname -a, g++ --version and make --version. > This is what I got on the working and non-working PC > > MINGW32_NT-5.1 AER1WB54103V2 1.0.11(0.46/3/2) 2004-04-30 18:55 i686 unknown > MINGW32_NT-5.1 C130DEV1 1.0.10(0.46/3/2) 2004-03-15 07:17 i686 unknown > Which one is the working one? The first line indicates MSYS-1.0.11 is installed. > g++.exe (GCC) 3.4.2 (mingw-special) > g++.exe (GCC) 3.4.5 (mingw-vista special r3) > Are you using a Vista OS? Earnie |
From: Damon R. <dam...@be...> - 2008-06-28 14:31:47
|
Earnie Boyd wrote: >> MINGW32_NT-5.1 AER1WB54103V2 1.0.11(0.46/3/2) 2004-04-30 18:55 i686 unknown >> MINGW32_NT-5.1 C130DEV1 1.0.10(0.46/3/2) 2004-03-15 07:17 i686 unknown >> > > Which one is the working one? The first line indicates MSYS-1.0.11 is > installed. sorry, I guess I didn't make it very clear. the first of each is the working one >> g++.exe (GCC) 3.4.2 (mingw-special) >> g++.exe (GCC) 3.4.5 (mingw-vista special r3) >> > > Are you using a Vista OS? No. They are all XP although I did try on my Vista laptop where it failed just like the XP. The second non-working one is what I get when I download the current MinGW-5.1.4.exe installer and choose "current" when installing. I am a little curious about the mingw-vista but I just assumed that it was built to work with Vista too but was still compatible with XP. Another person just posted that it might be an issue with my C++ libraries being built by a different version. considering problems I have had in the past with C++ libraries and different compilers, I should have thought of that. Damon Register |
From: Tim S <tim...@gm...> - 2008-06-29 00:30:10
|
Damon Register wrote: > > Another person just posted that it might be an issue with my C++ libraries > being built by a different version. considering problems I have had in the > past with C++ libraries and different compilers, I should have thought of > that. > > Damon Register > > Check to make sure no old version of mingwm10.dll runtime DLL is in the path of the non working PC. Tim S |
From: Damon R. <dam...@be...> - 2008-06-29 21:55:32
|
Tim S wrote: > Check to make sure no old version of mingwm10.dll runtime DLL is in the > path of the non working PC. It is difficult to determine if it is old since the dll contains no version info. I see that mingw\bin and cygwin\bin both have the file with 12/27/07 for the date. Damon Register |