Quote from: Phoenix on 15 October 2018, 10:47:41Sorry for the late reply (I'm enjoying safe browsing with ExpressVPN and not registered on the site and I do not receive an email alert).

IMPORTANT NOTE
Even if you use Windows 64bit, if you compile for example with Lazarus 32bit you can not have this problem.

Unfortunately, the memory violation has unpredictable effects.

- You can try to change the two lines of suspicious code

  If you use Lazarus (32 / 64bit):
  uInt = NativeUInt
  ptr2int = PtrUInt

  If you use Delphi (depends on the version):
  http://docwiki.embarcadero.com/Libraries/Tokyo/en/System.NativeUInt
  in theory for 64bit if you use "Int64" it's ok
  For ptr2int see my post

- RESTART the computer (in Windows 10, shut down the system should be similar to a hibernation) to "clean" the corrupted memory.
- Build the library (separately if you use it as a package) and the program

If you see differences with your problem you will have confirmation  ;).

I might be having this very issue. I'm also on Windows 10 64-bit. How can I make sure this is the same exact issue btw?

At the top of the page http://imaginglib.sourceforge.net/ there is also stated:

QuoteGet the latest source code from Mercurial repository. Latest release version is 0.26.4 released on 12th October 2009. Get the library package in 7z or ZIP format: Imaging.7z | Imaging.ZIP.

This implies that the project has not been updated since 2009, which is not true. That can also discourage new users which would be very pity.

Quote from: JernejL on 17 May 2018, 10:15:04
Even if it was last updated in 2012, this library is so solid and productive it could well have no updates for years :)

Yes, of course! That is exactly what I also think. It's a great library!

I thought about the people that are seeing the page for the first time. And they could be discouraged from using the great lib because they thing that there is nobody working on it anymore. If there is stated a current date, they would not think so.

Thanks for the report, just pushed your fix to the repo.

Hi,

I've just tested your sample (0->360 degrees) and I've had no crashes
(Lazarus 1.8.4 on Win10, Imaging latest rev. from May 2018, just empty new LCL app).

What versions exactly did you use? Maybe some compiler settings are affecting this?

I'm trying to rotate an image for 309 degrees, and it results in a strange crash:

Quote
#0 SYSTEM_$$_WAITFREE_VAR$PMEMCHUNK_VAR at :0
#1 SYSTEM_$$_SYSFREEMEM_VAR$PFREELISTS$PMEMCHUNK_VAR$$LONGWORD at :0
#2 ?? at :0
#3 FREEMEMNIL(<error reading variable: Attempt to dereference a generic pointer.>) at J:\\Top Down City\EDITORS\Imaging\Source\ImagingUtility.pas:325
#4 FREEIMAGE({WIDTH = 256, HEIGHT = 256, FORMAT = IFA8R8G8B8, SIZE = 262144, BITS = 0x13450070, PALETTE = 0x0}) at J:\\Top Down City\EDITORS\Imaging\Source\Imaging.pas:792
#5 ROTATE45({WIDTH = 256, HEIGHT = 256, FORMAT = IFA8R8G8B8, SIZE = 262144, BITS = 0x13450070, PALETTE = 0x0}, 22, 0x16af720) at J:\\Top Down City\EDITORS\Imaging\Source\Imaging.pas:1970
#6 ROTATEIMAGE({WIDTH = 256, HEIGHT = 256, FORMAT = IFA8R8G8B8, SIZE = 262144, BITS = 0x13450070, PALETTE = 0x0}, 22) at J:\\Top Down City\EDITORS\Imaging\Source\Imaging.pas:2104
#7 MAKEADOOR(292, 0x16afa44) at u_cared.pas:2195
#8 TWND_CAREDITOR__BTN_GENERATEDOORSCLICK(0x17f4c48, <error reading variable>) at u_cared.pas:2348

The crash seems to be depending on which angle i set to rotate about, other angles (343, 326) work well, but 309 degrees seems to be causing an issue.

Image is in this format:

img_door_builder_temp =

record TIMAGEDATA {
  WIDTH = 256,
  HEIGHT = 256,
  FORMAT = IFA8R8G8B8,
  SIZE = 262144,
  BITS = $13450060,
  PALETTE = $0}

Reproducing this is rather easy:

Quote
procedure Twnd_careditor.BitBtn2Click(Sender: TObject);
var
    imgtest: TImageData;
begin

    InitImage(imgtest);

    NewImage(256, 256, IFA8R8G8B8, imgtest);

    RotateImage(imgtest, 309);

    FreeImage(imgtest);

end;

This example seems to show the crash starting at angles 46 and up, but not all ranges seem affected equally:

Quote
procedure Twnd_careditor.BitBtn2Click(Sender: TObject);
var
    imgtest: TImageData;
   i: Integer;
begin

   for i:= 0 to 360 - 1 do begin

      InitImage(imgtest);
       NewImage(256, 256, IFA8R8G8B8, imgtest);
        OutputDebugString(pchar(format('angle %d', [ i ])));
       RotateImage(imgtest, round(i));
       FreeImage(imgtest);

   end;

end;

I think an older imaging version rotated well, maybe i can figure out which one i used in past.

I'm going to update the website with current status in coming days.

Imaging has has repo on Github for some time now: https://github.com/galfar/imaginglib

The crash I found is a memory violation (unfortunately, too much time has passed and I do not remember what happened. The original source has been heavily modified. Probably there was an anomaly in the program or a violation message of memory by the debugger). The application is very large and also uses several third-party libraries. I isolated the problem by excluding source parts. Finally, by applying the change reported, I no longer detected problems with memory.
So providing a source that can show a problem like this is very difficult  :(.

But these resources should help:

(1)

From http://wiki.freepascal.org/Code_Conversion_Guide

32bit / 64 bit support

Pointers under 64bit need 8 bytes instead of 4 on 32bit. The 'Integer' type remains for compatibility 32bit. This means you can no longer typecast pointers into integers and back. FPC defines two new types: PtrInt and PtrUInt. PtrInt is a 32bit signed integer on 32 bit platforms and a 64bit signed integer on 64bit platforms. The same for PtrUInt, but unsigned integer instead. Use for code that should work with Delphi and FPC:

{$IFNDEF FPC} for 32bit
type
  PtrInt = Longint;
  PtrUInt = DWord;
{$ENDIF}

{$IFNDEF FPC} for 64bit
type
  PtrInt = Int64;
  PtrUInt = QWord;
{$ENDIF}

(2)

http://wiki.freepascal.org/Cardinal

NOTE: pointers are unsigned integer

Thank!  :)

Could you check with the latest version of Imaging? There was a rework of the Lazarus packages in March 2018.

Even if it was last updated in 2012, this library is so solid and productive it could well have no updates for years :)

I would however suggest moving repo to github to attract more users and exposure.