PJSR RC6 Win7 imageWindow.forceClose() exception

[mschuster]

I am seeing the following exception during script execution when calling forceClose() on an image window:

line 1254: Error: At address 000007FEFD879E5D with exception code C0000005 :
Access violation: invalid memory read operation at address 0000000000000000

The problem appears new to RC6, did not occur in earlier RC's.

The image window's image is a grayscale 32-bit float image. This image has complex processing applied:

This image is first set via apply(), resampled via Resample process, cropped by Crop process and processed by PixelMath.

Commenting out the forceClose() leaves a hidden window. I can show it manually and close it manually in the UI without an exception.

If you need the script I can post it along with a test image.

Mike

[Juan Conejero]

Hi Mike,

This should *never* happen. Yes, please post a script and image where I can reproduce the problem. From your post I deduce that the image is hidden when you call ImageWindow.forceClose(). Does the problem happen if you call show() before forceClose()?

 Thank you!

[mschuster]

Hi Juan,

Yes, the exception also occurs after calling show().

Here is the script and a test image. The script is a prototype for comparing your StarDetector script with StarAlignment.

https://dl.dropboxusercontent.com/u/109232477/ForceClose.zip

To reproduce the exception:

Open pinpoint.fit.
Execute FWHMEccentricity.0.2.
Select pinpoint.fit.
Click the Measure button, wait a moment until the processing completes.
Click the Support button, wait a moment, the script will appear to hang.
Click the Dismiss button.
View the Process Console log for the exception information.

You can also use the #define to enable StarDetector usage. I am still experimenting to see if I can get its output to match StarAlignment.

Thank you,
Mike

[mschuster]

Hi Juan,
FYI: close() does not cause an exception, my workaround.
Mike

[Juan Conejero]

Hi Mike,

This problem is now fixed in the official RC6 version (build 1012). I have identified the exact location of this exception, but I've been unable to find a logical path that generates it. From my experience, this smells like a VC++ compiler bug. So the exception still happens, but since it is actually harmless, I eat it silently with an extra try {} catch ( ... ) {} construct. I'll investigate different compiler optimization options to see if the exception disappears 'magically', as usual with VC++ bugs. Obviously, this problem only happens on Windows, which supports the hypothesis of a compiler bug.

Thank you for your test data, which has been extremely useful, as always.