It is rare but has been happening for a while when I delete a bunch of pictures, one being the currently shown and the others being the next or previous ones.
Happens after I delete the files on the lister or if I use this button on the image viewer:
After deleting, the crash comes when I try to navigate to the next/previous picture. The viewer usually detects correctly that some files were deleted and I haven't noticed anything that could prompt the crashes.
It has happened again moments ago and I looked at the DOpus.Minidumps folder and saw a bunch of 0 bytes DMP files, none for this occurrence.
I don't think these crashes ever generate a dump. My impression is that the dump generator does not cover the related code (if that is possible).
My best guess is that it is timing related. Moving to the next/previous picture too soon after issuing the delete command might catch the program at some inconsistent state.
It happened other times after I created this thread, but I have been burned so many times that now I wait a bit before moving to the next/previous and, for what it is worth, I haven't see it happen for a while.
The dump you sent today looks like a heap corruption, as you mentioned in the PM.
Are you using any scripts that interact with the viewer?
Does it happen if all viewer plugins are disabled?
Or with particular file types? (Not just ones that are displayed, but any the folder as well. A file in the folder may be skipped but could still cause problems during the attempt to display it before it is skipped.)
I disabled all plugins and restarted Opus. The usual crash when advancing forward after delete did not happen (I will keep testing), but a reproducible crash happened when using Show VIEWERCMD=goto,-10. This crash is different than the usual, as it is immediate, the Windows' dialog "restarting Opus" does not even appear, nor there is any crash dump or entry on the event log. The exit status was 0xc0000374.
Maybe related to the previously reported crash, maybe not, but try to reproduce:
What happened? The viewer showed you which picture after that?
To be more specific, the steps I took: in a folder with multiple folders, I enabled Flat View grouped, selected the first image, opened the viewer, advanced to the middle of the queue, used the button to delete the folder (step 1 from above), then pressed a button to move back (step 2 from above).
Either nothing (if I was within the first 10 images already, or if I had deleted the folder and there was nothing to go back to), or it jumped back to an earlier picture (if there was one to jump to).
Which of those details are required to make it crash on your end? If we can simplify it to the smallest number of required steps, that would be best for us, as it tells us where to look and where not to look.
Deleting on the lister instead of with a button also leads to a crash.
After repeating the crash some 10 times, it generated a crash dump now. No idea of how it decides to generate a dump. After the first dump, the next crash did not generate one, then after some more tries, another dump was created. I will send one to you by private message.
I reproduced it on a virtual machine with a fresh copy of Windows 10 and Opus 12.8. It took some tries, did not happen on the first ones, but it crashed once. No dump there either. It will probably give one out if I keep trying. Let me know if this is needed.
Please include details of what's in the folder so we can create the same thing, and exactly what you click/double-click etc. to open the viewer, delete the folder, move to the next picture (if applicable), etc.
Re the crash dump, it's another heap corruption, similar to before. I've done a review of the code that might be involved and did find one potential bug, but I think it would only happen if a script removed the current file from the file list, so it's probably not what you're running into here.
Opus 12.8 with default config after installing clicking "next" at every step.
Open lister.
Go to "/home".
Copy "Images" folder to somewhere (e.g. C:\Temp). Name it "A".
Open "A" and make copies of the files in there until there are 15 files in the folder. (Ctrl+C, Ctrl+V multiple times does it.)
Move back up. Copy "A" twice and name them "B" and "C".
Single left-click on the Flat View of the default toolbar; that enables grouped mode.
Select first file of "A".
Press "Enter". There should be 45 files in the queue.
Add a button for Show VIEWERCMD=goto,-10.
Use PgDn some 35 times, so the viewer should display a image from folder "C". (Does not seem to matter how you get there, just make the viewer show a file from folder C while all the 45 files are in the queue.)
Go to the lister and delete folders "B" and "C".
Go back to the viewer, left-click on the button created on step 9. Opus should crash now.
I reverted the VM to a clean state and tried again. With these steps, it crashed on the first try (and every other try after that). The main difference here is deleting both "B" and "C", which in my usual workflow does not happen, as I usually only delete one at a time, but I guess the bug sometimes still happens when only deleting one folder.
Many thanks! With that I was able to reproduce and fix the crash. The fix will be in 12.8.1 beta.
The crash would only occur if a command like Show VIEWERCMD=goto,-10 was used, and the image it jumped to was deleted/invalid. It could happen sometime after it was used, not always immediately. But it wouldn't happen if only the default next/prev commands were used and goto had never been used.
Do you think that will also cover the original issue, or are there potentially two issues here?
The crash is gone, but Show VIEWERCMD=goto,-10 after a delete is oddly not updating the displayed picture, even if the viewer's status bar shows that the current index number is changing.
If the picture you jump to was deleted, it will move to the next picture in the list, until it either finds the one you started on (whether deleted or not) or a picture that still exists.