search

Beep6581 / RawTherapee

A powerful cross-platform raw photo processing program
https://rawtherapee.com
GNU General Public License v3.0
2.77k stars 313 forks source link

Cannot save image or PP3 from Image Editor #1778

Closed Beep6581 closed 8 years ago

Beep6581 commented 9 years ago

Originally reported on Google Code with ID 1794

I ran ./rt_default_release/rawtherapee, multiple editor tabs mode.
Opened a JPEG image on an attached USB stick, edited it, and tried to save. Both Ctrl+S
and clicking on the save icon don't do anything.
Clicking on the Save PP3 icon doesn't do anything.

This shows up in the console every time I try to save the image:
(rawtherapee:17831): glibmm-CRITICAL **: 
unhandled exception (type Glib::Error) in signal handler:
domain: gtk-file-chooser-error-quark
code  : 2
what  : Shortcut file:///run/media/drslony/UDISK already exists

Ctrl+Shift+S works.
Ctrl+Q works.
Adding the image to queue from the File Browser works.

Reported by entertheyoni on 2013-03-19 01:48:48

Beep6581 commented 9 years ago 
Are you editing an image that is located on the root of your USB disk perhaps?

Reported by natureh.510 on 2013-03-19 02:51:44

Beep6581 commented 9 years ago 
Yes, automounted by KDE.

Reported by entertheyoni on 2013-03-19 08:22:58

Beep6581 commented 9 years ago 
Following up on a request from DrSlony, here's my experience.  I've been using 4.0.9.185
for a while now, without problems (other than the Edge-enable bug being discussed in
the bug-report forum) on Fuji RAF files (typically about 13Mb, expanding to about 72
Mb TIFs).

But when I tried 4.0.10.1 I immediately discovered that the Save current image icon
in the bottom left-hand corner of the window no longer works; if I single-click or
double-click on it, the program ignores me, but if I type ctrl_S the program immediately
crashes (no dialog or warning; just kaboom!) -- even if I do nothing but open the RAW
file and then immediately try to save the TIF output!

Ctrl_shift_S works OK, however.

I'm running Windows 7 Professional 64-bit SP1 on an Intel i7 CPU, with 5.99 Gb RAM,
and everything (Raw Therapee and image files) is resident on the C drive (over 500
Gb free!), so I doubt I'm running out of space. Raw Therapee executes out of C:\Program
Files\RawTherapeeV40.  Usually I open files from and save files to, the desktop.

Just to make absolutely sure, I uninstalled 4.0.9.185, reinstalled 4.1.10.1 from the
desktop, and opened a RAF from the desktop.  Same thing happened.  (I tried again after
disabling my antivirus software -- that makes no difference.)

Windows throws up an error window that says:

Microsoft Visual C++ Runtime Library
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

I click on OK; Microshaft futzes around for a while and then wants me to send three
files to them (I didn't):

WER17E1.tmp.WERInternalMetadata.xml
WER2FF4.tmp.appcompat.txt
WER310E.tmp.mdmp

If you want to see them, please send me a private email address that I can use to send
them to you (e.g. set up a yahoo mail account for one-time use); I'm nervous about
posting info about the innards of my computer on the web for every hacker to see...

If there's something more you need to see, please ask. And I'm happy to run tests for
you, but please note: I have no compiler and no expertise, so you would have to supply
me with Windows x64 executables if you want me to do that.

Hope this helps,

Martin

Reported by daedalus333 on 2013-03-20 02:50:49

Beep6581 commented 9 years ago 
Thanks for the report, but i think that i've identified the problem: Gtk don't want
redudant places to be added to the Quick link of the Save as dialog box, so the problem
occures only when the edited files are in the root of a disk storage. I'll fix that
soon soon.

Reported by natureh.510 on 2013-03-20 09:51:27

Beep6581 commented 9 years ago 
Actually this problem looks more and more bizarre, the more I experiment with it.

In normal use, I never try to open/save images from the root of C: or any other drive.
(They are too hard to find there.) All my reports till now have been based on opening
files in the desktop (which is a folder several layers down from the root) or in a
folder on the desktop (ditto), and then trying to save them on the desktop. And 4.0.10.xx
has always crashed when I hit ctrl-S, etc.

But in despair, I've just reinstalled 4.0.10.36 and tried again. Yup, same behavior.
 Then I tried opening the same file on the G: USB drive, several layers down from its
root.  To my great surprise, I could save to either the G: drive or to the C: drive.
To my even greater surprise, I found that NOW if I open the file on the C: drive (several
layers down from the root)I can save it -- to the C drive or anywhere else!  Apparently,
the computer has "learned" how...

That learned behavior survives repeated uninstall/reinstall cycles. Apparently something
gets left behind in the registry -- or in the RT program folder -- that is picked up
by the next reinstallation.

However, if the image file was opened from the C: root, I still can't save it anywhere.
(Not a problem for me! At least now I have a workaround for using 4.0.10.xx.)  I'll
let you guys figure out what's going on; it's 2:55 am over here...

Martin

Reported by daedalus333 on 2013-03-30 08:55:17

Beep6581 commented 9 years ago

Reported by entertheyoni on 2013-03-30 21:26:21

Beep6581 commented 9 years ago 
As reported in the OP: "unhandled exception (type Glib::Error) in signal handler", i've
enclosed the add_shortcut_folder functions in a try catch statement, since adding an
already existing path throw an exception.

But unfortunately, i can't make it work on Windows. I'm near an total nood in Exceptions
handling, so i'de like someone to help me in testing and debug the following patch.
The error says that it's a Glib::Error, but it might be Gtk::FileChooserError in fact,
i don't really know. Linux users may have more luck that this patch will work. If so,
please report the debug output.

I use Gcc4.51. From what i've Googled, exceptions thrown in a dll can't be properly
unwinded outside of that dll with MinGW, so the solution for most crashs caused by
Exception could be to statically link all dll on Windows.

Reported by natureh.510 on 2013-03-31 14:22:32

Beep6581 commented 9 years ago 
Hombre, is it possible to query list of already present shortcuts, and only if absent,
then add?

Reported by michaelezra000 on 2013-03-31 14:54:56

Beep6581 commented 9 years ago 
Probably, but that's what add_shortcut_folder does, we only have to properly handle
the thrown exception. Let's try the clean solution first.

Reported by natureh.510 on 2013-03-31 15:05:48

Beep6581 commented 9 years ago 
Hi Hombre, you refer to "this patch" but I don't see one attached, where can I find
it?

Reported by entertheyoni on 2013-03-31 21:13:01

Beep6581 commented 9 years ago 
Ahem...

Reported by natureh.510 on 2013-03-31 21:45:28

Beep6581 commented 9 years ago 
So, does it works on Linux? Any advice regarding Exception handling on Windows?

Reported by natureh.510 on 2013-04-01 17:03:54

Beep6581 commented 9 years ago 
Works fine for me now Hombre, thank you!

Reported by entertheyoni on 2013-04-02 22:58:32

Beep6581 commented 9 years ago 
This appears in the console every time I hit Ctrl+s

Begin setImagePath
Gtk::FileChooserError catch: Path already exist!
End setImagePath

Reported by entertheyoni on 2013-04-02 22:59:46

Beep6581 commented 9 years ago 
Thanks, that's what i wished to know :). I'll remove these debug output before committing.

Is Gtkmm dynamically or statically linked with your build?

Reported by natureh.510 on 2013-04-02 23:02:16

Beep6581 commented 9 years ago 
I would guess dynamically, but how can I be sure?

Reported by entertheyoni on 2013-04-02 23:05:11

Beep6581 commented 9 years ago 
I don't know. Maybe you have a tool to check the dependencies of an executable file?

Reported by natureh.510 on 2013-04-02 23:20:41

Beep6581 commented 9 years ago 
ldd shows them, and I didn't specify -static, so it seems they're dynamically linked.

Reported by entertheyoni on 2013-04-02 23:32:30

Beep6581 commented 9 years ago 
Here is a new version of the patch. For Linux and Apple systems, the exceptions are
properly caught, but for Windows i've made a workaround: it checks if the path is a
root drive, and if so, doesn't try to add the shortcut.

Of course, handling exceptions would be better, since i'm not sure that the workaround
is bullet proof...

Reported by natureh.510 on 2013-04-04 23:12:53

Beep6581 commented 9 years ago 
I'll commit tomorrow.

Reported by natureh.510 on 2013-04-05 17:31:56

Beep6581 commented 9 years ago 
My "tomorrow" was 5 days... ;]

Reported by entertheyoni on 2013-04-09 18:52:16

Beep6581 commented 9 years ago 
You're speaking of PlayRaw 31, right ? :]

Yeah, this issue went under my radar, thanks for reporting. Committed to default. Please
leave this issue opened since one have to make a clean fix for Windows, i.e. explaining
how to catch exceptions from dlls.

Reported by natureh.510 on 2013-04-09 23:14:50

Beep6581 commented 9 years ago 
No, PR was delayed because I requested different photos from those I got in the first
two e-mails. I was referring to issue 1801 :]

Reported by entertheyoni on 2013-04-10 10:18:52

Beep6581 commented 9 years ago

Reported by entertheyoni on 2013-04-10 10:21:46

Beep6581 commented 9 years ago

Reported by natureh.510 on 2013-04-10 10:22:19

Beep6581 commented 9 years ago 
Here is a new patch adding the Desktop folder to the list of trapped folder. See http://www.rawtherapee.com/forum/viewtopic.php?f=3&t=4693

Reported by natureh.510 on 2013-08-06 19:29:46

Beep6581 commented 9 years ago 
Hombre, I'd like to help testing here on Linux but RT works unpatched for me. Your patch,
however, applies and compiles nicely and doesn't hurt my RT in anyway :-)

Reported by sofie@birkagatan.com on 2013-08-07 06:50:21

Beep6581 commented 9 years ago 
Thanks, it's better to have it confirmed ;)

Reported by natureh.510 on 2013-08-07 11:41:06

Beep6581 commented 9 years ago 
Patch committed. Issue remains opened until a clean solution is found (i.e. handling
exceptions properly).

Reported by natureh.510 on 2013-08-11 14:05:41