2

I'm using QtCreator with the visual studio 2015 kit on windows 8.1 to build a program I developed and tested on Linux, on linux it works correctly, but on windows it's just crashing immediately, and I have no idea what to look for.

The only external libraries, aside from QT I'm using are opengl and glew, so I don't think it's those.

Is there anything that's known to work in GNU C++ but crash immediately in MSVC?

Patrick Jeeves
  • 371
  • 2
  • 16
  • 1
    Like always, try to reduce something to a smallest reproducible case. One thing that can influence things like this are global variables, their constructors as well as the total size. Depending on the specific case, objects might move from being in data sections, and on the stack. And the stack size might be limited. But, again, try to remove as much as possible to a barebone case and determine whether you still get crashes. Or, hey, start it in the debugger and see exactly what kind of stack trace you get. – cnettel Feb 05 '17 at 20:24
  • 1
    It crashes - ok. But when you run it under MSVC debugger, what's the error message? assertion fault? access violation? missing file (dll, etc)? anything? – quetzalcoatl Feb 05 '17 at 20:26
  • @quetzacoatl It sigsevs, I can't figure out how to link the MSVC debugger to Qt Creator, and if I don't open it from within QtCreator it can't find qt5widgets.dll. I can link QtCreator to the GDB from minGW, but i'm not sure if the symbols are valid in that case. – Patrick Jeeves Feb 05 '17 at 20:37
  • If you're using the pre-built binaries, make sure you're using the ones that match your compiler. The binaries built for Mingw wont' work for MSVC and vice versa. – MrEricSir Feb 05 '17 at 21:31
  • Possible duplicate of [How to debug a crash before main?](https://stackoverflow.com/q/7808769/608639) – jww Apr 23 '19 at 16:52

4 Answers4

2

Usually this kind of crashes have absolutely nothing to do with your program. It's an external library linking issue. I had this issue recently with the OpenSplice DDS library. I linked to a library that caused a segmentation fault before anything started. I resolved the issue by linking the pre-compiled libraries 1-by-1, and check each if that fixes the program.

What I recommend you to do is: Remove the libraries and resources you're linking to gradually, until your program starts and prints "Hello world" from the first line of main().

Another way to go is, make a new empty program, and link the same resources you're using in your program. This is easier, as it doesn't involve modifying your program.

The Quantum Physicist
  • 24,987
  • 19
  • 103
  • 189
  • 3
    "Debug before main(), doesn't exist!" Of course it does. For the debuggers I use at least, you can add breakpoints to code that will be called before main is entered and the debuggers will break on those breakpoints. –  Feb 05 '17 at 20:42
  • @Quant Construction of objects like cout and cin. But there many, many other examples. –  Feb 05 '17 at 20:47
  • I wrapped globals that were used by other global's constructors in functions like std::list & timer_list() { static std::list list; return list; } in the hopes that would control the order of construction, will that actually work? – Patrick Jeeves Feb 05 '17 at 20:51
  • 1
    @PatrickJeeves It's very unlikely that you have a coding error if your code already works in Linux. Also consider using the keyword `-pedantic` in linux to make it paranoid. The only possibility I see other than linking problems, is that you're doing something that's compiler dependent. You get rid of that using `-pedantic`. – The Quantum Physicist Feb 05 '17 at 20:55
  • _See the comments, Neil Butterworth says this is not true, but I haven't seen that before_ <--- This doesn't mean that it doesn't exist. – skypjack Feb 05 '17 at 20:58
  • @skypjack No it doesn't. It means it's still controversial on the level of my answer. I can't confirm it nor deny it. – The Quantum Physicist Feb 05 '17 at 21:01
  • @Quant You could, by reading any good C++ textbook, or the C++ Standard. –  Feb 05 '17 at 21:02
  • @NeilButterworth Or your previous comment, that already contains valid examples. ;-) – skypjack Feb 05 '17 at 21:04
  • I hate arguing like this. I really do. This is a non-mature argument. I'm removing the first sentence to satisfy you. – The Quantum Physicist Feb 05 '17 at 21:05
  • "This is a non-mature argument." No, the statement you made was completely wrong. If you don't like people correcting you, maybe you shouldn't post here? –  Feb 05 '17 at 21:06
  • @TheQuantumPhysicist. just try it yourself. Make a global object of a type having a constructor. Observe. – Greg Kikola Feb 05 '17 at 21:07
  • @Neil Asking to read a C++ textbook is immature. I'm not gonna discuss this further. Please end this discussion if you still think what you did is normal. – The Quantum Physicist Feb 05 '17 at 21:12
2

This is what I would do.

Start by rebuilding the entire solution or project from a clean state. Just in case this is just some weird dependency issue that resulted in something not getting recompiled. Never hurts.

As Neil said in the comments for the question, the crash is possibly coming from a global variable who's constructor runs before main or WinMain. Are you sure you don't have something declared as "static" or at global scope that might have a constructor?

Now do the following:

  • Open Visual Studio.

  • From the menu, select File->Open->Project/Solution...

  • When the file open dialog pops up, select the EXE produced by Qt Creator. (That's right - you are opening the EXE as a project). This directory is typically one folder level above the Qt project (..\build-yourapp-Desktop_Qt_5_7_0_MSVC2015_32bit-Debug\debug)

  • Now press the green arrow to start debugging (menu->Debug->Start Debugging). If all goes well, your program will fail early and

Now chances are high that the program is not going to run at all under Visual Studio because Qt Creator doesn't copy all the Qt*.dll binaries to your build directory. You'll get a bunch of dialogs popping up saying that "The program can't start because Qt5-XYZ.dll can't be found". This is easily fixed by updating your PATH environment in any of the following way to include your Qt5.x.0\5.x\msvc2015\bin folder to your PATH.

  • You add it from the command linke and then re-launch devenv.exe from the command line.

  • You can add it globally from Control Panel->System->Advanced. Then restart Visual Studio from the Windows desktop.

  • With the EXE debug project open from within Visual Studio, just right click on the project name (not parent solution) and a dialog will popup that allows you to edit startup settings. One of which is the Environment.

And that should do it. From there you can start the debugger on your EXE, set breakpoints as needed, and analyze the call stack on crash.

selbie
  • 100,020
  • 15
  • 103
  • 173
0

It's really easy: build all the libraries you use, including Qt, with debug information (those can be release builds as long as the PDB files are generated). Then run your application under a debugger (e.g. F5 under Qt Creator), and it will stop at the point of the crash.

The code that runs before main and is known to cause trouble will be the global object initialization: you're likely running into the static initialization order fiasco.

Community
  • 1
  • 1
Kuba hasn't forgotten Monica
  • 95,931
  • 16
  • 151
  • 313
0

Another cause for the problem could be stackoverflow. In Linux, the stack size by default is usually 8 MB whereas in Windows it's just 1 MB.

Try to link with /STACK:8388608 switch. If it works, you might consider allocating more data on the heap and stay with the default stack size of 1 MB.

imix
  • 1,231
  • 11
  • 13