Release 1.8.6 Repeating Crashes

[wisetrout]

During the past two years I never experienced a PI crash.  Release 1.8.6 is not stable on my computer.  I have uninstalled and reinstalled twice.  Is anybody else having difficulties?

[pfile]

not on OSX - you'll have to provide more details. windows? linux?

is there any crashdump information available?

rob

[wisetrout]

I am running Windows 8.1.  I get a message window from "Windows" stating there has been an error, and the program must close.  No other information.  The program runs for about 15 to 30 minutes then the error occurs.  It happens every time I run the program.  In two years of using the earlier version, I never had it happen.

Thanks for your help.

[pfile]

you might need to look in the error reporter and see if there's any info about the crash:

https://www.cyberlink.com/support/faq-content.do?id=10449

without this info juan can't do anything. since there are not an avalanche of people posting here with similar problems, it may be something specific to your system.

rob

[Darkstar]

I have similar problems on Windows 10. Never had with 1.8.5.

Always the same memory access violation errors with subsequent application crash.

These during an Image Integration processing:

[Juan Conejero]

I cannot reproduce these problems on any platform. What memory access violations? What hardware? Any repeatable pattern? A reduced data set where I can reproduce the issue?

[Darkstar]

Just modified my post with some images.

[Juan Conejero]

This cannot be reproduced on any of our working and testing machines.

On Windows, these exceptions can be caused sometimes as a result of severe exhaustion of RAM resources; for example if you are trying to integrate a huge set of images that cannot be loaded incrementally (for example, digital camera raw images) and you don't have enough memory to load them at once.

Another possible cause is a defective OpenGL implementation, but if you have been using version 1.8.5 before this is unlikely.

Anyway, can you please upload a data set where this can be reproduced? If you can use something like Dropbox to upload a project, that would be of great help.

[wadeh237]

I'm also noticing that 1.8.6 is unstable as compared to previous versions.  I am seeing 3 specific behaviors that I've never seen before installing the current version.

For reference, I am running Windows 10 version 1709, build 16299.611, with a Surface Book with Core-i7 processor and 16GB of RAM.  Here are the things that I'm seeing:

1) When I am using a process with a real-time preview window, sometimes the preview window does not close the first time I click on the 'X' in the corner of the window.  It always closes on the second click.  This is a small thing and it doesn't happen all the time, but I've seen it enough times that it's noticeable.

2) Sometimes when I select a process that's not open yet, I get the following error dialog with the text.  I have seen it on multiple processes and if I exit and restart PI, then it works normally:

CreateSpinBox(): Low-Level API Function
error (0x0001): Unknown error

3) Twice now, I've had version 1.8.6 go unresponsive while running a process or script.  According to the resource monitor, when this happens the CPU goes to maximum clock speed and the pixinsight.exe process consumes 100% CPU for about 5 seconds and then goes idle for about 5 seconds, repeatedly.  I've seen this happen when running the PSFImage script from www.skypixels.at.  I initially attributed it to the script, but I've also seen it happen with TGVDenoise and MultiscaleMedianTransform.  Once when I saw it, I left the computer for two hours and it never returned to a responsive state.  Clicking on the Abort button in the Process Console for the two built-in processes did not return the PI to a responsive state.  In all cases, terminating the pixinsight.exe process and then restarting it returned things to normal (with the loss of any unsaved work).  In the new PixInsight instance, all of the processes ran as expected.

In addition to CPU, I've monitored memory consumption.  The pixinsight.exe process was consuming about 1.5GB of RAM in the cases where the CPU spun, and total memory usage on the machine never exceeded 65% of the total available.

Unfortunately, I cannot reproduce any of the above behaviors and have not found any pattern to them.  I've taken to doing frequent saves of my project to avoid losing too much work.  Again, this is all on a machine that has been rock solid stable on previous PI versions.

If there is something I can do to collect more information, please let me know.

Thanks,
-Wade

[Warhen]

Warren, from the beta tester team reporting in. I've had no problems with my desktop and Windows 10. When I get home tomorrow from my PixInsight teaching trip, I will install 1.8.6 on my Windows 10 laptop and report back in.

[pfile]

is todays release with the QT dll included intended to fix this problem?

rob

[RickS]

Warren, from the beta tester team reporting in. I've had no problems with my desktop and Windows 10. When I get home tomorrow from my PixInsight teaching trip, I will install 1.8.6 on my Windows 10 laptop and report back in.

Likewise, the beta versions and the final release have been stable for me on a desktop system (AMD Threadripper, Windows 10 Home) and a laptop (Dell XPS15, Windows 10 Pro.)

Cheers,
Rick.

[Darkstar]

This cannot be reproduced on any of our working and testing machines.

On Windows, these exceptions can be caused sometimes as a result of severe exhaustion of RAM resources; for example if you are trying to integrate a huge set of images that cannot be loaded incrementally (for example, digital camera raw images) and you don't have enough memory to load them at once.

Another possible cause is a defective OpenGL implementation, but if you have been using version 1.8.5 before this is unlikely.

Anyway, can you please upload a data set where this can be reproduced? If you can use something like Dropbox to upload a project, that would be of great help.

I'm doing further tests. Now crashed on applying a crop process in a image container of 20 images not 200 ...

I'm gonna to send you project file if further tests go wrong.

[Warhen]

As promised, I have installed the very latest .1448 on my Windows 10 ASUS laptop and ran a quick BPP LRGB run w/ CosmeticCorrection with no issues at all. The only thing I saw was a red checksum error in the Process Console when I tried to open an instance of BPP from a new instance icon that had been saved in 1.8.5. 1.8.6.1448 working well in Windows 10 on a desktop and a laptop.

[Juan Conejero]

Hi Warren,

Thank you so much for your report. The checksum mismatch error is normal if you are executing BPP (or any other script for that matter) from an icon previously saved with version 1.8.5. The checksums don't match because we have modified the script in this version. As you know, you can run the icon after deleting the MD5 checksum manually on the Script tool.

By the way, users sometimes ask why this happens when we change a script. I'll take advantage of this opportunity to answer. This happens because scripts are intrinsically dangerous in PixInsight. A script can be altered very easily, since its entire source code is necessarily available when it is going to be executed. A malicious modification made to one of the scripts distributed with PixInsight would easily pass unnoticed, but could do extremely harmful things, considering the power available in our JavaScript runtime.

By associating a cryptographic checksum (MD5 in this case) to each executed instance of a script, we can ensure that the icon you are going to launch will run exactly the same source code that was executed previously, when you saved the icon. This rules out the possibility of a malicious modification applied to a process icon, and/or to the associated script, which would lead you to run altered code without your knowledge. When you delete the MD5 checksum on the Script tool, you are assuming the entire responsibility for what happens next

In a future version of the core application, I plan on implementing a secure system for authentication of scripts. This will include the necessity to sign scripts with a developer's certificate, just as we do now with standard PixInsight modules.