RT crashes when trying to open processing queue

(Ingo Weyrich) #21

@HIRAM can you try this patch please?

diff --git a/rtgui/multilangmgr.cc b/rtgui/multilangmgr.cc
index b4896d69..23bf4c45 100644
--- a/rtgui/multilangmgr.cc
+++ b/rtgui/multilangmgr.cc
@@ -117,9 +117,13 @@ void setGtkLanguage(const Glib::ustring &language)
     auto l = localeToLang.getLocale(language);
 #ifdef WIN32
     putenv(("LANG=" + l).c_str());
+#ifdef __APPLE__
+    setenv("LANG", (l + ".UTF-8").c_str(), true);
     setenv("LANG", l.c_str(), true);


@heckflosse, still have the problems and crash when switching to queue.


I even tried
#elifdef __APPLE__
{;} //do nothing
but always the same crash…

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libcairomm-1.0.1.dylib        	0x000000010a47efe0 Cairo::Context::set_source(Cairo::RefPtr<Cairo::Surface> const&, double, double) + 16 (surface.h:364)
1   rawtherapee-bin               	0x00000001087262ab ThumbBrowserEntryBase::draw(Cairo::RefPtr<Cairo::Context>) + 699
2   rawtherapee-bin               	0x0000000108723081 ThumbBrowserBase::Internal::on_draw(Cairo::RefPtr<Cairo::Context> const&) + 369
3   libgtkmm-3.0.1.dylib          	0x0000000109726f2f Gtk::Widget_Class::draw_callback(_GtkWidget*, _cairo*) + 175
4   libgtk-3.0.dylib              	0x0000000109e1971c gtk_widget_draw_internal + 364 (gtkwidget.c:7027)
5   libgtk-3.0.dylib              	0x0000000109c35e9a gtk_container_propagate_draw + 362 (gtkcontainer.c:3840)
6   libgtk-3.0.dylib              	0x0000000109c36443 gtk_container_draw + 147 (gtkcontainer.c:3655)


I’m not a developer, so my idea is probably naïve, but let go: Is it not possible just to take the corresponding parts of the code from RT 4.2 which had overcome this problem, unlike earlier versions?

(Ingo Weyrich) #25

That sounds good, but

  1. rt 4.2 used gtk2 while rt 5.3 uses gtk3
  2. we didn’t yet indentify the culprit


I have no idea what gtk means, but I have a version of RT 4.2 that has gtk3 in the name. That does not solve problem 2. of course. But should it not have something to do with non-ASCII characters in the Path, since also 5.3 works if the image file is on the Desktop?


That seems to correspond to this code:

Now, when backBuffer is NULL or garbage that will crash. Can that happen? After all, that case is checked a few lines earlier? Yes, it can, as updateBackBuffer returns early when there is no parent:

If any of that is relevant I don’t know. But it might be a start for some further debugging.

Edit: I might have been wrong there. It could be that backbuffer is fine but that it has no surface set.

(Flössie) #28

Thanks, @houz, for looking into it. Our current problem is, why locales are so difficult (under macOS). I would be really glad, if you could share some thoughts on the issue.



Interesting @houz
Perhaps having a weird combo like en_DE causes problems with backBuffer or surface?