View Issue Details

IDProjectCategoryView StatusLast Update
0016252LazarusIDEpublic2011-12-01 11:25
ReporterLeteur AlixAssigned ToVincent Snijders 
PrioritynormalSeveritymajorReproducibilityalways
Status closedResolutionfixed 
Platformwin64OSwin xp pro 64OS Versionsp2
Product VersionProduct Build 
Target VersionFixed in Version0.9.29 (SVN) 
Summary0016252: Foating point type error under win64 when reading/writing property file (was:Silently failing to record property in lfm)
Descriptioni'm currently porting one of my lib from delphi to lazarus in the process of completly moving to lazarus+fpc

this lib contains very simple graphical components with publish float property (single)

if i add one component to the form everything seems ok but only the first single property is recorded to the lfm,
if i add a second component it shows on the form but is not recorded at all

i tried to add a default value for all property without success (bug still present)

version used:
Lazarus-0.9.29-24569-fpc-2.4.1-20100411

please note that i used the nightly build because it was even worse with:
lazarus-0.9.28.2-fpc-2.2.4-win64
(saving the form would produce a streaming error with that version)
Steps To Reproduce-lazarus 0.9.29-24569
-install test package
-add 2 TTestKnob to the form
-only some properties show in the lfm
-now change Position property of the first knob in object inspector
-the second knob has disappeared of the lfm
TagsNo tags attached.
Fixed in Revision28428
LazTarget-
WidgetsetWin32/Win64
Attached Files
  • TestPack.7z (2,020 bytes)
  • unit1.lfm (462 bytes)
  • floatPatch.diff (1,872 bytes)
    Index: lresources.pp
    ===================================================================
    --- lresources.pp	(revision 24631)
    +++ lresources.pp	(working copy)
    @@ -528,6 +528,7 @@
     function ReadLRSCurrency(s: TStream): Currency;
     function ReadLRSWideString(s: TStream): WideString;
     function ReadLRSEndianLittleExtendedAsDouble(s: TStream): Double;
    +function ReadLRSBigEndianExtendedAsDouble(s: TStream): Double;
     function ReadLRSValueType(s: TStream): TValueType;
     function ReadLRSInt64MB(s: TStream): int64;// multibyte
     
    @@ -3334,9 +3335,9 @@
         {$ENDIF}
       {$ELSE}
         {$IFDEF FPC_BIG_ENDIAN}
    +      Result:=ReadLRSBigEndianExtendedAsDouble(s);
    +    {$ELSE}
           Result:=ReadLRSEndianLittleExtendedAsDouble(s);
    -    {$ELSE}
    -      Debugln('Reading of extended on little endian cpus without 80 bits extended is not yet implemented');
         {$ENDIF}
       {$ENDIF}
     end;
    @@ -3369,9 +3370,19 @@
       e: array[1..10] of byte;
     begin
       s.Read(e,10);
    +  //that function already take care of endianness
       Result:=ConvertLRSExtendedToDouble(@e);
     end;
     
    +function ReadLRSBigEndianExtendedAsDouble(s: TStream): Double;
    +var
    +  e: array[1..10] of byte;
    +begin
    +  s.Read(e,10);
    +  //that function already take care of endianness
    +  Result:=ConvertLRSExtendedToDouble(@e);
    +end;
    +
     function ReadLRSValueType(s: TStream): TValueType;
     var
       b: byte;
    @@ -4358,10 +4369,8 @@
     end;
     
     procedure TLRSObjectWriter.WriteExtendedContent(e: Extended);
    -{$IFDEF FPC_BIG_ENDIAN}
     var
       LRSExtended: array[1..10] of byte;
    -{$endif}
     begin
       {$IFDEF FPC_BIG_ENDIAN}
         {$IFDEF FPC_HAS_TYPE_EXTENDED}
    @@ -4372,7 +4381,12 @@
           Write(LRSExtended,10);
         {$ENDIF}
       {$ELSE}
    -  Write(e,10);
    +    {$IFDEF FPC_HAS_TYPE_EXTENDED}
    +      Write(e,10);
    +    {$ELSE}
    +      ConvertLEDoubleToLRSExtended(@e,@LRSExtended);
    +      Write(LRSExtended,10);
    +    {$ENDIF}
       {$ENDIF}
     end;
     
    
    floatPatch.diff (1,872 bytes)

Relationships

related to 0017814 closedVincent Snijders Packages Using TAChart component in form causes mistakes in *.lfm file (Win64 only) 
related to 0018292 closedVincent Snijders Lazarus More than one FloatSpinEdit cause problems on IDE 

Activities

2010-04-11 10:25

 

TestPack.7z (2,020 bytes)

Juha Manninen

2010-04-12 11:10

developer   ~0036632

I works well for me. I installed the package, made a test project and added 2 TTestKnob controls on a form. I can set their Position and ResetPosition properties and they get saved to LFM file correctly.

The default value 0.0 is not saved to LFM file but all other values are. I upload an example LFM file.

How can I reproduce this error?

2010-04-12 11:11

 

unit1.lfm (462 bytes)

Leteur Alix

2010-04-12 13:13

reporter   ~0036639

Since you were unable to reproduce i made a clean install (and erased lazarus Application data folder to be sure to have factory settings)

i installed only the testpack and made a test project

the second component added to the form dissapear as soon as i modify one float property and view the lfm

(please note also that the float properties of the 1st compoenent are reset to zero)

Could i help you further to understand that issue ? point me in the right direction maybe ?
i really don't know how to help you efficiently since it's 100 % reproducable here

Leteur Alix

2010-04-12 22:21

reporter   ~0036648

Further tests show that even standard lcl components seems affected,
i have the same issue with TFloatSpinEdit

Juha Manninen

2010-04-12 23:52

developer   ~0036651

Ok, there is clearly something else broken in your system.
All the problems are with floating point numbers, right?
Could win64 have such problems? Does anyone know?

I recommend you make a clean build of Lazarus SVN trunk version.
  http://wiki.lazarus.freepascal.org/Getting_Lazarus#Getting_SVN
You already made a clean install of nightly build so I am sure if it makes difference, but at least SVN version is easier to update later.

Leteur Alix

2010-04-13 08:35

reporter   ~0036659

Last edited: 2010-04-13 09:01

>Ok, there is clearly something else broken in your system.
>Could win64 have such problems? Does anyone know?

i really don't think so, i use visual studio 2008 team, never noticed any problem,
wouldn't it affects a lot of thing if it was system wide?
i mean, it's not like floating point are an obscure feature used by rare programs ;)

All the problems are with floating point numbers, right?
Yes

i'll try to make a build today and see if it makes any difference

Juha Manninen

2010-04-13 09:01

developer   ~0036660

> i really don't think so, i use visual studio 2008 team, never noticed any
> problem,
> wouldn't it affects a lot of thing if it was system wide?

Actually I meant if FPC or Lazarus had such problems under win64. I don't think so either because many people now have 64-bit systems and someone would have noticed.

Leteur Alix

2010-04-13 12:04

reporter   ~0036662

Last edited: 2010-04-13 12:05

First time i build fpc and lazarus, took me some time to succeed
i actually made an error and build win32 version
and it worked very nicely (the bug was ABSENT in that build, i tested just to see)

..... (half an hour later)
so i was able to build fpc for 64 bit from source (2.4.0)
and lazarus from svn (revision 24608)

Problem still present


Can i help you further?

Juha Manninen

2010-04-13 13:45

developer   ~0036663

Someone with Win64 should give a comment on this.
I don't have win64 to test with.
Could it be a bug in FPC? Should it be updated to a more recent version?

Leteur Alix

2010-04-13 14:02

reporter   ~0036664

Do you want me to try with a newer fpc from svn ?

also i can try to help to spot the problem if you point me to the sources that are responsible for the lfm creation

Leteur Alix

2010-04-15 13:28

reporter   ~0036722

Last edited: 2010-04-15 13:35

i guess i spotted a potential error:
in LResources.pp line 2685
the variable "flt" should be double if i interpret correctly the code

since that variable is written with WriteLRSExtended(Output,flt);
which use the function WriteLRSDoubleAsExtended

so i guess a double was expected here and since it's bitwise manipulated , is probably not error proof

Correct me if i'm wrong.

Juha Manninen

2010-04-15 14:31

developer   ~0036723

You can try what happens if you change the type from extended to double, and rebuild Lazarus. I was hoping someone else with win64 would test this case.

In my LResources.pp "flt" is defined at line 2706.
"WriteLRSExtended(Output,flt);" is line 2724.
SVN trunk rev 24627.

You could also try the chat channel or Lazarus mailing list for support. They are quite active.

Leteur Alix

2010-04-15 14:52

reporter   ~0036724

>You could also try the chat channel or Lazarus mailing list for support. They are quite active.

ok thanks for the advice,
i'll try to have a deeper understanding of lazarus sources, do some debugging and ask questions after if everything fails

Leteur Alix

2010-04-15 16:47

reporter   ~0036727

Finally found the source of the problem, it was really obvious with lazarus console turned on :


Reading of extended on little endian cpus without 80 bits extended is not yet implemented
TMainIDE.SaveFileResources E3: Stream read error
  Stack trace:
  $0000000100094459
  $000000010009497F
  $0000000100101BA5 READPROPLIST, line 2448 of lresources.pp
  $0000000100101946 READOBJECT, line 2486 of lresources.pp
  $00000001001019AC READOBJECT, line 2490 of lresources.pp
  $000000010010162B LRSOBJECTBINARYTOTEXT, line 2510 of lresources.pp
  $000000010004E34D TMAINIDE__DOSAVEUNITCOMPONENT, line 5292 of main.pp
  $000000010005AA37 TMAINIDE__DOSAVEEDITORFILE, line 8151 of main.pp
  $0000000100060336 TMAINIDE__DOSAVEPROJECT, line 9476 of main.pp
  $0000000100065942 TMAINIDE__DOSAVEALL, line 10722 of main.pp
  $0000000100043B7E TMAINIDE__MNUSAVEALLCLICKED, line 2775 of main.pp
  $000000010046A2B4 TIDEMENUITEM__MENUITEMCLICK, line 538 of menuintf.pas
  $000000010046DD61 TIDEMENUCOMMAND__MENUITEMCLICK, line 1549 of menuintf.pas
  $000000010019F079 TMENUITEM__CLICK, line 75 of ./include/menuitem.inc
  $000000010019F802 TMENUITEM__DOCLICKED, line 269 of ./include/menuitem.inc
  $000000010000E685
  $00000001001B528A WINDOWPROC, line 1237 of win32callback.inc
LAZARUS END - cleaning up ...

Juha Manninen

2010-04-15 19:18

developer   ~0036732

The reason is that x64 processors have dropped support for extended type (80bits).

  function ReadLRSExtended(s: TStream): Extended; in LResources.pp
has a test:
  {$IFDEF FPC_HAS_TYPE_EXTENDED}
which is false for x64 processor.

Leteur Alix

2010-04-15 21:22

reporter   ~0036733

Finally found a nice way to correct it, without breaking anything

see my patch

2010-04-15 21:23

 

floatPatch.diff (1,872 bytes)
Index: lresources.pp
===================================================================
--- lresources.pp	(revision 24631)
+++ lresources.pp	(working copy)
@@ -528,6 +528,7 @@
 function ReadLRSCurrency(s: TStream): Currency;
 function ReadLRSWideString(s: TStream): WideString;
 function ReadLRSEndianLittleExtendedAsDouble(s: TStream): Double;
+function ReadLRSBigEndianExtendedAsDouble(s: TStream): Double;
 function ReadLRSValueType(s: TStream): TValueType;
 function ReadLRSInt64MB(s: TStream): int64;// multibyte
 
@@ -3334,9 +3335,9 @@
     {$ENDIF}
   {$ELSE}
     {$IFDEF FPC_BIG_ENDIAN}
+      Result:=ReadLRSBigEndianExtendedAsDouble(s);
+    {$ELSE}
       Result:=ReadLRSEndianLittleExtendedAsDouble(s);
-    {$ELSE}
-      Debugln('Reading of extended on little endian cpus without 80 bits extended is not yet implemented');
     {$ENDIF}
   {$ENDIF}
 end;
@@ -3369,9 +3370,19 @@
   e: array[1..10] of byte;
 begin
   s.Read(e,10);
+  //that function already take care of endianness
   Result:=ConvertLRSExtendedToDouble(@e);
 end;
 
+function ReadLRSBigEndianExtendedAsDouble(s: TStream): Double;
+var
+  e: array[1..10] of byte;
+begin
+  s.Read(e,10);
+  //that function already take care of endianness
+  Result:=ConvertLRSExtendedToDouble(@e);
+end;
+
 function ReadLRSValueType(s: TStream): TValueType;
 var
   b: byte;
@@ -4358,10 +4369,8 @@
 end;
 
 procedure TLRSObjectWriter.WriteExtendedContent(e: Extended);
-{$IFDEF FPC_BIG_ENDIAN}
 var
   LRSExtended: array[1..10] of byte;
-{$endif}
 begin
   {$IFDEF FPC_BIG_ENDIAN}
     {$IFDEF FPC_HAS_TYPE_EXTENDED}
@@ -4372,7 +4381,12 @@
       Write(LRSExtended,10);
     {$ENDIF}
   {$ELSE}
-  Write(e,10);
+    {$IFDEF FPC_HAS_TYPE_EXTENDED}
+      Write(e,10);
+    {$ELSE}
+      ConvertLEDoubleToLRSExtended(@e,@LRSExtended);
+      Write(LRSExtended,10);
+    {$ENDIF}
   {$ENDIF}
 end;
 
floatPatch.diff (1,872 bytes)

Vincent Snijders

2010-11-23 09:53

manager   ~0043401

Thanks for the patch. I fixed it with my own changes, while looking at the patch.

Please test, and close if ok.

Issue History

Date Modified Username Field Change
2010-04-11 10:25 Leteur Alix New Issue
2010-04-11 10:25 Leteur Alix File Added: TestPack.7z
2010-04-11 10:25 Leteur Alix Widgetset => Win32/Win64
2010-04-12 11:10 Juha Manninen LazTarget => -
2010-04-12 11:10 Juha Manninen Note Added: 0036632
2010-04-12 11:10 Juha Manninen Status new => feedback
2010-04-12 11:11 Juha Manninen File Added: unit1.lfm
2010-04-12 13:13 Leteur Alix Note Added: 0036639
2010-04-12 22:21 Leteur Alix Note Added: 0036648
2010-04-12 23:52 Juha Manninen Note Added: 0036651
2010-04-13 08:35 Leteur Alix Note Added: 0036659
2010-04-13 09:01 Juha Manninen Note Added: 0036660
2010-04-13 09:01 Leteur Alix Note Edited: 0036659
2010-04-13 12:04 Leteur Alix Note Added: 0036662
2010-04-13 12:05 Leteur Alix Note Edited: 0036662
2010-04-13 13:45 Juha Manninen Note Added: 0036663
2010-04-13 14:02 Leteur Alix Note Added: 0036664
2010-04-15 13:28 Leteur Alix Note Added: 0036722
2010-04-15 13:35 Leteur Alix Note Edited: 0036722
2010-04-15 14:31 Juha Manninen Note Added: 0036723
2010-04-15 14:52 Leteur Alix Note Added: 0036724
2010-04-15 16:47 Leteur Alix Note Added: 0036727
2010-04-15 17:56 Juha Manninen Summary Silently failing to record property in lfm => Foating point type error under win64 when reading/writing property file (was:Silently failing to record property in lfm)
2010-04-15 19:18 Juha Manninen Note Added: 0036732
2010-04-15 19:20 Juha Manninen Status feedback => assigned
2010-04-15 19:20 Juha Manninen Assigned To => Vincent Snijders
2010-04-15 21:22 Leteur Alix Note Added: 0036733
2010-04-15 21:23 Leteur Alix File Added: floatPatch.diff
2010-11-23 09:53 Vincent Snijders Fixed in Revision => 28428
2010-11-23 09:53 Vincent Snijders Status assigned => resolved
2010-11-23 09:53 Vincent Snijders Fixed in Version => 0.9.29 (SVN)
2010-11-23 09:53 Vincent Snijders Resolution open => fixed
2010-11-23 09:53 Vincent Snijders Note Added: 0043401
2010-11-23 09:54 Vincent Snijders Relationship added related to 0017814
2010-12-22 20:34 Vincent Snijders Relationship added related to 0018292
2011-12-01 11:25 Marc Weustink Status resolved => closed