It is currently Mon Apr 12, 2021 4:29 am

All times are UTC + 1 hour




Post new topic Reply to topic  [ 46 posts ]  Go to page 1, 2, 3, 4  Next
Author Message
 Post subject: The unknown dangerous Procedure StringFunction Bug
PostPosted: Sun Feb 14, 2021 11:32 am 
Offline
Enthusiast
Enthusiast
User avatar

Joined: Sun Apr 05, 2020 11:28 am
Posts: 626
Location: Pandora
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 !
Image

If you create a small demo code the bug is gone
Code:
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
Image

Fail
Image

_________________
地球上の平和


Top
 Profile  
Reply with quote  
 Post subject: Re: The unknown dangerous Procedure StringFunction Bug
PostPosted: Sun Feb 14, 2021 11:50 am 
Offline
Addict
Addict
User avatar

Joined: Sun Sep 11, 2016 2:17 pm
Posts: 867
I dont think its a PB bug.
The code of the functions doesnt change just because your code gets bigger.


Top
 Profile  
Reply with quote  
 Post subject: Re: The unknown dangerous Procedure StringFunction Bug
PostPosted: Sun Feb 14, 2021 12:19 pm 
Offline
Enthusiast
Enthusiast
User avatar

Joined: Sun Apr 05, 2020 11:28 am
Posts: 626
Location: Pandora
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.

_________________
地球上の平和


Top
 Profile  
Reply with quote  
 Post subject: Re: The unknown dangerous Procedure StringFunction Bug
PostPosted: Sun Feb 14, 2021 1:33 pm 
Offline
Enthusiast
Enthusiast

Joined: Wed May 27, 2020 12:26 pm
Posts: 292
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...
:D

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

_________________
Thank you Google Search


Top
 Profile  
Reply with quote  
 Post subject: Re: The unknown dangerous Procedure StringFunction Bug
PostPosted: Sun Feb 14, 2021 1:48 pm 
Offline
Enthusiast
Enthusiast
User avatar

Joined: Sun Apr 05, 2020 11:28 am
Posts: 626
Location: Pandora
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. :wink:
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.

Olli wrote:
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...
:D

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. :?:

_________________
地球上の平和


Last edited by Saki on Sun Feb 14, 2021 2:53 pm, edited 1 time in total.

Top
 Profile  
Reply with quote  
 Post subject: Re: The unknown dangerous Procedure StringFunction Bug
PostPosted: Sun Feb 14, 2021 2:50 pm 
Offline
Addict
Addict

Joined: Thu Apr 18, 2019 8:17 am
Posts: 1434
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.


Top
 Profile  
Reply with quote  
 Post subject: Re: The unknown dangerous Procedure StringFunction Bug
PostPosted: Sun Feb 14, 2021 3:28 pm 
Offline
Enthusiast
Enthusiast
User avatar

Joined: Sun Jun 22, 2003 7:43 pm
Posts: 759
Location: Germany, Saarbrücken
Is this error also reproducable if you write this as the parameter?
Code:
"" + 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.

_________________
The english grammar is freeware, you can use it freely - But it's not Open Source, i.e. you can not change it or publish it in altered way.


Top
 Profile  
Reply with quote  
 Post subject: Re: The unknown dangerous Procedure StringFunction Bug
PostPosted: Sun Feb 14, 2021 4:21 pm 
Offline
Enthusiast
Enthusiast
User avatar

Joined: Sun Apr 05, 2020 11:28 am
Posts: 626
Location: Pandora
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.

Image

MiniCode Test All OK :x
Image
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.

_________________
地球上の平和


Last edited by Saki on Sun Feb 14, 2021 5:04 pm, edited 2 times in total.

Top
 Profile  
Reply with quote  
 Post subject: Re: The unknown dangerous Procedure StringFunction Bug
PostPosted: Sun Feb 14, 2021 4:52 pm 
Offline
PureBasic Expert
PureBasic Expert
User avatar

Joined: Fri Apr 25, 2003 4:34 pm
Posts: 1055
Location: Canada
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?

_________________
Image Image


Top
 Profile  
Reply with quote  
 Post subject: Re: The unknown dangerous Procedure StringFunction Bug
PostPosted: Sun Feb 14, 2021 5:10 pm 
Offline
Enthusiast
Enthusiast
User avatar

Joined: Sun Apr 05, 2020 11:28 am
Posts: 626
Location: Pandora
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.

_________________
地球上の平和


Top
 Profile  
Reply with quote  
 Post subject: Re: The unknown dangerous Procedure StringFunction Bug
PostPosted: Sun Feb 14, 2021 5:15 pm 
Offline
Addict
Addict

Joined: Thu Apr 18, 2019 8:17 am
Posts: 1434
Saki, you haven't got a macro named Str() by mistake, maybe? To override the default Str() function?


Top
 Profile  
Reply with quote  
 Post subject: Re: The unknown dangerous Procedure StringFunction Bug
PostPosted: Sun Feb 14, 2021 5:35 pm 
Offline
Enthusiast
Enthusiast
User avatar

Joined: Sun Apr 05, 2020 11:28 am
Posts: 626
Location: Pandora
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.

_________________
地球上の平和


Last edited by Saki on Sun Feb 14, 2021 5:40 pm, edited 1 time in total.

Top
 Profile  
Reply with quote  
 Post subject: Re: The unknown dangerous Procedure StringFunction Bug
PostPosted: Sun Feb 14, 2021 5:40 pm 
Offline
Addict
Addict
User avatar

Joined: Sat Feb 19, 2011 3:47 am
Posts: 2490
Location: Singapore
Saki wrote:
...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:
text$ = Str(10) 
DrawText_FW(canvas_ID, ... , text$, ... )

_________________
Texas Instruments TI-99/4A Home Computer: the first home computer with a 16bit processor, crammed into an 8bit architecture. Great hardware - Poor design - Wonderful BASIC engine. And it could talk too!


Top
 Profile  
Reply with quote  
 Post subject: Re: The unknown dangerous Procedure StringFunction Bug
PostPosted: Sun Feb 14, 2021 5:47 pm 
Offline
Enthusiast
Enthusiast
User avatar

Joined: Sun Jun 22, 2003 7:43 pm
Posts: 759
Location: Germany, Saarbrücken
TI-994A wrote:
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.

_________________
The english grammar is freeware, you can use it freely - But it's not Open Source, i.e. you can not change it or publish it in altered way.


Top
 Profile  
Reply with quote  
 Post subject: Re: The unknown dangerous Procedure StringFunction Bug
PostPosted: Sun Feb 14, 2021 5:49 pm 
Offline
Enthusiast
Enthusiast
User avatar

Joined: Sun Apr 05, 2020 11:28 am
Posts: 626
Location: Pandora
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.

_________________
地球上の平和


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 46 posts ]  Go to page 1, 2, 3, 4  Next

All times are UTC + 1 hour


Who is online

Users browsing this forum: No registered users and 20 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
Jump to:  

 


Powered by phpBB © 2008 phpBB Group
subSilver+ theme by Canver Software, sponsor Sanal Modifiye