AARRGHH !

AARRGHH !

I can't reproduce this bug but I want to report it here.

On a project under Tokyo, I use an avanced JSON Unit based on the one I've published on my web site.

http://lookinside.free.fr/delphi.php?Delphi+XE8+et+JSON

at application startup, I read a Record from a JSON file, it contains the application configuration.

But after some change in the code (not related to JSON nor the Record), I've hit F9 and the application starts to do strange things...the problem was about the configuration.

I've followed the JSON parsing to find out that the TypeInfo informations where corrupted. It was a Record TypeInfo with the rigth name but with fields informations from an other Record ! So my JSON Parser just dropped the values because nothing matched the record definition.

I just had to rebuild the project to fix that nasty bug.

not cool :/
http://lookinside.free.fr/delphi.php?Delphi+XE8+et+JSON

Comments

  1. Ok, the bug is reproductible with my project.

    In fact, the project has two record of the same name in two different units.

    There's no collision in the code that compile without problem, but when I change the code in a third unit, the TypeInfo of my variable of type Unit1.TType is binded to Unit2.TType !

    I've made a video (my code is not public).
    execute.fr - TypeInfo bug in Delphi Tokyo

    ReplyDelete
  2. BTW my JSON Unit uses TypeInfo(T) where T is a Generic...the bug is perhaps there

    {code}
    class procedure JSON.fromJSON(var instance: T; const Str: string);
    begin
    Finalize(instance);
    FillChar(instance, SizeOf(T), 0);
    if Str <> '' then
    PTypeInfo(TypeInfo(T)).FromJSON(@instance, Str);
    end;
    {code}

    ReplyDelete
  3. Take the typeinfo you get, pass it to TRttiContext.GetType and look if that is also wrong. Only then you can be sure that this is bug in the compiler and not in your own json typeinfohelper code.

    Also please check if that also happens with build - I noticed that compile lately (possibly related the dcu caching refactoring few versions ago?) is a bit broken and sometimes results in a wrong binary.

    ReplyDelete
  4. Stefan Glienke the same code should provide the same result. and the bug is reproductible, not random.

    the problem is not in my code but in the TypeInfo() returned pointer that point to the wrong type.

    I've changed the name of one of the record and there's no more problem.

    ReplyDelete
  5. hum...I've tried to specify the type instead of using type inference.
    when I hit F9 I have an error E2033 about type mismatch.
    but if I just hit F9 a second time (you have to do that since Berlin, Delphi tends to raise inexisting errors), the application starts (with the wrong typeinfo).

    I've tried to reproduce that on a tiny project but failed.

    ReplyDelete
  6. That's what I meant, I had multiple occasions where I pressed F9 and the compiler seemed to run, the application ran but crashed at some location it should not although there was some invalid code that should have raised a compiler error (generics involved). Since then I tend to press shift+f9 almost every time although 95% of the code it then compiles again was not touched but because it seems to forget some of the code that actually was changed. Did not have time or was in the mood to do some investigation. At the end of the day I have to get stuff done.

    ReplyDelete
  7. Stefan Glienke yes, I've seen also since some versions, Delphi handles badly files modified from outside (like SVN), a popup ask if the file should be reloaded but 90% of the time the compilation do not take the changes into account.

    ReplyDelete

Post a Comment