Trouble with CreateThread in release mode

[dboggs]

I have been using a program that incorporates code from an old CVF Samples program, PeakApp3, that uses a 2nd thread initiated with this:

MODULE PEEKAPP_myversion
USE DFMT
:
CONTAINS
SUBROUTINE PeekStart
:
ThreadHandle = CreateThread (0,0,GetCharProc,%loc(unit,Create_suspended, thread_id)
:

It has been working fine, but I had always limited it to Debug build. When I try a release build, I get a compile error#6284 "There is no matching specific function for this generic function reference [CREATETHREAD]. There is also "error #7002 Error in opening the compiled module file. Check INCLUDE paths. [PEEKAPP_myversion]", but I had cured this (at least in Debug mode) by including the module .f90 file as part of the project in VS.

Why does this cause trouble in Release but not in Debug?

This is a Quickwin project, and the runtime library is /libs:qwin in both modes. Is the problem somehow related to single-thread vs. multi-thread libraries?

[IanH]

Have a close look at the compile options that result for the two configurations (e.g. right click on the source file name in the solution explorer, select Properties, then have a look at the "All Options" listed under Configuration Properties > Fortran > Command Line).  Make sure that there isn't a compiler option selected in the debug configuration that hasn't been also selected in the release configuration.  You may have changed a property in the debug build from the default, and forgotten to make the equivalent change in the release configuration.

[dboggs]

Thanks Ian. Actually most of the options are different, but I think by design (traceback, warnings, bounds checking etc. enabled in Debug. The debug options are

/nologo /debug:full /Od /fpscomp:ioformat /warn:noalignments /warn:interfaces /module:"Debug\\" /object:"Debug\\" /Fd"Debug\vc100.pdb" /traceback /check:bounds /libs:qwin /c

In release mode:

/nologo /O2 /fpscomp:ioformat /module:"Release\\" /object:"Release\\" /Fd"Release\vc100.pdb" /libs:qwin /c

In the process of experimenting I learned that the problem is not always the compile errors I described. Sometimes, the project will build OK but not run, giving an access violation error 157 (dreaded thing). This seems to be the more common problem, in both Debug and Release. Also, in Release I changed the optimization level to disable (i.e. /O1), but it made no difference.

[Paul_Curtis]

CreateThread() has a well-documented memory leak.  You should $beginthreadex() instead:

threads(i)%handle  = $beginthreadex (NULL,	& ! security descriptor
	                             0,		& ! initial stack size
	                             ProcLoc,	& ! ptr to thread function
	                             i,         & ! single datum or data ptr 
	                             0,		& ! creation flag -- start immediately
				     threadId)    ! returned thread identifier

[dboggs]

I have it running now, but I'm not completely sure why. It seems to be some sort of inconsistency between debug and release versions of the application code, the static library code, the module compiled .obj code, and the module .mod file. Many things to keep track of, and I frequently have trouble with this.

The general means I have established to deal with user-distributed subs and modules is:

I make two versions of the library: Mylib.dbg.lib, Mylib.rel.lib. I put these in a special folder and link my projects to the appropriate one for either a debug or release build.

There are several modules in the static library project, so building the library creates Mymod.obj, contained in either of these libraries depending on the build type. In this way the compiled module file obj becomes available to the project via the library linking.

The (possible) problem that I don't have a good handle on is how to handle the redistributable module .mod files. I did not realize until recently that building the library results in two versions of the .mod files--one in the \debug folder and one in the \release folder. Are these different? Do I need to keep track of them? My practice so far has been to take EITHER ONE of these (but not both, as they have the same name), put it in a special folder, and make it available to the project via an "Additional Include Directory" in VS. This can accidentally result in a debug .mod file to be combined with a release .obj module file in a release build of the project. Is this destined to cause trouble?

Do I need to maintain two different folders for redistributable module files, say \Mymods_dbg and \Mymods_re, and specify the appropriate one as an additional include directory for a debug or release project build? Maybe this could explain a number of strange behaviors!

[IanH]

I can't think of any particular reason with those options for a problem to arise, but as a general principle I think distributing/using the same pair of object code and module files as generated by a particular compiler invocation to be the safest idea.

[dboggs]

Thanks Ian.

For the record, I can now report that the problem has been found to be an incorrect setting for the /SUBSYSTEM switch in the project linker settings. I will report fully in another thread more closely devoted to the error 157 Access Violation.