Corrupted executable generated.

[Brian Alvarez]

I have a CGI script in PluriBASIC with this code:

Code: [Select]

#COMPILE cgi
'#COMPILER pbwin
#COMPILER OXYGEN
#project "nbson"
#OPTIONS X64 developer localtest
#DIM ALL
#DATABASE closed
#TIMELIMIT 10

#FORM Upload, "upload.html"

FUNCTION PBMAIN() AS LONG

select case getfield("action")
    case "upload"
        stdout "Temporary file is at:<br>"
        stdout cgi.TempName("fileToUpload") & "<br>"
        stdout "<br>"
        stdout "Remote Name:<br>"
        stdout cgi.FileName("fileToUpload") & "<br>"
        stdout "<br>"
        stdout "Extension:<br>"         
        stdout cgi.FileExt("fileToUpload") & "<br>"
        stdout str$(cgi.FileError("fileToUpload")) & "<br>"
        stdout formfield("fileToUpload") ' outputs the whole file contents.
               
        stdout "uploaded"
   
    case else
        call formout(Upload)
   
end select   

END FUNCTION
Which translates to attached source code 1, wich oxygen compiles correctly and runs very well.

When i remark the line:

Code: [Select]

stdout formfield("fileToUpload") ' outputs the whole file contents.
It translates to attached source code 2, which oxygen compiles as a corrupted executable that doesnt run.

[Charles Pegge]

Hi Brian,

Using o2 version 0.2.8, I was able to compile & run version2 without corruption.

However, I noticed you have some arrays dimensioned [ 0 ] while using indexbase 1 by default. This may be the primary cause.

Code: [Select]

'Generated with PluriBASIC 6.0.6.293216

'cp test 12:15 28/09/2019

$ filename "forms.exe"
uses rtl64
%NoConsole
uses console
uses forms.res
indexbase 0
...


[Brian Alvarez]

Those arrays are not used. The engine generates only the positive indexes for used tokens,
and for using them it generates base 1 code.

Anyway, you know best, but the problem occurs since before including token variables. Even
if the array base was the issue, i doubt it would lead to executable not being initialized correctly...
would it? or would it be so consistently intermitent? would adding or reomving random code fix it?
I suspect it is some kind of header alignment issue...

 I updated yesterday, my version is 0.2.3, where do i get 2.3.8?

  Iam attaching the damaged executable so you can examine it if you wish.

[Brian Alvarez]

For comparison sake, here is the correctly generated executable.

[Brian Alvarez]

Charles, i found version 0.2.7, tried to compile the faulty executable and it compiled and worked fine.

 Maybe this issue is fixed in newer versions?... i hope is not that just the alignment changed and it works
fine only in this instance.

[Charles Pegge]

Version 0.2.8 is the current OxygenBasicProgress.zip. The compiled binary is slightly smaller than in your first attachment but it executes ok, as far as I can tell.

Code: [Select]

...
PBMAIN() ' invoke entry point
mbox "ok"


[Brian Alvarez]

 This error occurs only at certain exact alignment... adding or removing statements fix it.
In this case, probably adding mbox "ok" fixed it.

 The updated version also have this error, but changing the RTL's changed the error alignment,
fixing this code for this version, but the bug still exists...

 For an example of it happening (and a chance to fix it), check the version 0.2.3 with the exact
code and resource i posted, this will probably give clues on how to fix it for newer versions.

[Charles Pegge]

Hi Brian,

It's not feasible to regress to 0.2.3 because there are about 50 changes. But if you get further exec failures with 0.2.8 then we will have something to work on. I've not had any so far.

[Brian Alvarez]

 Hello Charles, I completely understand that.

 But with this it will be pointless for others (beside you) to experience this issue.
Even if we report it, for when you have made changes to the code, it will probably be
always too late. What i can suggest is that when you release a new version, keep a separate
folder with the code to it, so that when i find the problem again, you can pull out the code
and look for the error. Finding a fix wont fix the newest version, but you will now know how
to apply a fix to the newest version... That said... i will report any errors with 0.2.8 if i get them,
hoping it is not too late.

 Also, Im not sure i explained myself correctly, when the engine generates a damaged
executable, it wont even be recognized by windows (see image attached or run the damaged executable),
so, adding a new statement to it (mbox "ok") will probably now generate a working executable, giving the false
illusion that there is no problem.

 I do understand there is no easy debugging for this one. As it is not easy to find it. I have found
this problem around 20 times. Every time it takes adding or removing a line of code to "fix it".

 I Usually just keep adding more lines of code until i no longer experience the issue. This works,
but i think at some point a real fix will be required?

Addendum:
 I experienced this problem in Windows 7, and it also happens in Windows 10.

[Charles Pegge]

Yes understood. Such an error is hard to miss   I do see it occasionally, but it has always been due to a detectable and fixable bug.

I will shortly resume development on the graphics and audio projects of o2. These impose the greatest demands on language, complexity and size. These should help to expose any further hidden weaknesses.

[Arnold]

In a few cases I got the same error message like Brian. But it only happened when I ran a compiled 64-bit exe. As I am experimenting with 32-bit and 64-bit at the same time and also create errors in my code, I am not sure if there is a dependence. For instance I used ExitProcess in a code which created the error in 64-bit exe. Using version 0.2.8 and a fresh boot up, this error message does not appear at the moment after compiling.

Would it be helpful to report these occurences? It is perhaps a bit difficult sometimes to reproduce this error message. At the moment I think that this error only occurs in 64-bit mode.

[Charles Pegge]

Yes, that would be very helpful, Roland. I am also lookin for ways of deliberately creating this error.

[Brian Alvarez]

 Thanks Charles, you are awesome.

[Brian Alvarez]

 Hello Charles, i have been a bit disconnected because of side obligations, but, are there news on this?

[Charles Pegge]

Hi Brian,

I have also been diverted over the last 2 months. We need some concise examples that can be analysed, and I don't have any of my own.

However, the next release (0.2.9) will fix a problem with quad function returns in 64bit mode.