Crashing during processing of queue

[Beep6581]

Originally reported on Google Code with ID 1788

When processing a queue containing many (70+) raw files, Raw Therapee crashes to desktop
after an apparently random number of images have been processed. In generally, it seems
that it is more likely to crash early on if you work in RT for a little while first.
If you simply resume after a crash, go to the queue, and resume processing, it seems
to last a bit longer before crashing.

Note that processing this many files in the queue is a necessary part of my workflow.
I do microphotography and focus stacking - dealing with hundreds of images is not unusual.
Unfortunately, this bug makes it rather bothersome to do, having to restart RT and
resume processing the queue 3-4 times before the images are fully processed.

There are no error messages reported. This bug has existed for as long as I can remember,
back all the way to some version of RT 3. I am currently using the newest version of
RT, built today from the source - but I normally use the officially released binaries
and the issue is equally bothersome in all cases.

Issue 1383 seems to be exactly the problem, except it's been marked as fixed. I continue
to experience the same symptoms.

Since I have the source and software necessary to build, but am not entirely sure what
I am doing (not much of a desktop app developer, I'm afraid), someone will have to
walk me through building a debug version so that I can get a stack trace or error codes
of some sort.

I am processing raw files from a Canon 7D camera (.cr2 extension). The issue also existed
with a Rebel T2i (same raw file format).

Here is a link to a sample raw file and accompanying .pp3 file: http://filebin.net/jp9lm3j8gs

To simulate my workflow, you can make 200 duplicates of these files with unique names,
add them to the queue, and attempt to process them.

Branch: default
Version: 4.0.10.4
Changeset: 50973592b058
Compiler: gcc 4.5.2
Processor: undefined
System: Windows
Bit depth: 64 bits
Gtkmm: V2.22.0
Build type: Release
Build flags:  -march=native -fopenmp -O3 -DNDEBUG
Link flags:   -march=native
OpenMP support: ON
MMAP support: ON

Win7-64bit SP1
8 gigs ram
Intel Core i7-2630QM

The issue also existed when I was running WinXP-32bit on a lower end machine.

Operating system (e.g. winXP-32bit, Ubuntu-11.10-64bit):

Reported by rylee.isitt on 2013-03-18 04:16:07

[Beep6581]

Scribble, thanks a lot for your test.

As said, this was only a build, no package. I cloned the latest revision, made a generic
build and zipped the content of the release folder. Glad, that you got around the problem
with missing files.
Seems to be stable at your system. The difference between the version you used for
test and the version Michael used, is, that in your version also patch for Issue 1796
is included.

Concerning WB. Had a short look at the changes between .1 and .32 but didn't find a
change, which is responsible for the fix at first sight. Maybe other devs do know more.

Again, thank you very much!!!

Ingo

Reported by heckflosse@i-weyrich.de on 2013-03-26 16:18:05

[Beep6581]

As for the wb balance problem I 'll comment on my issue and let the wise 
ones worry about it.

While I was out shopping with my wife I converted 502 jpgs with the  rt 10.1 
build without a problem.  The history of this machine and D7000 RAW and jpgs 
is confusing as you probably remember from issue 1764.   Except for size I 
would think a jpg is a jpg and it wouldn't matter if it came from a Canon or 
NIkon. But you never know.

I'll be doing a large batch of real conversions for both WB and noise, 
possibly today.  We'll see how well those go

scribble

Sent: Tuesday, March 26, 2013 11:18 AM
To: scribble1@charter.net
Subject: Re: Issue 1788 in rawtherapee: Crashing during processing of queue

Reported by scribble1@charter.net on 2013-03-26 17:31:41

[Beep6581]

The real world test didn't go that well. After 103 conversions rt10.32 crashed. I was
running the HighISO default settings for noise reduction, WB corrections and .66EV
exposure correction.  At the time I was also running ImageJ.  But I had been doing
that for about 25 minutes before the crash. Total timing was 103 conversions in 42
min. Restarted RT and finished the last 12 with no problems.

Let me know if there is anything else I can do.

Reported by scribble1@charter.net on 2013-03-26 19:29:35

[Beep6581]

Seems that to get or not to get the crash is really random. If you like, please put
the queue (not necessarily RT) in background, the next time you process a lot of pictures
in the queue. At my system, it was more stable with queue in background and e.g. RT
file browser in foreground.

Thanks a lot for your efforts.

Ingo

Reported by heckflosse@i-weyrich.de on 2013-03-26 19:40:43

[Beep6581]

I'll let this issue open until I'm back from vacation.

Reported by heckflosse@i-weyrich.de on 2013-03-26 21:33:46

[Beep6581]

a few more data points

I crashed rt10.32 twice today. Each time I was working with files from the same directory
the queue was using to write files into. I was also doing the same thing during yesterday's
crash. Perhaps windows is prevent a queue write and causing a conflict.

Once I let the queue do its thing undisturbed by workomg with other directories, the
crashes stopped. However when I started to clean up my work space I found this written
8 times in the dos box.

(rawtherapee.exe:5088): Gtk-CRITICAL **: gtk_progress_set_percentage: 

assertion
`percentage >= 0 && percentage <= 1.0' failed

I have no idea what I was doing at the time. 

joel

Reported by scribble1@charter.net on 2013-03-28 17:50:32

[Beep6581]

Scribble, thanks a lot for the data points. Very interesting points. Will make some
tests. Can you give me information about the changeset of the version you used? It's
easier to make a clone with this information.

Ingo

Reported by heckflosse@i-weyrich.de on 2013-03-28 19:18:57

[Beep6581]

Here is what it says.  And I see now that I have the version off by 2. 
Memory, thy name is not scribble,

Branch: default
Version: 4.0.10.34
Changeset: efc995cc9f7e
Compiler: gcc 4.7.1
Processor: generic x86
System: Windows
Bit depth: 64 bits
Gtkmm: V2.22.0
Build type: Release
Build flags:  -mtune=generic -fopenmp -O3 -DNDEBUG  -mstackrealign
Link flags:   -mtune=generic
OpenMP support: ON
MMAP support: ON

Reported by scribble1@charter.net on 2013-03-28 21:37:27

[Beep6581]

@62: Please excuse, that I named you 'scribble'. It's not easy, to name everyone by
it's first name, especially when I don't know it. That's why I named you the way I
did (and maybe I forgot the concluding '1'). Sorry about that :(

Thank you for your informations :-)

Ingo

Reported by heckflosse@i-weyrich.de on 2013-03-28 22:03:29

[Beep6581]

I named me 'scribble'. Or rather the typists who had to decipher my 
handwriting whenever I gave them a letter or report that needed to become 
legible. Somewhere packed away I have a certificate they presented me at a 
company picnic honoring  my unique penmanship.

joel aka scribble

Reported by scribble1@charter.net on 2013-03-28 23:09:39

[Beep6581]

And I leod (www.leo.org) what joel means, great :-)))

Ingo aka heckflosse

Reported by heckflosse@i-weyrich.de on 2013-03-28 23:16:47

[Beep6581]

I haven't closed rt10.34 yet and it picked up a ninth error sitting there 
while I used other programs.

(rawtherapee.exe:5088): Gtk-CRITICAL **: gtk_progress_set_percentage: 
assertion
`percentage >= 0 && percentage <= 1.0' failed

(rawtherapee.exe:5088): Gtk-CRITICAL **: gtk_progress_set_percentage: 
assertion
`percentage >= 0 && percentage <= 1.0' failed

(rawtherapee.exe:5088): Gtk-CRITICAL **: gtk_progress_set_percentage: 
assertion
`percentage >= 0 && percentage <= 1.0' failed

(rawtherapee.exe:5088): Gtk-CRITICAL **: gtk_progress_set_percentage: 
assertion
`percentage >= 0 && percentage <= 1.0' failed

(rawtherapee.exe:5088): Gtk-CRITICAL **: gtk_progress_set_percentage: 
assertion
`percentage >= 0 && percentage <= 1.0' failed

(rawtherapee.exe:5088): Gtk-CRITICAL **: gtk_progress_set_percentage: 
assertion
`percentage >= 0 && percentage <= 1.0' failed

(rawtherapee.exe:5088): Gtk-CRITICAL **: gtk_progress_set_percentage: 
assertion
`percentage >= 0 && percentage <= 1.0' failed

(rawtherapee.exe:5088): Gtk-CRITICAL **: gtk_progress_set_percentage: 
assertion
`percentage >= 0 && percentage <= 1.0' failed

(rawtherapee.exe:5088): Gtk-CRITICAL **: gtk_box_pack: assertion 
`child->parent
== NULL' failed

Reported by scribble1@charter.net on 2013-03-28 23:21:11

[Beep6581]

Joel, thanks for your report! Sounds like the progress-bar gets some wrong values???

Ingo

Reported by heckflosse@i-weyrich.de on 2013-03-28 23:27:17

[Beep6581]

Issue 1845 has been merged into this issue.

Reported by entertheyoni on 2013-04-16 20:44:29

[Beep6581]

Ingo

Downloaded the latest 4.0.10.69 RT from visual bakery
Loaded 114 D7000 NEF files from the the file browser to test stability
Converted directly to jpgs using the default profile
RT Crashed after 64 clean conversions leaving 50 NEF to be processed. 

Any other testing you would like me to do? 

Reported by scribble1@charter.net on 2013-04-19 15:59:05

[Beep6581]

Brought up RT and started to convert the last 50 NEFs. RT crashed after 16 conversions
RT queue was in front of other programs. I believe my task manager was in front the
 first time

Started to convert last 36 files. Switched to another directory. Brought up another
NEF  and worked on it during the last 36  conversions. No crash or  obvious problems

Reported by scribble1@charter.net on 2013-04-19 16:36:19

[Beep6581]

Cleaned out old pp3 files. Reloaded all 116 NEFs into queue from file browser. After
starting conversions switched RT to the show the NEF file I was working on during the
last set of conversions. All 116 NEFs converted without a crash.  

Reported by scribble1@charter.net on 2013-04-19 17:19:37

[Beep6581]

Don't want to conjure the RT demons, but that sounds promising :-)

Reported by heckflosse@i-weyrich.de on 2013-04-19 23:45:56

[Beep6581]

Not being a programmer this is only a guess but if you had a crash causing race condition
between closing the just converted thumbnail and loading the next NEF file that would
explain a lot

Reported by scribble1@charter.net on 2013-04-20 00:29:49

[Beep6581]

Issue 1841 has been merged into this issue.

Reported by entertheyoni on 2013-04-20 20:33:05

[Beep6581]

320 images developed without a crash! (Win7)

I'll try to publish a patch tomorrow, which will include improvements/bugfix as well.
;)

Reported by natureh.510 on 2013-05-12 23:52:09

[Beep6581]

Although I have been a bit preoccupied with moving, writing a thesis proposal, and attempting
to learn the guitar, I have to thank you all for looking into this, and it sounds like
you've made some good progress!

Eventually I will get around to testing the patch of course... but it looks like you're
on top of it already!

Reported by rylee.isitt on 2013-05-12 23:55:50

[Beep6581]

Here we go! ...and please read the warnings below.

I've googled and made a lot of tries during the paste week, with some success and some
problems still to solve. I learned a lot about Gtk's way of handling multi-threading,
but i don't claim to know everything, so please correct me if this is wrong:

1. It appears that Glib::RWLock seems to be able to produce deadlock because of a known
bug of some AMD processors. Strangely, i experienced negative values of the reader
count on my Core i7 too, without being able to find out why, so i've decided to create
a custom MyRWMutex (in guiutils.h) with debugging capabilities. Don't be affraid by
the code size, it's quite small and fast (for a non realtime application) in Release
build.

To enable the debug output (WARNING: redirect the std output to a file if you don't
want to wait "for hours"), available in Debug builds only, i've added a new boolean
CMake option "TRACE_MYRWMUTEX" (OFF by default).

2. There are 2 RWLock converted to MyRWMutex to protect some shared std:vectors. Before,
this was enabled for the Windows platform only, because Olli (iirc) didn't knew about
thread safety of this class on Linux, but i doubt that they're thread safe, and think
that all platform should protect those vectors more efficiently (protecting loop accesses).

So now you can chose to enable or disable this protetion with the new boolean CMake
option "PROTECT_VECTORS" (ON by default). Linux users can try with and without it.

3. The main loop of Gtk is structured like this:

while (TRUE) {
  handle_widgets_signals (...);  // Protected with automatic gdk_thread_enter/leave
  handle_timeout (...);          // Not protected
  handle_idle_callbacks (...);   // Not protected
}

There would be no problem of using g_idle_add *if and only if* there would be no access
of Gtk outside of such callbacks, which is not our case. So, since Gtk structures can
be read and/or written here and there, we _have to_ protect everything (i.e. the idle
and timeout callbacks too!).

To do so, you can use gdk_thread_add_idle and gdk_thread_add_timeout, which automatically
call gdk_thread_enter/leave. But for performance concern, i didn't chosed to use them,
and prefered to use our GThreadLock / GThreadUnlock (i.e. gdk_thread_enter/leave) class
where appropriated.

4. The problem with point #3 is that you can lock the GTK thread several time, it'll
be unlocked on the first occurence of gdk_thread_leave, which is a problem. So i've
replaced the standard Gtk lock (Glib:Mutex) by a Glib::RecMutex. It will handle a refCount
and unlock when getting back to zero, quite practical! (see main.c)

5. In Gtk's official documentation, it is recommended to flush all pending X server
event before calling gdk_thread_leave (if X is your backend), but only if an X warning/error
occures. Since i don't know how to track X events, i've added an automatic gdk_flush
in our custom gdk_thread_leave (see main.cc), but that's optional. I've added a new
boolean CMake option "AUTO_GDK_FLUSH" for that (OFF by default). So, if you have warning
related to X when using RT, try to enable this. I've experienced no slowdown on Windows,
but of course, we don't have X :) !

Here is a list of some other change i've made:

6. I've noticed that the file browser's filter "set" objects had concurrent R/W access
by several threads, so i've protected it with a simple Glib::Mutex.

7. I don't know how it comed in, by we end up with an asynchronous batch queue's thumbnail
creation, which represent a huge speed improvement! You can send 500 files to the queue
and restart RT with as much queued image in seconds! :), for all platforms! Also note
that i've set queue's thumbnail creation as low priority, their creation won't be lightning
fast but that's not necessary.

8. The batch queue ave now its own thumbnail size. So we end up with the following
options in the option file:
   ThumbnailSize      : file browser's thumbnails
   ThumbnailSizeTab   : editor tab's file browser's thumbnail
   ThumbnailSizeQueue : queue's thumbnail

9. I've added a new "SameThumbSize" option (default to True) in the option file. This
will use only one thumbnail size for both the file browser and the editor panel, which
avoid the reprocessing when switching from one to another :). Only "ThumbnailSize"
is modified in this case.

10. Cosmetic: thumbnails are now properly displayed (i.e. sized) when sent to the queue
from the file browser.

WARNINGS:
---------

11. I've experienced a lot of safe_keyfile problem (i.e. more than what we can actually
already experience). I think it's not related to this issue, but i have to look at
it before commting. So take care of this and use a different cache folder and navigate
to a non sensible image directory.

12. Despite the time i've spent on testing, there might still be some remaining deadlock,
but now we have a tool to track them more easily. If you experience such problem, just
report back the way to replicate the deadlock, i'll try to solve it.

KNOWN PROBLEMS:
---------------

13. For an unknown reason (perhaps a missing queue_draw?), some queue's thumbnail are
left empty when starting RT with a queue; all you have to do is zooming in/out to make
them appear.

14. I've had a nice "back to desktop" on Win32 (understand "severe crash"), but didn't
had time to investigate.

15. It an already existing problem, but just for the record, entering a directory with
image files and pp3 but without cached datas will render them slowly (synchronously
it seems). I don't plan to solve this.

This is not the final patch, i still have to clean it up.

Enjoy :)

PS: I've set myself as owner of this issue, i hope you don't mind heckflosse

Reported by natureh.510 on 2013-05-14 09:20:04

• Labels added: OpSys-All, Component-UI

[Beep6581]

No problem, Hombre :-)

Reported by heckflosse@i-weyrich.de on 2013-05-14 10:17:50

[Beep6581]

Hi Hombre,

Nice work!

> Before, this was enabled for the Windows platform only, because Olli (iirc) didn't

> knew about thread safety of this class on Linux
The problem was that GTK seems to thrown the events in different order or something
on e.g. Linux. My first patch with thread safety back then nailed everything down for
all platforms, but it caused many lockups on Linux, so I had to revert it and made
them all IFDEF on Windows.
Also there was trouble with lockups that very not immediately obvious, also on Windows,
when I made the locking too granular.

Reported by oduis@hotmail.com on 2013-05-14 11:00:45

[Beep6581]

Compiles and works fine. The speedup when putting pictures into the queue is really
great. Just one click and it's ready, fantastic!!! 
Start time with a queue filled with 488 pictures changed from 78 to 48 seconds! Is
there a possibility to further improve start time with filled queue? I ask, because
I saw, that only one core is used during the start process. Or maybe it can also be
done asynchronously?

I tested with release-build and didn't change any of your new switches.

Number 10 fixes Issue 1742.

Ingo

Reported by heckflosse@i-weyrich.de on 2013-05-14 11:52:35

[Beep6581]

Since I was about to blog about this and other issues if someone wants to send me a
build I'll test it out on my win 7 64bit machine. My email is scribble1@charter.net

Reported by scribble1@charter.net on 2013-05-14 16:24:01

[Beep6581]

Ingo, what is your processor?

What do you mean by "start time"? What you should compare is the time before RT opens
its main window. Thumbnail creation takes time, especially if you have big thumbnails.
The new mechanism create all the BatchQueueEntry before opening the window, synchronously
and single threaded, then compute the thumb images right after, i.e. when Gtk builds
the window and show it. Maybe we should delay thumbnails processing until the window
is opened?

I have a crash in release build, certainly because of an uninitialized value, so i've
made a test in Debug build:

WinXP/32, old Core2 Duo@2.5Ghz, 3 Gb RAM, starting RT in a directory of 120 images
and a saved queue of 357 images (raw, jpg, tiff): 43s from starting RT to being able
to select thumbnails in the file browser, which are still being processed.

Reported by natureh.510 on 2013-05-14 17:58:15

[Beep6581]

Hombre, processor is AMD Bulldozer 4 GHz 8 cores. The time I measured was the time before
RT opens the main window. Queue was filled with 488 pictures all set to default profile.
File-browser was pointed to a directory with 81 pictures, whereof all thumbnails have
been in RT-cache. Or to use your notation (but Release build):

Win7/64, AMD Bulldozer 8 cores@4.0Ghz, 32 Gb RAM, starting RT in a directory of 81
images and a saved queue of 488 images (raw): 48s from starting RT to being able to
select thumbnails in the file browser, which are still being processed.

Did you try with Default or Neutral profile?
Delaying thumbnail processing until window is opened sounds good!

:) Ingo

Reported by heckflosse@i-weyrich.de on 2013-05-14 19:11:58

[Beep6581]

Issue 1510 has been merged into this issue.

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

[Beep6581]

Another try, with a new patch and my personal computer, and with a Release build this
time:

Win7/64, Core i7 - 4 cores@2.2Ghz (auto overclocked), 12 Gb RAM, starting RT in a directory
of 168 raw files and a saved queue of 495 raw images with cached thumbnails: 7s from
starting RT to being able to select thumbnails in the file browser, which are still
being processed. Was 78s with the previous patch!!! That's what i call a speedup :)

The severe crash from comment #78.14 should be solved too.

Reported by natureh.510 on 2013-05-15 00:41:54

[Beep6581]

compiling!!!

Reported by michaelezra000 on 2013-05-15 01:07:02

[Beep6581]

Hombre, the start-up change for the queue is spectacular!

issues feedback:
I was able to get a complete hang without response by 
1. starting queue with 260 items (it was going very well) 
2. and then deleting item in the queue

I tested moving queue items to front and back of the queue and did not have an issue.
Even hang above is not easily reproducible. I suppose it is specific to timing with
other events in the executing queue.

Reported by michaelezra000 on 2013-05-15 01:20:41

[Beep6581]

The question is: was RT building thumbnails in the file browser while you were trying
to delete images in the queue? And how much have you waited before killing the application?

Reported by natureh.510 on 2013-05-15 01:28:42

[Beep6581]

Thumbnails were fully built.
I waited for a couple minutes.

Reported by michaelezra000 on 2013-05-15 01:39:31

[Beep6581]

Great!!! Starts in 3 seconds with a queue filled with 495 pics.

Reported by heckflosse@i-weyrich.de on 2013-05-15 09:56:56

[Beep6581]

Then please provide me a log of the RWMutex:
1. enable the TRACE_MYRWMUTEX cmake option 
2. start RT by redirecting the output to a file (>log.txt)
3. kill RT when it hang, the log file should end by a "waiting..." comment

Since this problem occurs randomly, i would suggest to restart RT before you get a
20Mb log file :)

Then zip it and send it to me by email.

Reported by natureh.510 on 2013-05-15 10:01:27

[Beep6581]

Will  TRACE_MYRWMUTEX work with RELWITHDEBINFO also or DEBUG only?

Reported by michaelezra000 on 2013-05-15 11:51:11

[Beep6581]

No, DEBUG only.

Reported by natureh.510 on 2013-05-15 12:01:25

[Beep6581]

Trying it to crash.

Starting Rt with many items in the queue. something to note is that in my tests queue
contains the same images multiple times.

I got this:
case 1

0x5fbb7c0/4660:lockRW / C:\Users\Michael\workspace\rawtherapee_default\rtgui\thumbbrowserentrybase.cc
: 383 - locking - W ++ new owner <<< ReaderCount: 0 - WriterCount: 1
0x5fbb7c0/4660 / unlocking - W -- new owner possible! <<< ReaderCount: 0 - WriterCount:
0
0x5fbb7c0/231 / unlocking - R (release) - ReaderCount: 0 -- new owner possible! >>>
ReaderCount: 0 - WriterCount: 0
0x5fbb7c0/231 / already unlocked by this object - R

(log stops here), crash

Case 2
File: C:\Users\Michael\workspace\rawtherapee_default\rtgui\bqentryupdater.cc, Line
104
Expression: (current.ow+1)*current.oh >= img->getW()*img->getH()

- crash

Reported by michaelezra000 on 2013-05-15 12:40:56

[Beep6581]

I need the full log files please.

For the second crash, had you some output in the DOS console as well?

Reported by natureh.510 on 2013-05-15 12:51:13

[Beep6581]

DOS console for crash 2
TIFFReadDirectory: Warning, I:\RT\RT_testing\RGB_test.tif: wrong data type 7 for "RichTIFFIPTC";
tag ignored.
TIFFReadDirectory: Warning, I:\RT\RT_testing\RGB_test.tif: wrong data type 7 for "RichTIFFIPTC";
tag ignored.
TIFFReadDirectory: Warning, I:\RT\RT_testing\RGB_test2.tif: wrong data type 7 for "RichTIFFIPTC";
tag ignored.
TIFFReadDirectory: Warning, I:\RT\RT_testing\RGB_test2.tif: wrong data type 7 for "RichTIFFIPTC";
tag ignored.
TIFFReadDirectory: Warning, I:\RT\RT_testing\tif-16-withalpha.tif: unknown field with
tag 37724 (0x935c) encountered.
TIFFReadDirectory: Warning, I:\RT\RT_testing\tif-16-withalpha.tif: unknown field with
tag 37724 (0x935c) encountered.
TIFFReadDirectory: Warning, I:\RT\RT_testing\tif-32-withalpha.tif: unknown field with
tag 37724 (0x935c) encountered.
TIFFReadDirectory: Warning, I:\RT\RT_testing\tif-32-withalpha.tif: unknown field with
tag 37724 (0x935c) encountered.
TIFFReadDirectory: Warning, I:\RT\RT_testing\tif-8-withalpha.tif: unknown field with
tag 37724 (0x935c) encountered.
TIFFReadDirectory: Warning, I:\RT\RT_testing\tif-8-withalpha.tif: unknown field with
tag 37724 (0x935c) encountered.
TIFFReadDirectory: Warning, I:\RT\RT_testing\YashasBDay2013-03-30_164207_NEX5r070-16.tif:
wrong data type 7 for "RichTIFFIPTC"; tag ignored.
TIFFReadDirectory: Warning, I:\RT\RT_testing\YashasBDay2013-03-30_164207_NEX5r070-16.tif:
wrong data type 7 for "RichTIFFIPTC"; tag ignored.
TIFFReadDirectory: Warning, I:\RT\RT_testing\YashasBDay2013-03-30_164207_NEX5r070.tif:
wrong data type 7 for "RichTIFFIPTC"; tag ignored.
TIFFReadDirectory: Warning, I:\RT\RT_testing\YashasBDay2013-03-30_164207_NEX5r070.tif:
wrong data type 7 for "RichTIFFIPTC"; tag ignored.
I:\RT\RT_testing\JDY_C056.MEF: Cannot use camera white balance.
Assertion failed!

Program: C:\Users\Michael\rt_builds\rt_default_DEBUG\DEBUG\rawtherapee_MYRWMUTEX6_trace.exe
File: C:\Users\Michael\workspace\rawtherapee_default\rtgui\bqentryupdater.cc, Line
104

Expression: (current.ow+1)*current.oh >= img->getW()*img->getH()

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

Reported by michaelezra000 on 2013-05-15 12:55:54

---

• _Attachment: log__crash-onstart-1_2.zip_

[Beep6581]

Reported by michaelezra000 on 2013-05-15 13:25:58

---

• _Attachment: log__3_Crash-onStart-with-emptyQ.zip_

[Beep6581]

On Wxp, crash when adding an image into the queue from editor (multi editor tabs mode):

Assertion failed: (current.ow+1)*current.oh >= img->getW()*img->getH(), file C:\
RTXMP\rawtherapee\rtgui\bqentryupdater.cc, line 104

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

Reported by gaaned92 on 2013-05-15 15:10:53

[Beep6581]

I've introduced a silly bug in "issue1788_6", which was the reason of all the reported
crash (let's hope so!). Please try this one.

Reported by natureh.510 on 2013-05-20 01:41:29

[Beep6581]

issue17788_7.patch applied

same crash as #99
Assertion failed: (current.ow+1)*current.oh >= img->getW()*img->getH(), file C:\
RTXMP\rawtherapee\rtgui\bqentryupdater.cc, line 104

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

Reported by gaaned92 on 2013-05-20 14:46:27

[Beep6581]

It should fix the issue.

Reported by natureh.510 on 2013-05-20 15:48:44

[Beep6581]

issue1788_8.patch could crash on some circumstance, from the Editor panel. The following
patch should be safer (at least it didn't crashed here).

Thanks for testing gaaned92 :)

Reported by natureh.510 on 2013-05-20 17:03:26

---

• _Attachment: issue1788_8b.patch_

[Beep6581]

issue1788_8b.patch applied
With this patch, I was able to procees a few files and put them in the queue. The queing
process seems more stable and faster. Without the patch, queing is much longer and
sometimes prevents the closing of editor panel (I complained already about that).

I have the impression that with previous patch thumbnails display was faster. Now it
seems to me very slow.
I will continue to test tomorrow.

Reported by gaaned92 on 2013-05-20 20:44:34

[Beep6581]

Reported by entertheyoni on 2013-05-20 22:47:50

• Blocking: #1818