Results 1 to 6 of 6

Thread: Strange problem, can't describe in title..

  1. #1
    Join Date
    Oct 2015
    Location
    Nowhere
    Posts
    134
    Mentioned
    2 Post(s)
    Quoted
    64 Post(s)

    Default Strange problem, can't describe in title..

    For some reason my integer variable will not increase (using inc(i)), but only in certain ways..

    First, I'll show this:
    Simba Code:
    procedure mt(var TimeMarker: longword); //mark time, got tired of typing out marktime
    begin
      TimeMarker := GetSystemTime();
    end;
    Now onto the problem:
    Simba Code:
    procedure inctest();
    var
      t:Longword;
      test:Integer;
    begin
      writeln(test); //prints 0
      inc(test);
      writeln(test); //prints 1
      mt(t);
      writeln(test); //prints 0
    end;
    As you can see, after mt(t), the value goes back to 0. If I remove mt(t), it works fine. Or, if I swap the variable initialization and leave in mt(t), like this:
    Simba Code:
    procedure inctest();
    var
      test:Integer;
    t:Longword;
    begin
      writeln(test); //prints 0
      inc(test);
      writeln(test); //prints 1
      mt(t);
      writeln(test); //prints 1
    end;

    Why is it doing this? I am using simba 1.2

  2. #2
    Join Date
    Feb 2012
    Location
    Norway
    Posts
    995
    Mentioned
    145 Post(s)
    Quoted
    596 Post(s)

    Default

    OH REALLY! Now this is a very peculiar bug! I like it!

    Edit:
    After a quick look, the issue stems from how it's added to Simba.
    GetSystemTime is just an alias for GetTickCount, however in newer Simba releases the return of GetTickCount is a 64bit number, not a 32bit number, the definition of GetSystemTime however has not been updated to reflect this change:
    >> AddGlobalFunc('function GetSystemTime: LongWord', PPointer(Compiler['GetTickCount'].Ptr)^); //should be 'function GetSystemTime(): UInt64'
    while GetTickCount now looks like:
    >> function GetTickCount(): UInt64;

    The solution is to not use GetSystemTime, but instead use the function named "GetTickCount".

    ---

    Some names that might have find time to upload a patch: @nielsie95; @Olly; @Dgby714; @riwu;
    Last edited by slacky; 01-22-2017 at 08:42 AM.
    !No priv. messages please

  3. #3
    Join Date
    Oct 2015
    Location
    Nowhere
    Posts
    134
    Mentioned
    2 Post(s)
    Quoted
    64 Post(s)

    Default

    Indeed that fixed it, thanks!

    But... Why? I don't understand how it affects the int variable, or why it works if I initialize the longword after the int

  4. #4
    Join Date
    Feb 2012
    Location
    Norway
    Posts
    995
    Mentioned
    145 Post(s)
    Quoted
    596 Post(s)

    Default

    Quote Originally Posted by skollstagg View Post
    Indeed that fixed it, thanks!

    But... Why? I don't understand how it affects the int variable, or why it works if I initialize the longword after the int
    It's complicated, i'll try to super-simplify it, but to really understand wtf is going on you really need to somewhat understand compilers, and have some understanding about how computer memory works.

    "t" and "test" is stored after one another in memory. First "t", because it was created first, then "test". Together both these two 4 byte numbers occupies an 8 byte block of memory.
    when "GetSystemTime" updates "t", now named "TimeMarker" it will write a 8 byte long number into the 4 byte large variable "t", but that can't possibly fit, the number is 4 bytes to large, so it "flows over", it's forced to write the 4 remaining bytes to the neighboring 4 bytes in your memory, this is for us known as the variable named "test"..

    If you flip the order of when you create "t" and "test", then "test" would not be modified. It would write from "t" and out into something else, something "unknown" would be modified and at some point this could randomly crash Simba as whatever was modified could be important.


    The reason it happens is because the mistake I mentioned above that "fools" lape to think a 4 byte variable is big enough to receive 8 bytes of data.

    - I tried.
    Last edited by slacky; 01-22-2017 at 09:46 AM.
    !No priv. messages please

  5. #5
    Join Date
    Mar 2013
    Posts
    1,010
    Mentioned
    35 Post(s)
    Quoted
    620 Post(s)

    Default

    Quote Originally Posted by slacky View Post
    OH REALLY! Now this is a very peculiar bug! I like it!

    Edit:
    After a quick look, the issue stems from how it's added to Simba.
    GetSystemTime is just an alias for GetTickCount, however in newer Simba releases the return of GetTickCount is a 64bit number, not a 32bit number, the definition of GetSystemTime however has not been updated to reflect this change:
    >> AddGlobalFunc('function GetSystemTime: LongWord', PPointer(Compiler['GetTickCount'].Ptr)^); //should be 'function GetSystemTime(): UInt64'
    while GetTickCount now looks like:
    >> function GetTickCount(): UInt64;

    The solution is to not use GetSystemTime, but instead use the function named "GetTickCount".

    ---

    Some names that might have find time to upload a patch: @nielsie95; @Olly; @Dgby714; @riwu;
    Fixed, just need someone to update the build
    #slack4admin2016
    <slacky> I will build a wall
    <slacky> I will ban reflection and OGL hooking until we know what the hell is going on

  6. #6
    Join Date
    Oct 2015
    Location
    Nowhere
    Posts
    134
    Mentioned
    2 Post(s)
    Quoted
    64 Post(s)

    Default

    Quote Originally Posted by slacky View Post
    It's complicated, i'll try to super-simplify it, but to really understand wtf is going on you really need to somewhat understand compilers, and have some understanding about how computer memory works.

    "t" and "test" is stored after one another in memory. First "t", because it was created first, then "test". Together both these two 4 byte numbers occupies an 8 byte block of memory.
    when "GetSystemTime" updates "t", now named "TimeMarker" it will write a 8 byte long number into the 4 byte large variable "t", but that can't possibly fit, the number is 4 bytes to large, so it "flows over", it's forced to write the 4 remaining bytes to the neighboring 4 bytes in your memory, this is for us known as the variable named "test"..

    If you flip the order of when you create "t" and "test", then "test" would not be modified. It would write from "t" and out into something else, something "unknown" would be modified and at some point this could randomly crash Simba as whatever was modified could be important.


    The reason it happens is because the mistake I mentioned above that "fools" lape to think a 4 byte variable is big enough to receive 8 bytes of data.

    - I tried.
    I get it. Thanks

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •