The unknown dangerous Procedure StringFunction Bug

[Saki]

I would like to show you an old unknown and very dangerous bug.

It's amazing, if you haven't seen it, you won't believe it.

What I write now refers to my own experience with it,
I neither insist that it is right nor that it is wrong.

The bug cannot be reproduced with a small demo code.
It exists for a long time, how long I don't know.
When codes get bigger it can appear suddenly, in all OS.

When a string function is executed in a procedure it can occur.
Badly, it also occurs in Val(), which causes values to be extremely corrupted, resulting in
which leads to malfunctions and crashes.

With Val() it looks like this
that everything is interpreted as a number until two zeros in memory terminate it.

Hard or factually not localizable crashes with large or very large codes,
which suddenly arise during development are signs of this.

Here it happens only on macOS and only on this code.
Note that not only the text but also the white color is gone, there will be overwrites !
So more than one parameter is damaged by the bug, that can really pop.
This can lead to inexplicable crashes, which can drive you to sheer despair if they do not know about it.
The behavior can be reproduced on any Mac.
But as said, this bug is primary not Mac specific !


If you create a small demo code the bug is gone

Code: Select all

Procedure.s test(canvas_ID, ; output_ID
                 text$,     ; Font$
                 a,         ; font_flag
                 b,         ; output_x
                 c,         ; output_y
                 d,         ; output_width
                 e,         ; output_height
                 f,         ; text_color
                 g,         ; text_adjustment
                 h,         ; background_color -1 = invisible
                 text1$,    ; text$
                 i,         ; padding_x
                 j,         ; padding_y
                 k)         ; resize_factor.f
  ProcedureReturn text1$
EndProcedure

x=10
Debug Test(0,      ; output_ID
           "",     ; Font$
           0,      ; font_flag
           0,      ; output_x
           0,      ; output_y
           0,      ; output_width
           0,      ; output_height
           0,      ; text_color
           0,      ; text_adjustment
           0,      ; background_color -1 = invisible
           Str(x), ; text$
           0,      ; padding_x
           0,      ; padding_y
           0)      ; resize_factor.f

OK


Fail

[Mijikai]

I dont think its a PB bug.
The code of the functions doesnt change just because your code gets bigger.

[Saki]

Hi,
well, it doesn't just apply to this (small) project.
I just noticed it here again and wanted to document it once, since no one can believes it.
I've had this error with all sorts of different codes, PC and PB Versions.
And the codes are simple, they have no special features whatsoever.
The first time it took me months to locate the error in a very large code.
There seems to be an increasing number of overwrites.
I don't know, if you have a Mac you can try it.
It also happens in other code for Windows.
There is absolutely no way to pinpoint exactly what is triggering it and when it occurs.

As soon as I make the codes small, it is gone at some point.

As a matter of principle, I no longer use string functions in procedure parameters and good is !
Once again, I hadn't thought of this and it promptly went bang again.

When I read that people can't finish their very large projects because they suddenly have
inexplicable crashes or malfunctions, this is the first thing I think of.

I can't look in to see what's happening, that's the problem.

[Olli]

What I can see, it's :

- a text
- an blurred image "alpha"
- a sentence
- a code extract
- the word "OK"
- an other blurred image "beta"
- the word "Fail"
- an other blurred image "gamma"


1) Do not use the debugger. With the time, the debugger it is you...

2) Explain exactly the sentence << If you create a small demo code the bug is gone >>. I do not understand this sentence : does the bug occur if you create a small code ?

3) Tell us if you use EnableExplicit. If no, so do not try to make a big work, and do not try to share a big work...


4) Tell us if you are on 32 bits or on 64 bits in your program (sizeOf(Integer) value = 4 or 8 ??)

4.1) This will allow us to create a small ASM macro to look after the CPU stack...
4.2) I feel you are on 32 bits and you are nesting a 32 bits variable in a 64 bits parameter... (the reason for the using of enableexplicit)

Thank you

[Saki]

Hi,
well, my Mac runs BigSur.
But the error here was also confirmed on a ten-year-old Mac.
I know that i should use EnableExplicit and a Debugger.
X64, for a long time.
The first software in which it occurred was x86/x64, as far as I can remember.
As I wrote above, this bug cannot be replicated in a mini code
Here in the Mac code, it made sense to document this with a Gif, as the misbehaviour is graphically visible and does not cause a suspicious crash.

3) Tell us if you use EnableExplicit. If no, so do not try to make a big work, and do not try to share a big work...

I really don't know how to self code this error, how do you want to overwrite this two function parameters ?

It would still be interesting to know whats happens.

[BarryG]

The GIF animation in the first post clearly shows some sort of bug, because it shows that replacing the variable "text$" with "Str(i)" will make the boxes no longer show the number that "i" is. I agree some sort of weird bug exists, based on that.

[NicTheQuick]

Is this error also reproducable if you write this as the parameter?

Code: Select all

"" + Str(i)

I can only image that there is a small difference when you pass a string variable to a function and when you pass an other string function as a parameter. In both cases the function usually expects a pointer to a string. Maybe that resulting string of Str() is corrupt or its memory was already freed before and so a dangling pointer gets passed to the function.

Also, if I remember right, the calling convention is depending on the number of parameters. Don't quote me on that.

[Saki]

Hi,

I have moved the string parameter up once and tried the addition ""+Str(i) and other.
The result is the same, but now the box height parameter is overwritten.
If there was a critical value there, it would already go bang.
It still depends on what it is, whether the debugger reports it or not.



MiniCode Test All OK

Now imagine you start your program like this.
Now your code gets bigger and bigger and eventually
it bangs without the debugger reporting it.
You will turn green and yellow in the face trying to locate the error.
The idea that it's the first function you wrote in, say, 50,000 lines of code that triggers the bug, that's what you have to have first.

Now one proceeds then in such a way that one begins to reduce the code, until the bug is away.
So you start to remove the last 500 lines.
Hooray, the bug is gone.
So it goes up and down, until the time and the nerves are at the end.

[Paul]

Why don't you but a Debug Str(i) right before you call DrawText_FW to see if the proper value is being sent?
And then put a Debug in the first line of the DrawText_FW procedure to see if the same value arrives in your procedure?

[Saki]

Everything already tried Paul, up and down.
It is not one parameter, a second one is also broken, so it is sure that it happens in the procedure.
As I said, this bug almost drove me crazy.

The problem was always that I could never reproduce it with a mini code.
I could never define what the cause is.

After all, i sometimes overlook things.
Or makes very stupid mistakes.
But I have a lot of experience, so it happens to me not so often, or I find the cause and can eliminate it.

[BarryG]

Saki, you haven't got a macro named Str() by mistake, maybe? To override the default Str() function?

[Saki]

Hi BarryG
No, it is a very simple structured code.
I always try to do it as simple as possible,
otherwise I self have quickly problems even after months to create a fix if it should be necessary.

It is a demo code of the FontWizzard_BF module.
The module is only about 2000 loosely structured lines in size.

You can find it, well, it's just included in the GFX_Wizzard_BF download archive because it's too big for the forum.
FontWizzard_BF_Formatted_List_Demo_1.pb

There are other codes for Windows, with this bug.
But I fixed those like the example above.
I have to look which ones they were, I know two more or less i can find again.

[TI-994A]

...cannot be reproduced with a small demo code...

...crashes with large or very large codes...

As stated, the error cannot be reproduced, occurring mostly in larger code. Font_Wizzard_BF is quite a substantial module and it would be quite difficult to trace the offending code.

Nevertheless, it's usually not good coding practice to pass functions as parameters to other functions. The error in question is resolved by passing the result of the Str() function, instead of the function itself:

Code: Select all

text$ = Str(10)  
DrawText_FW(canvas_ID, ... , text$, ... )

[NicTheQuick]

Nevertheless, it's usually not good coding practice to pass functions as parameters to other functions. The error in question is resolved by passing the result of the Str() function, instead of the function itself:

I don't think that this is a valid argument. There should be absolute no difference between using Str() directly or first store its return value in a variable. The compiler has to make it work in the exact same way. Your statement "it's usually not good coding practice to pass functions as parameters to other functions" seems random to me.

[Saki]

TI-994A
Yes, I've been doing it that way for a long time now, too.
Nevertheless, something is overwritten, it should not matter whether the code is large or small.
But I can't look inside.
The primary problem is that many people use this because it is convenient and it works 99.9% of the time without you noticing anything.
Only if you get the bug at some point, you quickly have a problem if you don't know where to look.
One has then when troubleshooting the impression that the bug runs away from you, it can not be grasped.
When a year of work goes into a software and you suddenly have sporadic crashes that you can't localize, that's the end of fun.