forums.silverfrost.com

[jjgermis]

The question relates to a common variable defined by means of a module and alocatable variables.

In oder to save time we have several 2D data arrays defined in a module. This means we assign the data once and perform the desired operations. In short we experience the following:

In some subroutines arrays are constructed from the module (or global) data, i.e. one column of a matrix.

When using the debugger the assigned matrix display no valid data (but a print to the screen is correct).

I prepared a small sample code which shows this:

[jjgermis]

Unfortunately I cannot judge whether the above issue is the result of some bad programming by us or some poor behaviour (or bug) from the debugger. However, I did put in some effort to provide a working example which will reproduce what we experience.

I will appreciate an one line comment

[Robert]

Hi

I will take a look at your example. Without really looking ... I would blame the debugger

[JohnCampbell]

I managed to reproduce your example, using FTN95 Ver 5.30.0
While SDBG Ver 5.30 shows T1 as undefined, the write statement gives the correct result. T2 has the correct values displayed in SDBG and also printed.
I can't see any explaination other than the values SDBG has for T1 are not being correctly updated.

I did change T1 to allocatable and that changed the performance of SDBG. Stepping through using F7 shows how SDBG is working or not working. Could it be that SDBG does not like automatic arrays ?

[jjgermis]

I started using the numerical recipes in fortran 90. Here automatic arrays are often used in the code. Even though the results are correct, it is not possible to debug properly (or without printing to the screen). From this I conclude that this must be a bug in SDBG.

Furthermore, I checked FTN95 versions starting from Ver. 4.70. This means that automatic arrays were never correctly updated or displayed by SDBG. Maybe other programmers do such a good job the first time they do not need to bedug - I always do a lot of debugging

Perhaps someone at Silverfrost can comment on this issue.

[Robert]

The problem only happens when the size is passed in and the array has to be allocated from the heap rather than the stack (if it is fixed size). I cannot believe this has not been noticed before.

[JohnCampbell]

Robert,

These are automatic arrays. Maybe few programmers use automatic arrays, as allocate gives a bit more control.

I rarely use SDBG, as (nearly) every time I use it on a new program, it does not display on the screen. I start with "SDBG program.exe" in a cmd.exe box. I then either have to select sdbg from the taskbar, then close it and open again or I think you can delete sdbg.ini from \windows.
It can take a few restarts to get the child windows open in SDBG that I want.
Is there an explaination for this problem or can't sdbg.ini cope with a new program.exe ?

I just tried SDBG with another program and it started up fine, so I'm not sure what causes it to sometimes start and not display the window on the screen. Any ideas ?

John

[Robert]

The sdbg window positions are the same for any debugged program. If you change them that will be reflected in future debugging sessions. In other words the program you are debugging has no effect on the window location. Do you have a current example that causes sdbg to not show its windows? If so can yo run it and then after termination send the sdbg.ini file to ftn95@silverfrost.com so I can take a look at it.

[JohnCampbell]

Robert,
I emailed the .ini files, but the difference appears to be in the coordinates.

I saved then tried the sdbg.ini file on my notebook. The before does not display on my screen, but the one after does.
The "before" one is from the last use in May, and the "ok" one is after saving the file when exiting sdbg.
When starting sdbg for the first time; to get sdbg to display, I select the sdbg logo on the taskbar, then maximise.
This produces a screen with areas that are not updated.
I then exit sdbg, saving the status.
Restarting sdbg then works.

It is off-putting that when I first start SDBG, nothing happens. (This occurs fairly regularly)
I'm not sure why this occurs, being invalid info in the sdbg file or other processes that conflict.
If it is invalid data, I don't remember how it was created, as if I save the status when exiting, it is ok.
May be it is when I don't save the info, but why would it update the file with corrupt info.
I'm at a loss to explain this, although the only obvious change in the files is that the before file has:
Desktop-X=67639555
Desktop-Y=1230127955
while the ok has:
Desktop-X=-4
Desktop-Y=-4

I did try exiting sdbg without saving, and it changed the file to (savepositiononexit=0)
How can the desktop-X in the bad file be apparently so wrong ??
I do sometimes use 2 screens with my notebook (at home), but I don't think I did that with SDBG. The bad file is stamped 1:47pm, which means I probably did not have 2 screens at the time.

Could the fix be to check for invalid locations in the .ini file ?
The before file is:-

[JohnCampbell]

I think that the sdbg.ini file was created when I compiled using:-
ftn95 program /check /lgo
If the program crashes, it goes to the error pop-up, but could also then initialise sdbg, but not via sdbg startup.

[Robert]

I have uploaded a new debugger into http://www.ftn95.co.uk/ftn95/debugger.zip. It fixes the problem with non constant, non allocatable, local arrays. In addition I have added some code to mitigate this strange window placement problem. It detects odd coordinates and reset them -- so at least the window will be visible. Has anyone else seen JohnCampbell's problem where the debugger disappears and the sdbg.ini file has to be deleted?

Robert

[JohnCampbell]

Robert,

I have tested the new version of sdbg, with my corrupt .ini file and the original example of jjgermis and both now work correctly.

thanks for your assistance

John

[jjgermis]

Hi John and Robert,

I successfully tested the new version as well. It works as expected

Thank you!