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)

*------------------------------------------------------------------------------

	IMPLICIT NONE

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

	INCLUDE 'MODEL_PRIV.CMN'
	INCLUDE 'MODEL_ERROR.PRM'
	INCLUDE 'FILE_IO.CMN'

*	---------
*	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
	END DO

*	---------------------------------------------------
*	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)

	RETURN
	END

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 帖子 / 0 全新
最新文章
如需更全面地了解编译器优化,请参阅优化注意事项

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"?

Mike

Mike,

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.

James

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.

发表评论

登录添加评论。还不是成员?立即加入