Breakpoint problem with 8.04 but not with 8.03

[Davide Vecchi]

After installing 8.04 all was going very well, but when I put a breakpoint in a certain part of my program, the execution doesn't stop, as if it was not passing there, but I'm 100% sure it passes there.

That breakpoint was within a SUB which definitely gets called. So, I put another breakpoint just on the call statement; the execution does stop there, then I click on "Step into code" button, expecting to end up into the SUB where the the first breakpoint is. Instead, I end up into a different procedure (which is in a different included file); this is a sure thing, no mistakes.

I tried the same, with the very same source and data files, on a second PC, where I hadn't installed the 8.04 update yet, and the problem doesn't occur (the execution just stops on the breakpoint within the SUB as expected).

Then I uninstalled PB/Win from the first PC, reinstalled it and all the updates, up to 8.03 included, and the problem doesn't occur anymore.

The problem occurred 100% of the times, it's not occasional.

However, whether I run this program in the IDE with or without breakpoints, with 8.03 or 8.04, or I run the EXE, there it doesn't seem to be any difference in the actual execution flow, and the output is always the same; the problem seems to be only with debugging.

My best guess is that there is something wrong in my code, which 8.03 kind of forgives but 8.04 doesn't. Memory corruption or something like that.

I know that if I send all the files to PB they could try to help, but it's not that easy, the code is huge, there are lots of includes, hard-coded absolute paths and third parties libraries.

So, before doing that, I'd like to know if someone has any suggestion as to what could I check or do to try to find what in my program could lead to this.

The program has #DIM ALL and #DEBUG ERROR ON at its top. Being a problem with breakpoints, I don't think #TOOLS related statements may help. For what it's worth, I'm checking ERR very very frequently, and at the time of the call to the SUB where the missed breakpoint is, ERR is 0.

[Gösta H. Lovgren-2]

David,

I am probably out of my league here but I suggest you try opening your own "trace" file and PRINTing to it, before, during and after the call. JIC it is something that's not tripping an ERROR code. I often do that and it works for me.

Psuedo code:

Global TraceFileNum&
Function PBMain:    
  TraceFileNum& = FreeFile
  Open "C:MyTrace.txt" For Output As TraceFileNum&
 
  Print #TraceFileNum, , "Starting at " & Time$ & funcname$
 
  ....
    Print #TraceFileNum, "Calling troublesome in " & FuncName$
  Call Troubled_Call
...
 
 
Sub Troubled_Call
    Print #TraceFileNum, "Entering " & FuncName$
...
    Print #TraceFileNum, "In the middle of " & FuncName$
...
 
   Print #TraceFileNum, "Exiting troublesome in " & FuncName$
End Sub
 
Print #TraceFileNum, "Exited troublesome in " & FuncName$

That way you may be better able to isolate the problem. Sprinkle PRINTs at suspect lines. Just a thought.

[Gösta H. Lovgren-2]

Forgot to add

I forgot to add you should make TWO files so they can be compared if necessary:

Global TraceFileNum&
Function PBMain:    
  TraceFileNum& = FreeFile
 
 local fn$
 'For 8.03 compile
  fn$ =  "C:\MyTrace803.txt" '<== Remmed during 8.04 run
 ' for 8.04 compile
  fn$ = "C:\MyTrace804.txt" '<== Remmed during 8.03 run
 
Open  fn$ For Output As TraceFileNum&
 
 ...

Just another thought.

[Michael Mattias]

'For 8.03 compile
fn$ = "C:\MyTrace803.txt" '<== Remmed during 8.04 run
' for 8.04 compile
fn$ = "C:\MyTrace804.txt" '<== Remmed during 8.03 run

For either compiler without changing code between compiles ....

#IF (%pb_revision AND &hFF) = &h04
    fn$ =  "C:\MyTrace804.txt" 
#ELSEIF (%pb_revision AND &hFF) = &h03
    fn$ =  "C:\MyTrace803.txt" 
#ENDIF
.....

[Davide Vecchi]

Thanks Gösta , I have put the PRINT#s at top and bottom of the involved procedures as suggested, and I got the confirmation that the execution flow is going just like it should: the procedures are entered and exited like the code says.

However the problem with the breakpoint is confirmed as well. I updated to 8.04 the PC where the problem didn't occur, and now it occurs there too.

I tested more, here is what happens with the included files:

In a few words: SubA of A.BAS calls SubB of B.BAS which calls SubC of C.BAS; the execution flow, as documented by the PRINT#s, is correct (SubA to SubB to SubC).
But when the execution was still on the breakpoint in SubA, I went ahead by always clicking "Step into code", so I should have travelled in SubB, instead I went directly from SubA to SubC .

There are the detailed steps, for the records:

- I put a breakpoint in A.BAS, over a CALL SubB .

- The execution correctly stops at that breakpoint.

- I click "Step into code", expecting to enter SubB (which is in B.BAS and contains a CALL SubC).

- Instead, the execution point goes directly at the start of SubC of C.BAS, which actually had been called by SubB . But the execution point never stayed in SubB . It should have stayed in SubB of B.BAS just after the first time I clicked "Step into code" from the breakpoint.

I worked more on trying to figure out what in my code could be causing the problem; it shouldn't be an array out of bounds, because I'm using #DEBUG ERROR ON and ERR is always 0 along the above execution path.
It might be bad pointers, even though the output is always correct, but I couldn't find any possible problem.

For now I'm back to 8.03 on my development PC, and with no hurry I'll try to find something more about this problem on the other PC.

[Gösta H. Lovgren-2]

Thanks Gösta , I have put the PRINT#s at top and bottom of the involved procedures as suggested, and I got the confirmation that the execution flow is going just like it should: the procedures are entered and exited like the code says.

If I am understanding correctly, the problem only occurs if a breakpoint is set in 8.04. if that's so, then why are you setting a breakpoint?

If it is to check a variable or code flow or something like it can be done by sprinkling the code with:

Print #TraceFileNum, using$(" Variable = #.##  ",  Var#) & FuncName$

or something like that. Not trying to be smart but if setting a breakpoint is causing a problem then why not just inform Support there is a problem with Breakpoint in 8.04 and get on with life.

================================================================
"The only way to get rid of a temptation
is to yield to it."
Oscar Wilde (1854-1900)
================================================================

[Davide Vecchi]

If I am understanding correctly, the problem only occurs if a breakpoint is set in 8.04.

Correct.

I'm setting the breakpoint because I need to step through the execution flow to check it.

Not trying to be smart but if setting a breakpoint is causing a problem then why not just inform Support there is a problem with Breakpoint in 8.04 and get on with life.

That's what I'm doing, ecxept for the "inform Support" part because it's hard to pack a useful sample to send them and because I don't want to waste their time for a kind of problem which is usually considered to be caused most of times by application code corrupting memory.