Brain Bashing Crash!!!

Brain Bashing Crash!!!

Just prior to our release (typically!), we found a crash that only occurred with our release build on NT4. 2K was fine. Debug build was fine. Release build instrumented with BugTrapper was fine. Since we develop on Win2K, we somehow hadn't noticed this until pre-release testing.

So, resorting to ATL trace lines and remote debugging, our senior guys narrowed the 'problem' down to one piece of FORTRAN. It is called from C to set a path in a commmon block variable. Prior to storage an attempt is made to trim NULL characters from the end of the string.

Can anyone spot anything intrinsically wrong with the following code, particularly the WHILE loop that strips NULLs:

	SUBROUTINE set_diagnostic_path(filename)



*	--------
*	Includes
*	--------


*	---------
*	Arguments
*	---------

	CHARACTER	filename*260

*	---------
*	Variables
*	---------

	CHARACTER	dumy_name*(260)
	BYTE		byte_name(260)
	EQUIVALENCE	(dumy_name, byte_name)

	INTEGER*4	iSlashPos, iStrLen

*	--------------------------------------------
*	Cut off gabbages from 'end of string' in C++
*	--------------------------------------------

	dumy_name = filename
	iStrLen = 1
	DO WHILE (byte_name(iStrLen) .NE. 0)
		iStrLen = iStrLen + 1

*	---------------------------------------------------
*	Set the path for Diagnostic files to be the same as
*	the path from which the latest database was loaded.
*	---------------------------------------------------

	iSlashPos = INDEX(filename(1:iStrLen),'', BACK = .TRUE.)

	DiagnosticPath = filename(1:iSlashPos)


I will say that the while loop was cribbed from elsewhere in our FORTRAN code where it has worked without problems since time immemorial. Commenting out the WHILE loop eradicated the crash, as did trimming the string in the C++ layer before calling the FORTRAN (the solution we settled on).

It's fixed, but why it was a problem remains a mystery.

6 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

This may not solve the mystery, but I would definitely separate CHARACTER and filename*260, CHARACTER and dumy_name*(260), and INTEGER*4 and iSlashPos with a space.

Why do you have 260 in parentheses after dumy_name*?

What's a "gabbage"?



They are separated with tabs, the forum hasn't kept the spacing the same way that DevStudio does it.

I don't know why the parentheses :) I cut-n-pasted this code :)

As for gabbages - who knows? The original code was written by (either) one of two of our ex-developers. One was Chinese, the other was Scottish, draw your own conclusions... ;o)

You could do with some extra tests:

(1) the WHILE may not terminate if there is no ASCII-null in the string (ie. may go beyond end of array).

(ii) the INDEX function may return 0 if there is no backslash, and hence the next assignment might fail.

You may prefer to avoid the 'equivalence' and use the INDEX function to look for CHAR(0).

David Jones

I agree with what David said, the DO loop and equivalence are easily and probably more generally avoided here. Anyhow to solve the "mystery" it would help to know what exception you received when you had a the problem. Possible candidates would include being passed a variable of other than the specified size, or not finding a clear byte.


The crash appeared as an access violation in mfc42.dll, but only on NT4. That was why it was so hard to track down. Even on NT4, it didn't always happen. But once you found a database where it did happen, it happened consistently - allowing us to debug.

Leave a Comment

Please sign in to add a comment. Not a member? Join today