0

I have a Visual Studio 2013 C++ text based command line project that consists of:

  • Main file
  • Various Header & Implementation (.cpp) files
  • Uses multithreading
  • Uses the C++ standard library only

The project will run successfully if I run in debug mode from the IDE or if I build and run using the debug executable. Also, I can take the executable out of the debug directory and place it in another directory, and it will still work correctly. However, if I change to a Release build mode, the executable in the Release directory will not work.

The release executable will load a command window and just sit there - No errors, no text. It does not do anything.

I have looked through the project compile settings, and they are identical.

This copy of Visual Studio 2013 C++ is the Ultimate edition that I have acquired via my college. I am a graduate student. I am not asking for the answer to any problem posed to me in a class. This is for the deployment of a project in class.

Any assistance would be appreciated.

EDIT: The expected output is text in a console window.

xeralti
  • 3
  • 3
  • could be related: http://stackoverflow.com/a/15297493/4342498 – NathanOliver Apr 07 '15 at 12:15
  • What is the expected output of the application? Is it console window with some text? If yes, can you show a line of code where you output this text? – demonplus Apr 07 '15 at 12:16
  • 1
    Do you have any global variables whose initialization is non trivial? Could be an initialization order issue. – Eran Apr 07 '15 at 12:17
  • The project that I am trying to build had three processes using double buffers for a real time system simulation. The output is controlled by a queue of strings that the three sub processes can push strings for output. A fourth thread then prints the strings to the screen (to avoid the text mixing between the processes). – xeralti Apr 07 '15 at 12:25
  • I do not have any global variables that all classes have access to. There are some initialized outside of the main method, but they are not accessible to the classes used for the sub processes unless passed in. – xeralti Apr 07 '15 at 12:28
  • 2
    You can attach the debugger to the release build (or better yet - just debug the release build from the get go). Don't remember if the release build keeps debug info by default, but if not that's easy to take care of. Once in, just pause the run and see where's the deadlock. – Eran Apr 07 '15 at 12:31
  • You're probably dealing with the [debug works fine, release fails scenario](http://stackoverflow.com/questions/1762088/common-reasons-for-bugs-in-release-version-not-present-in-debug-mode). Have you tried using a tool like [Visual Lint](https://visualstudiogallery.msdn.microsoft.com/743CC5B0-369C-4150-9F48-5D65D3569BF4) to identify problems in your code? – rrirower Apr 07 '15 at 12:37
  • 1
    It's very common for a debug build to be slow enough to mask concurrency issues, or for a release build to be fast enough to do the same. – molbdnilo Apr 07 '15 at 12:40

1 Answers1

0

The solution to this problem is to verify that all variables are explicitly NULL initialized. Once all pointers were set to NULL, the program compiled and ran in Release mode properly and the executable will run in different locations.

xeralti
  • 3
  • 3