Hello again,

It seems that I found 2 bugs(31th May, binary+source snapshot 1.1 , not from cvs).

1. new() doesn't allocate memory correctly under specific circumstances, moreover it just crashes with 216 - av.

i had something like this(and it compiled and ran well under 1.0.6):

<src>
...
TResImageDef        = record
                        Name      : TResName;   // TResName=string[63]
                        hName     : longint;
                        Image     : TImage;
                        ImgType   : ResImgTypes;
                      end;
PResImageDef        = ^TResImageDef;
...
ResImageDefs    : array[1..MResImageDefs] of PResImageDef;
...
ResImageDefs[nResImageDefs]:=New(PResImageDef);   //   <-------
ResImageDefs[nResImageDefs]^.Name:=nName;
...
</src>

the marked line was causing a RE216 but when i changed it into:

<src>
GetMem(ResImageDefs[nResImageDefs],SizeOf(TResImageDef));
ResImageDefs[nResImageDefs]^.Name:=nName;
</src>

it works well. i dont get it :|.
(it is quite possible that this code clip works well, but i haven't been able
to isolate the minimal crashing code :|)

2. i get a following warning message when i try to compile OpenAL headers. al.pas(291,4) Warning: c:\fpc\bin\win32\wmvesa\al.ppu Interface CRC changed 6082E63FE1AAF691
it wouldn't be a problem, if it didn't cause a complete failure eg. my simple OpenAL-based engine doesn't work anymore - silence :|.

(the same compiler version as above.)

3.(more a notice than a bug :>)
when i had the 1.0.6 i've noticed that my DefaultHandler (messages etc) wasn't called at all when unrecognized message was encountered. but that doesn't count now, the 1.1 is fixed, it works well.

Regards
Luke 'Maly' O.

The 1.1 compiler is currently under heavy development so it can be unstable for some parts. We try to keep it as stable as possible but with the current number of changes that is sometimes hard.

When you can supply sources we can try to reproduce the problems

Peter

Firstly i'll try to sync with the cvs or the most recent build. However, if I manage to isolate the problem I'll certainly supply pieces of the source code or even the whole code if I don't manage.

Regards
Luke 'Maly' O.

Hello,
I'm suspecting that current 1.1 compiler forgets to make public the label that used to bind .edata to win32 dlls by smartlinking. At least, the linker cannot find `$PROGRAM$_L1' until I add `.globl $PROGRAM$_L1' before `$PROGRAM$_L1:' in source of obj module with .edata.

Best regards,
Pavel