1. agriggio Avatar agriggio
  2. ART
  3. ART
  4. Issues

crash on spotremoval branch

Issue #40 resolved
leclerc created an issue

it seems that a right click on a spot causes the software to crash

I'm running manjaro Linux on a mac pro 2011

Comments (21)

  3. leclerc reporter

    update: it seems that the update of the master version on AUR, has solved the problem of the crash on the spotremoval version (???) and indeed, a right click on a spot allows to delete it... I continue my tests, and sorry for the false alarm if ever everything works...!

  4. agriggio repo owner

    thanks for the info. if possible, please make sure you always test with the latest version, especially when new features are in the works, because the code might change rapidly…

  5. leclerc reporter

    hi Alberto, strangely, the bug did appear on the last version of the spotremoval branch! it disappeared when I compiled the master version! how is this possible?

  6. Former user Account Deleted

    I'm somewhat curious: the spotremoval branch is not jet merged to master…so this feature should not be there when you build from master?!

  7. leclerc reporter

    yes this feature is not in master. i'm just saying that maybe it's a coincidence, the bug on spotremoval disappeared after compiling the last version of master (but that has nothing to do with spotremoval)... it's very curious.

  9. Daniel Catalina

    Don’t forget that sometimes using the same cache folder between versions can cause strange things (like crashes). I always do that first when experiencing crashes …

  11. Daniel Catalina

    I can reproduce it with the attached file. @europlatus you have issues also with dng files? Or with other type of files?

  14. Daniel Catalina

    @agriggio I found out what the problem is.

    When a spot is deleted CropWindow calls updateCursor which will call Spot::getCursor.

    At this point, activeSpot is -1 and when at line 513 spots.at(activeSpot) is called an exception is triggered:

    unhandled exception (type std::exception) in signal handler:
what: vector::_M_range_check: __n (which is 18446744073709551615) >= this->size() (which is 35)

    I am not very sure about the fix. The temptation is to make Spot::getCursor return CSCrosshair immediately if activeSpot is -1.

    What do you think about it?

    ‌

    ‌

  15. agriggio repo owner

    I agree, I would just change this:

            if (objectID >= 3 && objectID <= 6) {

    to this:

            if (objectID >= 3 && objectID <= 6 && activeSpot != -1) {

    Thanks for the analysis! I’ll push the above fix if you agree

  18. europlatus

    @Daniel Catalina Looks like the issue is fixed, but just in case you’re still wondering, I was working on a CR2 file. Thanks guys!

  19. Daniel Catalina

    @europlatus would be great if you can check your use case and report.

    While I found out what was wrong with the file leclerc attached, I am not sure why this did not happen with the files and workflow I usually use. The one big suspect is that a lot of masking was done in his processing. I am still to scared of the concept to try the local modules myself :)

  20. agriggio repo owner

    it’s most likely related to concurrency, so probably it didn't happen if your processing was fast enough (I'm just speculating though)

  21. europlatus

    This happened on several CR2 files I was working on. The images are scanned negatives that I’m “developing” so there are quite a lot of masks and spot removals being used. Right-clicking on a spot would instantly crash the program. If you want me to try anything out, I’m happy to. The crash seems to lose all the edits of the current tool being used, but not all edits to the image. I’m on ART 1.2-89, which is probably one or two versions before the fix was pushed.

  22. Log in to comment
Assignee
–
Type
bug
Priority
major
Status
resolved
Votes
1
Watchers
4