B4J Question Debugger jumps over entire blocks of code

Didier9

Well-Known Member
Licensed User
Longtime User
When debugging, the debugger often jumps over entire blocks of code for no apparent reasons, so placing break points becomes an exercise in frustration.
That seems to be particularly true when using Wait For.
It seems that it may be code that is optimized out but not always (in what I am working on right now, it's hard to imagine why the specific section of code would be skipped over since it checks the result of reading a file, which could have changed after the previous run).
Successive debugging of the same code seems to not always jump over the same code, particularly when using incremental compilation (Ctrl-S)

Is there a way to force code execution of all lines of source code (by possibly reducing optimizations), or otherwise identify code that will be skipped over?
 

Didier9

Well-Known Member
Licensed User
Longtime User
Here is an example:

B4X:
    Try
        lstINIFile = File.ReadList( INIDir, INIFile )
    Catch
        'Log( LastException )
        AddText( LastException )
        Return
    End Try
    ' check that ini file not empty
    If lstINIFile.Size = 0 Then
        ToastMessageShow( "Empty or no INIFile", False )
        Return
    End If
    ' look for item name
    For i=0 To lstINIFile.Size-1
        m = lstINIFile.Get(i)
        If m.IndexOf(".") = 0 Then
            ' item name found
            item = m.SubString(1)
            Exit
        End If
    Next
    If m.Length > 0 Then
        ' check unit ID against item name
        If NVPPassthruCmdSelected Then
            m = NVPPassthruCmd
        Else
            m = ""
        End If
        Wait For( CheckUnitID( m )) Complete( success As Boolean )
        If success = False Then Return
    End If

If I put a breakpoint on line 14 "For i=0 To lstINIFile.Size-1", it does not stop there but crashes in the call to CheckUnitID on line 29.
I am sure that I am missing something. Some guidance as to what that may be would be tremendously appreciated.
(Note: don't be confused by the ToastMessageShow() function call, this is B4J, I just made my own ToastMessageShow() )

If I put a breakpoint on line 2 "lstINIFile = File.ReadList( INIDir, INIFile )", it does stop there but them immediately jumps to line 15 "m = lstINIFile.Get(i)"
 
Last edited:
Upvote 0

drgottjr

Expert
Licensed User
Longtime User
i believe there is a problem putting breakpoints
at the "for" statement. you can stop at a particular
point within. it's documented somewhere in
docs.oracle.com.

your implementation of CheckUnitID would be
interesting. also, reported crashes without any
messages make things difficult to assess.
 
Upvote 0

Didier9

Well-Known Member
Licensed User
Longtime User
It's not just the For statement, the following If statement won't break either.
Edit: I mean the program flow should stop on the If statement but it does not.

CheckUnitID compares a text string in a configuration file with the unit ID returned by a serial (or Ethernet) connected device. It is to make sure the right file is used with the device under test. We use the same tool to control a whole bunch of different equipment that uses the same protocol and if the tech uses the wrong file, that can cause some serious malfunction or even damage. It occurs rarely but we have a bunch of new people and it seems like errors occur more often, so the check...

The first part of the code I posted extracts the unit ID from the file (I call it "item"). The CheckUnitID function gets the ID via serial and compares.

Note that the code is broken in multiple places at the moment, the point of debugging precisely is to identify where it's broken and how to best fix it.

It seems like I am having a lot more problems debugging lately than I used to have. Certainly A LOT more problems on B4J than B4A. It may be due to me using Wait For and Sleep a lot more...
 
Upvote 0

Didier9

Well-Known Member
Licensed User
Longtime User
It seems that I should avoid placing break points over the For and If statements. If I put breakpoints just below them, it catches up.
The good news is that there is no limit to the number of breakpoints (apparently), so if that's the fix, I can live with it.

The reason it crashed in CheckUnitID was because that code was buggy, which I knew and was not the issue. The point was that it was going all the way there without stopping on the previous break points.

I have been playing with it for a while, consistently avoiding break points on the For and If statements, and it seems to work reliably.
 
Last edited:
Upvote 0
Top