Page MenuHome

2.93: Crash on system with a non-English locale
Closed, ResolvedPublicBUG


System Information
Operating system: macOS-11.4-arm64-arm-64bit 64 Bits
Graphics card: Apple M1 Apple 4.1 Metal - 71.6.4

Blender Version
Broken: version: 2.93.0, branch: master, commit date: 2021-06-02 11:21, hash: rB84da05a8b806
Worked: (newest version of Blender that worked as expected)

Short description of error
When I open first Blender on the system which the locale set to Korean, the program just shut down and report error message.

Exact steps for others to reproduce the error
Set system locale Korean, and just start Blender program at first time on the system.

When I started the program after changing system locale to English, the program worked normally. After that, I changed the locale of Blender program to Korean inside the program, then error didn't occur.
And I closed the program, and changed again the system locale to Korean, and open Blender program, and the error didn't occur. I guess the error occurs only when first open the Blender program that is not initialized on Korean system.

Crash report from T88845:

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
Ankit Meel (ankitm) renamed this task from 2.93: Crash on system with Korean locale to 2.93: Crash on system with a non-English locale.Jun 6 2021, 9:52 AM
Han (hannoeru) added a subscriber: Han (hannoeru).EditedJun 6 2021, 10:28 AM

Hi, I'm new to blender and also have this problem when I open blender in my Intel MBP, my locale is set to Japanese.
It works well when I was in 2.83 but crashed in 2.93.

I also deleted ~/Library/Application Support/Blender/ and tried to open it again, but it didn't work.

Ankit Meel (ankitm) changed the task status from Needs Information from User to Confirmed.Jun 6 2021, 10:52 AM
Ankit Meel (ankitm) updated the task description. (Show Details)

Try this:

  • Set system locale to Korean
  • Rename ~/Library/Application Support/Blender/ to something else, like Blender_backup
  • Open Blender.

Does the crash happen ?

Sorry, I tried reproduce the error by reinstalling the app after removing the app with App Cleaner, however I couldn't reproduce the error.
I checked ~/Library/Application Support/Blender/ is deleted after removing the app. After rebooting, and reinstalling, I opened the app on the system with Korean locale, but the error did not occur.

Ankit Meel (ankitm) updated the task description. (Show Details)

So it could be that settings saved in previous versions of Blender is causing the error in the new one.

Han (hannoeru) added a comment.EditedJun 6 2021, 11:44 AM

Here is what I tried:

  • Run AppCleaner to remove blender.
  • Run sudo rm -rf ~/Library/Application Support/Blender/, and reboot.
  • Reinstall blender 2.93

Still not works

  • Download blender 2.83
  • Replace blender in the Application folder


OS: macOS 11.4 (20F71)
Crash report:

Ankit Meel (ankitm) changed the task status from Confirmed to Needs Information from User.EditedJun 6 2021, 2:16 PM

We need steps to create the error locally, not the steps to make blender launch.
They'd look like:

  • set locale to Korean
  • Delete this folder
  • run this version
  • run that version
  • Now blender crashes


delete ~/Library/Application Support/Blender/ and launch 2.93 still not work.
here's the crash log.

however, i changed locale to english and launch 2.93, it launched.
If you checked successfully run it in English locale and revert it back to Korean locale, it even still works.

Ankit Meel (ankitm) changed the task status from Needs Information from User to Confirmed.EditedJun 7 2021, 4:57 PM

I cannot redo it on macOS mojave. All three reports are on Big Sur 11.4. (the OS is not mentioned in one comment)

I tried to localize in English and it works, but when I try to reset it to Italian it starts crashing again

@Ankit Meel (ankitm) Not sure how your patch could fix anything? It's just offsetting the start of the try block, nothing else... I would not expect setting the location of the MO's to be at the origin of that issue? Or do you think that the default constructor for boost::locale::generator is the crashing call here? Too bad there's no full backtrace identifying the calling line...

Since this happens when using default (system, empty string) locale, I'd rather look at the exception we have for OSX currently, the #if defined(__APPLE__) && !defined(WITH_HEADLESS) && !defined(WITH_GHOST_SDL), and check if this is called, what kind of string it returns, and if removing this special case helps, etc.

We could also try a different boost::locale::localization_backend_manager option, like "std" e.g.

In any case we need a dev able to reproduce the issue first though. @Sebastián Barschkis (sebbas) maybe you'd have some time and proper hardware/OSX version at hands?

Ankit Meel (ankitm) added a comment.EditedJun 15 2021, 1:15 PM

I was under impression that boost::locale::conv::conversion_error is caught by std::exception(.. turns out not). So the exception should be originating from the code outside try block.

I'll abandon the patch.

diff --git a/intern/locale/boost_locale_wrapper.cpp b/intern/locale/boost_locale_wrapper.cpp
index 73433fe7c5e..b4301793e75 100644
--- a/intern/locale/boost_locale_wrapper.cpp
+++ b/intern/locale/boost_locale_wrapper.cpp
@@ -87,6 +87,7 @@ void bl_locale_set(const char *locale)
   // gen.set_default_messages_domain(default_domain);
   try {
+    throw boost::locale::conv::conversion_error();
     if (locale && locale[0]) {
       _locale = gen(locale);
@@ -120,6 +121,9 @@ void bl_locale_set(const char *locale)
   catch (std::exception const &e) {
     std::cout << "bl_locale_set(" << locale << "): " << e.what() << " \n";
+  catch (std::runtime_error const &e){
+    std::cout << "**bl_locale_set(" << locale << "): " << e.what() << " \n";
+  }
 const char *bl_locale_get(void)
**bl_locale_set(): Conversion failed 
**bl_locale_set(en_US.UTF-8): Conversion failed


@Bastien Montagne (mont29) A build with something like D11806: Add logging to debug T88877 applied can be run by bug reporters to get some information.
In any case, an exception handler should be added anyway IMHO.

Oh I can do it now after setting language to en_IN and in lite build (+ boost + international), offending line is _locale = gen(locale_osx.c_str());

#0  __pthread_kill ()
#1  pthread_kill ()
#2  abort ()
#3  abort_message ()
#4  default_terminate_handler() ()
#5  _objc_terminate() ()
#6  std::__terminate(void (*)()) ()
#7  __cxxabiv1::failed_throw(__cxxabiv1::__cxa_exception*) ()
#8  __cxa_throw ()
#9  std::__1::basic_string<wchar_t, std::__1::char_traits<wchar_t>, std::__1::allocator<wchar_t> > boost::locale::conv::impl::iconverter_base::real_convert<wchar_t, char>(char const*, char const*) ()
#10 boost::locale::conv::impl::iconv_to_utf<wchar_t>::convert(char const*, char const*) ()
#11 std::__1::basic_string<wchar_t, std::__1::char_traits<wchar_t>, std::__1::allocator<wchar_t> > boost::locale::conv::impl::convert_to<wchar_t>(char const*, char const*, char const*, boost::locale::conv::method_type) ()
#12 std::__1::basic_string<wchar_t, std::__1::char_traits<wchar_t>, std::__1::allocator<wchar_t> > boost::locale::conv::to_utf<wchar_t>(char const*, char const*, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, boost::locale::conv::method_type) ()
#13 boost::locale::util::simple_converter_impl::simple_converter_impl(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) ()
#14 boost::locale::util::create_simple_codecvt(std::__1::locale const&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, unsigned int) ()
#15 boost::locale::impl_posix::create_codecvt(std::__1::locale const&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, unsigned int) ()
#16 boost::locale::impl_posix::posix_localization_backend::install(std::__1::locale const&, unsigned int, unsigned int) ()
#17 boost::locale::localization_backend_manager::impl::actual_backend::install(std::__1::locale const&, unsigned int, unsigned int) ()
#18 boost::locale::generator::generate(std::__1::locale const&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) const ()
#19 boost::locale::generator::generate(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) const ()
#20 boost::locale::generator::operator()(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) const at lib/darwin/boost/include/boost/locale/generator.hpp:203
#21 ::bl_locale_set(const unsigned char *) at blender/intern/locale/boost_locale_wrapper.cpp:96
#22 BLT_lang_set at blender/source/blender/blentranslation/intern/blt_lang.c:280
#23 WM_init at blender/source/blender/windowmanager/intern/wm_init_exit.c:268
#24 main at blender/source/creator/creator.c:505
#25 start ()
locale	const unsigned char *	""	0x000000010b279d00
gen	boost::locale::generator	
_locale	std::__1::locale	
e	const std::exception &	0x00001fffddf7fc78
locale_osx	std::__1::string	"en_IN.UTF-8"	
default_domain	std::__1::string	"blender"	
facet_global	const char_message_facet *	NULL	0x0000000000000000
locale_global	std::__1::locale	
locale_str	std::__1::string	""	
messages_path	std::__1::string	"/Users/ankitkumar/blender-build/build_darwin_lite/bin/Debug/"

In my case, result of NSLocale.localeIdentifier() is wrong in
My locale must be ko_KR. but NSLocale.localeIdentifier() returns ko-Kore_KR.

changed some code in for testing.
then it is ok for me.

it needs fixing from developers.

// get current locale
const char *osx_user_locale()
  NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
  CFLocaleRef myCFLocale = CFLocaleCopyCurrent();
  NSLocale *myNSLocale = (NSLocale *)myCFLocale;
  [myNSLocale autorelease];
  //NSString *nsIdentifier = [myNSLocale localeIdentifier];
    NSString *a = [myNSLocale languageCode];
    NSString *b = [myNSLocale countryCode];
    NSString *f = [a stringByAppendingString:@"_"];
    f = [f stringByAppendingString:b];
  user_locale = ::strdup([f UTF8String]);
  [pool drain];

  return user_locale;

It seems that the cause of the crash has been investigated as above.

Can I know when a fix will be released?

It seems that the cause of the crash has been investigated as above.

Can I know when a fix will be released?

It seems they plan to fix this on Blender 3.0, it says Administrator moved this task to 3.0

Current proposed patch is D13019: Fix T88877: 2.93: Crash on recent OSX with a non-English locale.. If you are using OSX and can compile Blender, it would be great if you could test it and confirm it fixes the issue.

Patch will be committed to 3.0 branch yes, and then backported to 2.93 (and probably 2.83 too) in the coming weeks.

Ankit Meel (ankitm) changed the subtype of this task from "Report" to "Bug".Oct 29 2021, 1:39 AM