PB 5.72 Under Win 10: Many odd issues

[Tristano]

After updating from 5.71 to 5.72 I've started to experience a number of strange bugs with my project.

Among the problems:

• Code that works fine with Run+Debugger fails to compile with unreasonable "Syntax Error" (both 32-bit and 64-bit)
• Trying to open a non-existing file (using #PB_Any) returns a non-NULL value.

I have the impression that there are some serious underlying issues with this new release, possibly related to the Debugger.
It might just be that the problem is not related to any particular command, but results from some internal memory problems that could affect any part of code.

Anyone experienced similar issues with projects that were working fine before the update?

[kenmo]

Sorry to hear, I am running the 32-bit version on Windows 10 and have not experienced issues yet.

Code that works fine with Run+Debugger fails to compile with unreasonable "Syntax Error" (both 32-bit and 64-bit)

Can you cut it down to a small example code?

Trying to open a non-existing file (using #PB_Any) returns a non-NULL value.

Yikes, that sounds severe. Again, can you find a small example? I just did some simple tests and they worked OK.
You mean ReadFile() correct? Because OpenFile() will create a file if it doesn't exist.

[skywalk]

I have no use for x86 builds, but all my x64 apps work fine in both debugged and release.
Except for the recent SQLite bug which can be worked around by loading our own external sqlite3.dll.

[Tristano]

Sorry to hear, I am running the 32-bit version on Windows 10 and have not experienced issues yet.

This seems to confirm that problem emerges with code complexity, more than the single instructions.

Code that works fine with Run+Debugger fails to compile with unreasonable "Syntax Error" (both 32-bit and 64-bit)

Can you cut it down to a small example code?

No, it's a big project, and one that I can't share its source, unfortunately. I'll try to provide a minimum viable example, if I manage to.
But the fact that code worked with 7.51 suggests issues are due to the update.

Trying to open a non-existing file (using #PB_Any) returns a non-NULL value.

Yikes, that sounds severe. Again, can you find a small example? I just did some simple tests and they worked OK.
You mean ReadFile() correct? Because OpenFile() will create a file if it doesn't exist.

Ah, you're right on that, the handle is for the newly created file. Still, I've experienced various problems with files operations in general, e.g. SaveDebugOutput() failed to write to file, for no apparent reason, but then started working again when I modified the code.

As I said, it seems that there are strange things going on, which I can't pin-point to any specific command but rather to the general context, where things seem to have gone astray.

The fact that I can run a given source (and it works), but I can't compile it due to a "syntax error" seems rather odd to me.
This is a project with various modules, some of which can also be run by themselves (for testing).

Anyhow, I'll do my best to try and pin-point the nature of these errors.

[BarryG]

Code that works fine with Run+Debugger fails to compile with unreasonable "Syntax Error" (both 32-bit and 64-bit)

Why not post the line that gives the Syntax error? Because a syntax error doesn't require us to see anything else in your source except that single line.

[infratec]

If something 'strange' happens at a line which looks fine, then ...

it is always a memory corruption involved.

So I thinke there is a bug somewhere in the code which overides memory.
With the 'old ' compiler the bug was there, but not recognizable.

Use:

Code: Select all

PurifierGranularity(1, 1, 1, 1)

at first code line and enable the Purifier in 'Compile/Start'

[skywalk]

I agree with infratec. When I last had a nasty bug that made no sense for the error line shown, it was due to my procedure consuming too much memory. I had to define some of my large structures in global memory. Then access them via pointers. The specific case was an x86 dll and I have not had similar errors since moving fully to x64 compiles.

[Tristano]

I've got an update regarding one of the reported problems, and it seems that the bug is due to the IDE.

The code before exiting contains a SaveDebugOutput("info.txt") command; after running the code a couple of times it starts reporting an error that it can't save the file, and closing all other apps (including explorer) or restarting the IDE doesn't solve it. I've checked for processes running in the background, but couldn't find anything that might be related. This problem didn't occur with PB 5.71, even though it was run in the same way and context.

But if I switch to using the "Standalone GUI Debugger" the problem is gone — and if I revert to the "Integrated IDE Debugger" the problem is back.
So it looks like there are some issues with the IDE debugger, that weren't there in 5.71.

Regarding the line that prevents compiling the source due to a syntax error, it's more or less like this:

Code: Select all

ElseIf somevar > somval
  Debug ~"some text \""+ somefilename$ +~"\""+ Str(somevar)
  CloseFile(somefilehandle)
  End #ErrorX
EndIf

according to the compiler error, the culprit line should be the one starting with "Debug" — i.e. if the error line reported is correct, since there are multiple include files.
Since running the app doesn't produce any error, I can't get a more precise error report.

If something 'strange' happens at a line which looks fine, then ...

it is always a memory corruption involved.

So I thinke there is a bug somewhere in the code which overides memory.
With the 'old ' compiler the bug was there, but not recognizable.

Use:

Code: Select all

PurifierGranularity(1, 1, 1, 1)

at first code line and enable the Purifier in 'Compile/Start'

This seems an excellent idea, I'll try it. Thanks.

[Tristano]

Regarding the line that prevents compiling the source due to a syntax error, it's more or less like this:

Code: Select all

ElseIf somevar > somval
  Debug ~"some text \""+ somefilename$ +~"\""+ Str(somevar)
  CloseFile(somefilehandle)
  End #ErrorX
EndIf

I've changed the above code to:

Code: Select all

ElseIf somevar > somval
  outstr$ = ~"some text \""+ somefilename$ +~"\""+ Str(somevar)
  Debug outstr$ 
  CloseFile(somefilehandle)
  End #ErrorX
EndIf

and the code compiles without error. It seems like that when the compiler creates the executable, and disregards debugging commands, it's unable to handle the Str(somevar) part as being part of the Debug command — i.e. that the line is not properly skipped in its entirety, but something is left over which leads to a syntax error. Maybe it's due to the escaped strings?

[Marc56us]

[...] Maybe it's due to the escaped strings?

I think so.
Try classic method instead:

Code: Select all

outstr$ = "some text " + #DQUOTE$ + somefilename$ + #DQUOTE$ + Str(somevar)

And for
SaveDebugOutput("info.txt")
I alway prefere to add full path (to avoid possible changecurentdir by other part of program)
i.e
Debug GetTemporaryDirectory() + "info.txt"
or
GetUserDirectory(#PB_Directory_AllUserData) + "info.txt"
This way, you will be sure not to be blocked by acces rights.

[Tristano]

Try classic method instead:

Code: Select all

outstr$ = "some text " + #DQUOTE$ + somefilename$ + #DQUOTE$ + Str(somevar)

And for
SaveDebugOutput("info.txt")
I alway prefere to add full path (to avoid possible changecurentdir by other part of program)
i.e
Debug GetTemporaryDirectory() + "info.txt"
or
GetUserDirectory(#PB_Directory_AllUserData) + "info.txt"
This way, you will be sure not to be blocked by acces rights.

I confirm that by applying the above fixes the problems were solved and now the code runs without error for SaveDebugOutput(GetCurrentDirectory() + "info.txt") — regardless of the debugger settings — and can be compiled without the syntax error showing up any more.

Regarding the SaveDebugOutput() full-path fix, it's very odd since I did test debugging GetCurrentDirectory() before invoking SaveDebugOutput(), and the path was correct (the program didn't change it at all), so it looks like there's a bug in the behavior of SaveDebugOutput() in the IDE Debugger (since it works fine with the Standalone Debugger), which seems to be unable to work out the current working dir.