We're sorry Aspose doesn't work properply without JavaScript enabled.

Free Support Forum - aspose.com

Tiff to Jpeg conversion causes memory leak?

Aspose.Imaging Product Family
#1

Hello Aspose,

this code

8< -------------------------------------------------------------------------------------------------------------------------
logger.debug(“Starting TIFF to JPEG conversion.”);
setProgress(0);

        TiffImage tiffImg = (TiffImage) Image.load(new ByteArrayInputStream(tiffData));
        ByteArrayOutputStream baos = new ByteArrayOutputStream();
        int frameCount = tiffImg.getFrames().length;
        final byte[][] jpegs = new byte[tiffImg.getFrames().length][];
        JpegOptions jpegOptions = new JpegOptions();
        int i = 0;
        for (TiffFrame tf : tiffImg.getFrames()) {
            if (isCancelled())
                break;
            baos.reset();
            tf.save(baos, jpegOptions);
            jpegs[i++] = baos.toByteArray();
            setProgress((int) ((100.0 * i) / frameCount));
        }

        return jpegs;

8< -------------------------------------------------------------------------------------------------------------------------

causes Screenshot_20171110_154952.png (3.4 KB)
after it is called several times.

This is what visualvm tells me
Screenshot_20171110_152320.png (28.0 KB)
Screenshot_20171110_152543.png (25.1 KB)

I checked, the byte[][] returned at the end is not accumulated somewhere and the heap dump backs that up.

Thanks for your help!
Otto

#2

@cfodev,

I have observed the sample code and error images shared by you. I suggest you to please first try using Aspose.Imaging 17.9 on your end. If there is still an issue then please share the source Tiff file reproducing the issue on your end.

#3

Hello Mudassir,

thank you for your quick response.
I was using 17.9 already and I’m not quite sure it’s a problem of the file. I cannot provide the original file causing the issue, because it contains confidential information. But the sample I will provide instead causes the same problem, although I had to increase the loop count from 100 to 1000 (3GB max heap).

Thanks for looking into it!

Regards
Otto
sample.zip (208.0 KB)

#4

@cfodev,

I have tried using following sample code on my end to export your TIFFto JPEG using Aspose.Imaging for Java 17.9. I have not been able to reproduce any issue on my end. Perhaps, you may share the actual file reproducing the issue on your end.

    public static void TestTiff()
    {
       TiffImage tiffImg = (TiffImage) Image.load("C:\\Imaging Data\\sample.tiff");
        int frameCount = tiffImg.getFrames().length;
        final byte[][] jpegs = new byte[tiffImg.getFrames().length][];
        JpegOptions jpegOptions = new JpegOptions();
        int i = 0;
        for (TiffFrame tf : tiffImg.getFrames())
        {
           tf.save("C:\\Imaging Data\\sample.jpeg", jpegOptions);
         }
    }

sample.zip (185.2 KB)

#5

Hello Mudassir,

again thanks for your quick response. How many times did you call this function? It fails here, with 3 GB max heap size after 236 repetitions. The original file I cannot provide because of the reasons I already mentioned.

Regards
Otto

#6

@cfodev,

I have tested the above sample code in loop with 300 iterations and there has been no issue observed on my end. I suggest you to please consider increasing Java heap size on your end. Otherwise, if there is still an issue then please share the actual image reproducing the issue on your end so that I may help you further.

#7

Hello Mudassir,

well, this is strange. There is no need for another image, as I said, the provided sample image fails here after 236 iterations. My max heap size (3 GB) is six times the production value! Can you please tell me what JDK (version and vendor), max heap size and OS you’re using?

Thanks in advance!

Regards,
Otto

#8

@cfodev,

I am using Windows 7 with JDK 1.7_79. The default maximum heap size on my end is 1 GB. I have used Aspose.Imaging for Java 17.9 on my end. Can you please provide the details on your end that may help to reproduce the issue on our end. I also request you to please try using the same sample code that I have shared with you.

    public static void TestTiff()
    {
       TiffImage tiffImg = (TiffImage) Image.load("C:\\Imaging Data\\sample.tiff");
        int frameCount = tiffImg.getFrames().length;
        final byte[][] jpegs = new byte[tiffImg.getFrames().length][];
        JpegOptions jpegOptions = new JpegOptions();
        int i = 0;
        for (TiffFrame tf : tiffImg.getFrames())
        {
            tf.save("C:\\Imaging Data\\sample.jpeg", jpegOptions);
        }
    }
//Function Call
for(int i=0;i<300;i++)
{
  TestTiff();
}
#9

Hello Mudassir,

I decorated your code with everything necessary to make it an actually compileable unit (see attached source), compiled it: javac -cp aspose-imaging-17.9-jdk16.jar Test.java; ran it: java -Xmx1024m -cp aspose-imaging-17.9-jdk16.jar;. Test 2>result.txt.
The program ended at 70 iterations, the stack trace is included in the attached zip
I used:
java version "1.7.0_79" Java(TM) SE Runtime Environment (build 1.7.0_79-b15) Java HotSpot(TM) 64-Bit Server VM (build 24.79-b02, mixed mode)
and
Microsoft Windows [Version 6.1.7601] (Windows 7)

I realised the longer the program ran, the longer took the next 10 iterations and the higher the CPU load grew. I suppose the garbage collector had a hard time then.

Regards
Otto

src-and-stacktrace.zip (1.2 KB)

#10

@cfodev,

Attached please find, output.zip (478 Bytes) that I have obtained in Windows 7 x64 Virtual Machine with JDK 1.7_79 and Aspose.Imaging for Java 17.9 on my end. Can you please try exploring the same on some other machine as this issue is not centric to API but Java configuration on your end.

#11

Hello Mudassir,

well, the problem exists in 3 environments: Win 7 with JDK_1.7.79 64bit, Win 7 with JDK_1.7.55 32bit, Linux with JDK_1.7.80 64bit.
In the environment where I ran the test, JAVA_TOOL_OPTIONS is not set.The JDK was downloaded from Oracle’s website and installed immediately before I ran the test and not configured in any way.
From your log file I can see the your test was running in some build environment. I suppose the settings on your end make the difference. Could you please share your JVM options?

Thank you!

Regards,
Otto

#12

@cfodev,

As shared earlier that I am using Oracle JDK 1.7_79 and Netbean Java application. The Netbeans is running using default configuration on my end. You may try the similar IDE on your end if that is possible.