SkybuckFlying
commented
6 years ago !!!
This bug is much more serious then it looked at first sight to me. At first I was under the impression it's just causing TotalBalance for GUI to be calculated wrongly.
Today I set out/forth to fix these nasty bugs. Surprise Surprise, these Inc() functions are used throughout the code, even for calculating such important things as account balances and account fees.
Now that I have attempted to correct these bugs it seems that:
- These bugs are exploiteable and could be used to enrich oneselfes.
- These bugs are exploiteable and could be used to deprive others of their coins or fees, causing massive fees.
- These bugs seem to lead to slightly wrong "fee" calculations, maybe even bigger than I think.
- Might also be used to crash clients.
I am just scratching the surface of the implications of these bugs.
One thing became immediately apperent though I am not yet sure:
These changes will require a HARD FORK just to prevent older clients from using wrong calculations.
And this has to happen very first cause somebody may try to EXPLOOOOOIITTTT IT LOLOLOLOLOL.
HHHHHMMMMMMMM who would that be ?! LOL.
Well anybody really, anybody can read this and start messing with the code. (Wow accidently pressed the side buttons of my mouse, you lucky git saved my text, would not have re-typed, another one of those stupid design things... AAARGHH...)
RED ALERT PEOPLE
Your PascalCoin is probably about to be OWNED.
Will be interesting to see what happens ! ;) =D
Techworker
On my system this line of code leads to garbage:
It's in UAccounts.pas
I am surprised you were able to build PascalCoin at all with Delphi 2010.
The test program below demonstrates that writing code as above is very unreliable and can lead to all kinds of weird problems and bugs.
First of all it can cause a compiler crash/error/abort.
Second of all it can lead to access violations.
Third of all it can lead to garbage in variables.
Advise is to test this for yourself, see the horror in action. If you don't see the horror in action then pls report back cause that would be highly interesting if this only happens on AMD X2 3800+ system.
Perhaps Delphi compiler generates bad code on this system. Would have to install Delphi on other systems to known for sure. So do report back if your findings are inconsistent with the finding below ;)
Further advise is to avoid using "inc". I always found it stupid to complexify code with a function you don't even know wtf it does and is inconsistent in it's behaviour. Now it does turn out it may or may not be the culprit of bugs in Delphi Compiler. My real hunch is that it may be further bugs related to uint64 types, as encountered in the past like UFOs =D
Anyway why use a function which you don't even known the parameters off ?! Quite whacky.
Anyway the bug results in TotalBalance for all accounts to be wrong/garbage !
Inc also relies on {X+} compiler switch/state... so again why complexify code with such a shitty function as inc ? ;)
I don't even known what inc does in X- nor do I care (will care in near future, but not for now ;)), avoid it like plague ;)
{X-} <- more shit to figure out, bye bye for now. REALLY ?! For something as shitty simple as an addition ?!?! LOL
Why programming languages like Delphi and C/C++ have to complexify something as simple as:
X = X + Y; to something as silly as:
Inc( X, Y )
or
X++
or
X += Y;
Fucked up I tell you, Fucked up ! ;) =D HAHAHAHA.
Now these fuckers run risks that their C/C++ compiler contain nasty bugs like this as well ! YIKES ?!
Worth it ?! Hell no, cause you didn't catch it ! ;) =D I DID ! :PPP****
You be lucky ! I was on your """team""".
// Begin of Test Program
program TestProgram;
{$APPTYPE CONSOLE}
{$R *.res}
(*
Test weird inc on int64, uint64 as encountered in PascalCoin.
version 0.01 created on 11 july 2018 !
I always knew uint64 is a bugged type sort of, and also using inc is pretty stupid for something as easy as this.
Funny enough the Delphi XE Seattle compiler completely crashes with the code below !
Pretty fricking unbelievable ! ;) =D
This time it caused an access violation ! Holyshit !
Your results/bugs may vary !
What could be the cause is that inc on 64bit types only works in "extended syntax" is enabled ?!? It said something like that in help file ?! No link to "How to enable extended syntax" ?!?
Gonna document it here just in case, nice way to fuck a code without people knowing about it ;)
http://docwiki.embarcadero.com/RADStudio/Tokyo/en/Extended_syntax_(Delphi)
" Extended syntax (Delphi)
Go Up to Delphi Compiler Directives (List) Index
Type: Switch
Syntax: {$X+} or {$X-} {$EXTENDEDSYNTAX ON} or {$EXTENDEDSYNTAX OFF}
Default: {$X+} {$EXTENDEDSYNTAX ON}
Scope: Global
Remarks:
The $X directive enables or disables Delphi's extended syntax:
1 Function statements. In the {$X+} mode, function calls can be used as procedure calls; that is, the result of a function call can be discarded, rather than passed to another function or used in an operation or assignment. Generally, the computations performed by a function are represented through its result, so discarding the result makes little sense. Sometimes, however, a function is called because it performs a task such as setting the value of a global variable, without producing a useful result. 2 The Result variable. In the {$X+} mode, the predefined variable Result can be used within a function body to hold the function's return value. 3 Null-terminated strings. In the {$X+} mode, Delphi strings can be assigned to zero-based character arrays (array[0..X] of Char), which are compatible with PChar types.
This directive also affects the use of the caret (^) to indicate pointers. When {$X+} is in effect (the default), you can omit the caret when referencing pointers. When declaring a pointer, however, the caret is required.
For example:
{$X+} type PMyRec = ^TMyRec; TMyRec = record Data: Integer; end;
var MyRec: PMyRec;
begin New(MyRec); MyRec.Data := 42; {#1} end.
Normally, the line marked #1 would be expressed as:
MyRec^.Data := 42;
But with extended syntax enabled, the caret can be omitted. "
Default it should already be on, so this makes no sense, it seems to be simply some kind of compiler bug.
Bye, Skybuck.
control-alt-c also not working to bring up cpu window... seems like Delphi has gone down hill quite a lot !
Seems delphi compiler is simply bugged and uses wrong address, 00000000000 instead of real variable address, "weird or what ?" ;)
*)
{$X+}
uses SysUtils; // System.SysUtils;
var TotalBalance : int64; SomeBalance : uint64;
procedure Main; begin TotalBalance := 0; SomeBalance := 0; while true do begin // experimenting asm clc; // clear carry flag stc; // set carry flag end;
end;
begin try Main; except on E: Exception do Writeln(E.ClassName, ': ', E.Message); end; ReadLn; end.
(*
Code generated is:
TestProgram.dpr.105: begin 0041870C 55 push ebp 0041870D 8BEC mov ebp,esp TestProgram.dpr.106: TotalBalance := 0; 0041870F C705C82E420000000000 mov [$00422ec8],$00000000 00418719 C705CC2E420000000000 mov [$00422ecc],$00000000 TestProgram.dpr.107: SomeBalance := 0; 00418723 C705D02E420000000000 mov [$00422ed0],$00000000 0041872D C705D42E420000000000 mov [$00422ed4],$00000000 TestProgram.dpr.110: Inc( TotalBalance, SomeBalance ); 00418737 8B0500000000 mov eax,[$00000000] 0041873D 8B1504000000 mov edx,[$00000004] 00418743 0105C82E4200 add [$00422ec8],eax 00418749 1115CC2E4200 adc [$00422ecc],edx TestProgram.dpr.111: writeln(TotalBalance); 0041874F FF35CC2E4200 push dword ptr [$00422ecc] 00418755 FF35C82E4200 push dword ptr [$00422ec8] 0041875B A18CD54100 mov eax,[$0041d58c] 00418760 E8ABFBFEFF call @Write0Int64 00418765 E856CDFEFF call @WriteLn 0041876A E815BAFEFF call @_IOTest TestProgram.dpr.112: sleep(1000); 0041876F 68E8030000 push $000003e8 00418774 E813F2FFFF call Sleep TestProgram.dpr.108: while true do 00418779 EBBC jmp $00418737 TestProgram.dpr.114: end; 0041877B 5D pop ebp 0041877C C3 ret
*)
// End of Test Program
Bye, Skybuck.