Memory Issues with BoneJ

Hello community, and BoneJ maintainers @mdoube and @alessandrofelder,

I’m trying to calculate the fractal dimension of a set of images using the plugin BoneJ (https://imagej.net/BoneJ). Currently testing it with 4 different binary images. Here is an example:
test 2 729 WT_c1 V2 Binary RLQ Periphery.tif (61.0 KB)

My settings call for 2 translations of the grid. Minimum size of 6 pixels, starting point of 48, and a scale factor of 1.2 (mostly the default settings). I’m limited to 2 translations as FIJI gives an error that it has run out of memory/it can’t create any new native threads if I go with any more translations.

The problem is that even with settings as mild as these, after a few images I start getting the error:
java.lang.OutOfMemoryError: unable to create new native thread

This also happens when I try to batch process all 4 of my images. I have no idea how to fix it, other than closing FIJI after every analysis. ImageJ should have access to 3.5GB of memory (laptop has 8GB of RAM) and 8 parallel threads. Any help would be greatly appreciated!!

Note: I am running FIJI 1.53j

Thanks,
MichelN

I’m can reproduce this using the procedure you describe above on a larger machine.

Java HotSpot(TM) 64-Bit Server VM warning: Attempt to protect stack guard pages failed.
<repeated many times>
Java HotSpot(TM) 64-Bit Server VM warning: INFO: os::commit_memory(0x00007f318501e000, 12288, 0) failed; error='Cannot allocate memory' (errno=12)
#
# There is insufficient memory for the Java Runtime Environment to continue.
# Native memory allocation (mmap) failed to map 12288 bytes for committing reserved memory.
# An error report file with more information is saved as:
# /home/mdoube/Fiji.app.dev/hs_err_pid379776.log
Java HotSpot(TM) 64-Bit Server VM warning: Attempt to protect stack guard pages failed.
Java HotSpot(TM) 64-Bit Server VM warning: Attempt to protect stack guard pages failed.
Java HotSpot(TM) 64-Bit Server VM warning: Attempt to protect stack guard pages failed.
Java HotSpot(TM) 64-Bit Server VM warning: Attempt to deallocate stack guard pages failed.
Java HotSpot(TM) 64-Bit Server VM warning: INFO: os::commit_memory(0x00007f7f3bbcb000, 65536, 1) failed; error='Cannot allocate memory' (errno=12)
[thread 139913374230272 also had an error]

This happens even though only a very small fraction (< 1GB) of total memory (200+ GB) was used. Normally if ImageJ detects an out of memory state it dies somewhat more elegantly than this, killing the plugin only and displaying an error to the user.

Running this macro on the demo image you provide above causes IJ to crash on my machine after a few iterations of the for loop:

for (i = 0; i < 10; i++) {
    run("Fractal dimension", "startboxsize=48 smallestboxsize=6 scalefactor=1.2 translations=2 autoparam=false showpoints=true");
}

Maybe there is a problem with the streaming or threading model used by Fractal Dimension or its upstream Op.

I made a quick hack that uses only one thread. It is slow on large images so is not a permanent solution, but @MichelN it will allow you to finish your project.

Download that and replace the imagej-ops-0.45.7.jar in your Fiji.app/jars/ directory, with this SNAPSHOT version. Later on Fiji will update automatically with a fixed release (i.e. not a SNAPSHOT) version.

1 Like

Hello,

Thank you so much for your help! I realize now how weak my quad core 2019 MacBookPro is…

Hopefully this will be exactly what I need.

Cheers,
MichelN

I get the same crash on my laptop, a few years old Dell Latitude (and now also on my big workstation). I am surprised we didn’t see this bug earlier, which makes me wonder whether something has changed in some libraries that BoneJ uses, maybe even Java itself. Which Java are you using (Help > About ImageJ)? I have Oracle’s 1.8.0_172 for Linux, 64-bit.

I posted a bug report here:

I’m using Java 1.8.0_202 (64-bit)

It’s unfortunate this bug hasn’t been ironed out earlier. It may be due to an issue in the fundamental libraries, since I’ve also encountered a bug in other plugin FracLac, which occurs after I do a deep fractal analysis of a vascular network. I’ve posted a picture of the error log that pops up.

This happens after a few runs of FracLac calculating fractal dimension and lacunarity with 12 grid orientations, limiting the maximum box size to 30 pixels (a point after which I saw the count reaches a horizontal plateau), a minimum size up to FracLac to determine, and using the default linear scaling method between the box sizes. I set it to output and save the results of every grid, and graphs showing the count vs grid calibre.

Admittedly this is a bigger analysis than the one I am attempting with BoneJ, and the error message is not the same, but I wonder if they are connected.

Thanks for the report - it’s not the same bug. Sorry you are having so much trouble with this!