forums.silverfrost.com

[KL]

Paul,

I have a severe problem with the Silverfrost Win32 Debugger. I am running a very large code with a specific data case. Using just the compiler with standard options gives correct results. However, when using

/checkmate /Full_Debug

the code crashes with the error message

�Error 429, Internal Error: stack pointer corrupt�

I have tried for days to find an error but I could only localize, that obviously �according to the debugger message- an error occurs in an internal subroutine consisting of a single line

dx (1:n) = - MatMul ( B_m1 (1:n, 1:n), F_new (1:n) )

(see the full subroutine below). The two arrays used as input to matmul are defined by the hosting subroutine, where they are dummy arguments. In fact they are array sections defined by the calling subroutine. The bounds reported by the debugger are B_m1 (3919408,356) and F_new (1:92861985) instead of the correct bounds (1:40,1:40) and (1:40), respectively. The elements are � again according to the debugger- either marked as �defined�, as �undefined� or as �Illegal pointer�. None of the numbers reported are correct. The resulting dx is completely wrong.

I have tried to check this internal subprogram by additional output:

[Robert]

Does your program crash in the same place without using the debugger? In other words does just using the debugger change the behaviour of your program?

[KL]

Robert, without the debugger the program does not crash and gives correct results. Klaus

[PaulLaidler]

I have noticed that the debugger sometimes shows incorrect array bounds. This may not be the fault of the debugger itself but incorrect or insufficient data being passed to the debugger. Also I think that some recent fixes may have reduced the occurence of this type of error.

The problem here seems to relate to a change in the internal assembly code between the different debugging modes.

A work around would be to compile the part that causes problems within a separate file or routine that does not use the debugging options and to use the debugger and debugging options only in those parts of the code that work OK.

I could investigate the specific problem given a short working program and data to go with it. That is, a short program that illustrates the fault.

[Robert]

So, are you saying that '�Error 429, Internal Error: stack pointer corrupt�' is coming out of the debugger itself? sdbg does not change anything in the program being executed - at least as far as it would make any difference.

[KL]

From the additional output it seems that the array bounds are correct but are not correctly reported by the debugger. This could indicate a problem with the debugger.

As I said already, I have looked for days for uncorrect formulations and especially for side effects but I could not find anything. Normally I test sub-problems within a special test environment and this has been done here also extensively.

During the last days I have followed various routes of bracketing the source of the error. One was to carefully check all array sections and how they are passed to subroutines. Up to now I was unable to construct any case where an array section, passed to a subroutine, was not treated correctly in the subroutine. Fortunately!

Paul, you say that the previous debugger version could give incorrect array bounds (probably only in very specific situations). Could it be possible that the crash and the corresponding error message was the result of incorrect array bounds known to the debugger? This is only a question for ruling out a specific possibility and does not mean that I exclude a complicated or even trivial error somewhere in my code! I consider this of course still is a likely possibility.

In this context I have another question: is it possible that overloading causes a problem for the debugger? Actually, in the present case I overload the intrinsic function matmul by a module procedures for some specific reasons with 3 own double precision functions. Again, I could not manage to write a test case showing any problems.

I will be in holiday for about two weeks and will then continue with the analysis of this problem. One question to the specialists: Is it possible to find more out by a detailed analysis of what the debugger gives in the case of a crash? I cannot understand anything of the crytic output but I could send a detailed screen shot as a *.doc file.

Paul, you write that you have managed to improve the debugger for some known problems. When could you make this version available?

Best regards,

Klaus

[PaulLaidler]

In short, the debugger does not always work even when the code is valid syntacticlly and logically. This is usually not the fault of the debugger itself but rather because of a small number of remaining bugs in the internal debugging code provided by the compiler. These can only be found and fixed on the basis of customer reports and sample programs.

Incorrect array bounds reported to the debugger might cause it to crash in some situations.

The fixes in this context are already in the current release. To my knowledge no changes have been made in the mean time that would affect this.

[JohnCampbell]

Klaus,

Try removing "-" from the intrinsic function.

dx(1:n) = MatMul ( B_m1(1:n, 1:n), F_new(1:n) )
dx(1:n) = - dx(1:n)

There was a problem with - before and this may be a repeat that problem.
I don't recall if it was limited to the Debugger.

If that doen't work, replace MatMul with a DO loop and see if the problem disappears.

[KL]

Thank you John! I will try your first proposal after my holiday. Concerning your second proposal I would argue that there are several other possibilities to circumvent the problem. However, the problem should not arise and I would like to contribute to find out why. Unfortunately I was -up to now- not able to show the specific problematic in a small code. The only thing I found is a strange (may be meaningless) compiler warning for the following subroutine. The warning is

[JohnCampbell]

Klaus,

I think I see where you are going with this.
My preference is for a simpler approach, such as:

[KL]

Paul,

I had a further look to the problem and managed to produce a little test program that demonstrates the effect. However, before giving further details I must admit that in the program I submitted on February 9th, there is an error which explains the �strange� compiler message: There must be no interface! I believed (wrongly) that an interface even for an internal subroutine would not harm.

After bracketing the error for further days I came to the conclusion that this error has nothing to do with overloading but simply with a function, which in my case performs a matrix multiplication. (One word to John Campbell: please do not send further suggestions for improvements. This is just a test program.)

Writing a subroutine instead of the function solves the problem, which clearly indicates that the error has something to do with the function.

Here are the programs:

Main Program:

[KL]

I have checked my contribution and the preview was OK. However something was cancelled. I try to send the rest:


Batch file:

[KL]

Paul,

did you find the time to reproduce the error message, or do you see something in my code that worries you?

Klaus

[PaulLaidler]

I have had a quick look at this and my first impression is that the compiler is not able to handle the matrix assignment when using /checkmate.

This means that the compiler code that provides the undef checking is wrong on this line (line 12 of the subroutine suba)

So if you get the correct results using /checkmate for the main program and /check for the subroutine then all well and good.

In the mean time I will note this as a bug to fix.

[KL]

Paul,

thank you very much. I can continue this thread (if necessary at all) only mid of March.

Klaus