Single-stepping advancing by itself

[nfordbscndrd]

On Android 3.1, if I'm single-stepping and stop pressing the buttons for a few minutes, the single-stepper will advance a line by itself at the rate of once per minute when I'm not even touching the device nor the keyboard of my PC.

I have a timer set for once per minute to update the time display in the app, but of course its not executing while I've got the program paused in debug (and the time display is not being updated).

I've been sitting here watching it as I type this, and it's just chugging away, a line per minute.

I assume it's something with Android or the Toshiba Thrive, but I thought I'd mention it anyway. I mean, this isn't a feature of the debugger that I've overlooked, is it? This is with the final 1.6 release, BTW, and I'm using B4A-Bridge. And I still get the problem where sometimes when I press F8, the debugger takes off on its own without going a line at a time.

 

[nfordbscndrd]

With the latest updates, debug is still single-stepping through code by itself at the rate of about 1 line per minute. Here is the unfiltered error log that shows up when it self-steps. It appears to give this same report every time it single-steps:

 

[moster67]

Weird and :sign0142:

...just kidding. Really odd.

I have actually a very similar looking log-report from some Honeycomb-users but of course it is not behaving like in your example.

 

[Erel]

Do you still get this error? I expect the latest update to fix it.

 

[agraham]

I thought only nfordbscndrd had the full fix so far. Moster67 won't have it yet will he?

 

[Erel]

I was actually referring to nfordbscndrd. I wasn't sure whether this error happened with the fix or not.

I plan to release this fix on the forum tomorrow.

 

[nfordbscndrd]

The new jar fixed the problem of debug not stopping on the first breakpoint, but I'm still getting the self-step problem. I'm hoping the log will tell you something since I get the same report every time it self-steps.

 

[Erel]

It seems from the log you posted that you are still using the old B4AShared.jar. The line numbers match the old version and not the new one.

 

[agraham]

you are still using the old B4AShared.jar

I bet that came as a relief when you noticed it Erel!

 

[nfordbscndrd]

It seems from the log you posted that you are still using the old B4AShared.jar. The line numbers match the old version and not the new one.

I just checked the Libraries folder and the old B4AShared.jar was indeed back in there. When I copied the new one in, I still had B4A running, but I didn't get an error message saying that the file was in use. Also, I tried B4A to see if it was skipping the first breakpoint and it wasn't, so I assumed the new jar had fixed that.

Could B4A restored the old file somehow?

Anyway, I closed B4A, copied the file over again, and it appears to have fixed the self-step problem, which is a huge relief since it was hard to debug with that going on. Thanks, Erel.

 

[Erel]

Could B4A restored the old file somehow?

I don't think so.

 

[agraham]

Could B4A restored the old file somehow?

No, but if you are running Vista or Windows 7 they both do (largely undocumented as far as I can see) things behind your back to protect some folder contents, especially Program Files and ProgramData, so that might have been the problem. I've had two applications seeing different versions of the same file in ProgramData because Windows thought that was the "safe" thing to do. It was keeping shadow copies of the file and presenting different ones to different apps. I keep only necessary stuff in Program Files and don't use ProgramData at all now.

 

[nfordbscndrd]

I have a folder off the C: root directory called Programming to make it easier to get to and in that directory I have a folder for B4A and my app folders are in there along with all the B4A folders, including Libraries.

Anyway, I've got a file manager opened to the Libraries folder and the B4AShared.jar on top of the list so that I can watch it for a while.

 

[nfordbscndrd]

Well, I've had B4A running all day and haven't had the problem occur again, nor has the jar file changed back to the old version. I guess that will remain a mystery. I'll just blame it on Win7.