Crash due to i18n translation at startup on OSX Mojave (versionning code, Data names translation enabled) #57066

New Issue

Roland Terver · 2018-10-04T18:56:26+02:00

Roland Terver commented

2018-10-04 18:56:26 +02:00

System Information
Macbook pro Retina 13 inch late 2012
Intel HD graphics 4000

Blender Version
2.79 (2.79 2018-10-04, Blender Foundation)

Short description of error
Blender crashes at start

Exact steps for others to reproduce the error
Save user preferences with translation to French enabled. Close and restart Blender.

Blender 2_79 crash.rtf

**System Information** Macbook pro Retina 13 inch late 2012 Intel HD graphics 4000 **Blender Version** 2.79 (2.79 2018-10-04, Blender Foundation) **Short description of error** Blender crashes at start **Exact steps for others to reproduce the error** Save user preferences with translation to French enabled. Close and restart Blender. [Blender 2_79 crash.rtf](https://archive.blender.org/developer/F4937118/Blender_2_79_crash.rtf)

Roland Terver commented

2018-10-04 18:56:26 +02:00

Added subscriber: @Warun

blender-admin commented

2018-10-04 18:56:26 +02:00

#57822 was marked as duplicate of this issue

blender-admin commented

2018-10-04 18:56:26 +02:00

#57353 was marked as duplicate of this issue

Brecht Van Lommel commented

2018-10-04 19:14:46 +02:00

Added subscriber: @brecht

Bastien Montagne was assigned by Brecht Van Lommel

2018-10-04 19:14:46 +02:00

Brecht Van Lommel commented

2018-10-04 19:14:46 +02:00

On Linux I don't get a crash, but valgrind shows a backtrace in the locale code as well:

==22684== Conditional jump or move depends on uninitialised value(s)
==22684==    at 0xC4135B3: __wmemchr_avx2 (memchr-avx2.S:240)
==22684==    by 0xCD7C2DF: std::__cxx11::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::find(wchar_t, unsigned long) const (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.25)
==22684==    by 0x387D43E: boost::locale::gnu_gettext::mo_message<wchar_t>::load_file(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, int, boost::function<std::vector<char, std::allocator<char> > (std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)> const&) (in /home/brecht/dev/build_linux/bin/blender)
==22684==    by 0x387FE43: boost::locale::gnu_gettext::mo_message<wchar_t>::mo_message(boost::locale::gnu_gettext::messages_info const&) (in /home/brecht/dev/build_linux/bin/blender)
==22684==    by 0x38749C0: boost::locale::message_format<wchar_t>* boost::locale::gnu_gettext::create_messages_facet<wchar_t>(boost::locale::gnu_gettext::messages_info const&) (in /home/brecht/dev/build_linux/bin/blender)
==22684==    by 0x386C56F: boost::locale::impl_posix::posix_localization_backend::install(std::locale const&, unsigned int, unsigned int) (in /home/brecht/dev/build_linux/bin/blender)
==22684==    by 0x38680C8: boost::locale::localization_backend_manager::impl::actual_backend::install(std::locale const&, unsigned int, unsigned int) (in /home/brecht/dev/build_linux/bin/blender)
==22684==    by 0x386387B: boost::locale::generator::generate(std::locale const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) const (in /home/brecht/dev/build_linux/bin/blender)
==22684==    by 0x3863FE6: boost::locale::generator::generate(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) const (in /home/brecht/dev/build_linux/bin/blender)
==22684==    by 0x2B8641C: operator() (generator.hpp:203)
==22684==    by 0x2B8641C: bl_locale_set (boost_locale_wrapper.cpp:64)
==22684==    by 0x251F735: BLT_lang_set (blt_lang.c:278)
==22684==    by 0x179EBF8: WM_init (wm_init_exit.c:200)

On Linux I don't get a crash, but valgrind shows a backtrace in the locale code as well: ``` ==22684== Conditional jump or move depends on uninitialised value(s) ==22684== at 0xC4135B3: __wmemchr_avx2 (memchr-avx2.S:240) ==22684== by 0xCD7C2DF: std::__cxx11::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::find(wchar_t, unsigned long) const (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.25) ==22684== by 0x387D43E: boost::locale::gnu_gettext::mo_message<wchar_t>::load_file(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, int, boost::function<std::vector<char, std::allocator<char> > (std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)> const&) (in /home/brecht/dev/build_linux/bin/blender) ==22684== by 0x387FE43: boost::locale::gnu_gettext::mo_message<wchar_t>::mo_message(boost::locale::gnu_gettext::messages_info const&) (in /home/brecht/dev/build_linux/bin/blender) ==22684== by 0x38749C0: boost::locale::message_format<wchar_t>* boost::locale::gnu_gettext::create_messages_facet<wchar_t>(boost::locale::gnu_gettext::messages_info const&) (in /home/brecht/dev/build_linux/bin/blender) ==22684== by 0x386C56F: boost::locale::impl_posix::posix_localization_backend::install(std::locale const&, unsigned int, unsigned int) (in /home/brecht/dev/build_linux/bin/blender) ==22684== by 0x38680C8: boost::locale::localization_backend_manager::impl::actual_backend::install(std::locale const&, unsigned int, unsigned int) (in /home/brecht/dev/build_linux/bin/blender) ==22684== by 0x386387B: boost::locale::generator::generate(std::locale const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) const (in /home/brecht/dev/build_linux/bin/blender) ==22684== by 0x3863FE6: boost::locale::generator::generate(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) const (in /home/brecht/dev/build_linux/bin/blender) ==22684== by 0x2B8641C: operator() (generator.hpp:203) ==22684== by 0x2B8641C: bl_locale_set (boost_locale_wrapper.cpp:64) ==22684== by 0x251F735: BLT_lang_set (blt_lang.c:278) ==22684== by 0x179EBF8: WM_init (wm_init_exit.c:200) ```

Bastien Montagne commented

2018-10-04 21:12:35 +02:00

@brecht not sure why that’s on my desk? Your valgrind backtrace does not have much in common with the original error (orig error is a crash while trying to translate datablock ID name somewhere in versioning code, when reading 'home' .blend file at startup). Not sure what to do with valgrind stuff, not even sure that’s not a false positive, in any case that’s very deep in boost library… In any case, cannot reproduce any crash here on debian64 with own build.

@Warun I’d kind of expect that starting Blender with --factory-startup command-line option, you’d get no crash? If that’s the case, can you please attach here your startup .blend file? Thanks.

@brecht not sure why that’s on my desk? Your valgrind backtrace does not have much in common with the original error (orig error is a crash while trying to translate datablock ID name somewhere in versioning code, when reading 'home' .blend file at startup). Not sure what to do with valgrind stuff, not even sure that’s not a false positive, in any case that’s very deep in boost library… In any case, cannot reproduce any crash here on debian64 with own build. @Warun I’d kind of expect that starting Blender with `--factory-startup` command-line option, you’d get no crash? If that’s the case, can you please attach here your startup .blend file? Thanks.

Roland Terver commented

2018-10-05 21:28:38 +02:00

Hi,

I used October 4 version, can't get it to start, don't know where to look for the .blend file...

Hi, I used October 4 version, can't get it to start, don't know where to look for the .blend file...

Bastien Montagne commented

2018-10-05 23:22:32 +02:00

Did you try to run it with --factory-startup command-line option?

Did you try to run it with `--factory-startup` command-line option?

Roland Terver commented

2018-10-06 07:08:55 +02:00

Hi Bastien,

I did. What I just get is the icon bumping in the dock... Same as if I use the icon to launch blender.

Hi Bastien, I did. What I just get is the icon bumping in the dock... Same as if I use the icon to launch blender.

Roland Terver commented

2018-10-06 07:30:36 +02:00

With the version, blender-2.79.0-git20181006.6e08b01bd9a-x86_64, I managed to get it to start.

without --factory-startup, crash
with --factory-startup start is OK.

Here is the file I saved.untitled.blend

With the version, blender-2.79.0-git20181006.6e08b01bd9a-x86_64, I managed to get it to start. without --factory-startup, crash with --factory-startup start is OK. Here is the file I saved.[untitled.blend](https://archive.blender.org/developer/F4958764/untitled.blend)

Roland Terver commented

2018-10-10 19:43:42 +02:00

Any News?

Bastien Montagne commented

2018-10-22 10:43:28 +02:00

@Warun pushed a potential fix, please check with tomorrow's build from buildbot. If that does not do it, am afraid you'll have to settle with a re-initialization of your user preferences… :/

Brecht Van Lommel commented

2018-10-23 13:53:00 +02:00

Added subscriber: @LARK

Brecht Van Lommel commented

2018-10-23 14:02:50 +02:00

It seems another user still has the same issue on today's build.

What could give a hint is running this from the terminal and attaching the output here:

locale -a

@mont29, it probably doesn't solve the core of the issue, but I think the exception handling in bl_locale_pgettext may be wrong too? It should be catching the bad cast but isn't. Maybe it should be:

-    catch(std::bad_cast const &e) {
+    catch(const std::bad_cast &e) {

-    catch(std::exception const &e) {
+    catch(const std::exception &e) {

It seems another user still has the same issue on today's build. What could give a hint is running this from the terminal and attaching the output here: ``` locale -a ``` @mont29, it probably doesn't solve the core of the issue, but I think the exception handling in `bl_locale_pgettext` may be wrong too? It should be catching the bad cast but isn't. Maybe it should be: ``` - catch(std::bad_cast const &e) { + catch(const std::bad_cast &e) { - catch(std::exception const &e) { + catch(const std::exception &e) { ```

Bastien Montagne commented

2018-10-23 14:22:07 +02:00

Don’t remember writing those exceptions, but indeed seems const is at the wrong place. Though I really doubt this will fix things here…

@LARK @Warun Please also try to start blender with --factory-startup, enable again translation (including data names translation), and create a new ID. Does it also crash in that case?

Don’t remember writing those exceptions, but indeed seems const is at the wrong place. Though I really doubt this will fix things here… @LARK @Warun Please also try to start blender with `--factory-startup`, enable again translation (including data names translation), and create a new ID. Does it also crash in that case?

Brecht Van Lommel commented

2018-10-23 14:34:01 +02:00

Fixing the exceptions should at least stop it from crashing, but the translation would still be wrong.

Roland Terver commented

2018-10-23 19:26:05 +02:00

Hi,

I tested without "--factory-startup" on blender-2.79.0-git20181023.86dbbd156fa-x86_64 => Crash
with "--factory-startup" => no crash.
I can change the language to French... But what do mean exactly by "create a new ID"?

Hi, I tested without "--factory-startup" on blender-2.79.0-git20181023.86dbbd156fa-x86_64 => Crash with "--factory-startup" => no crash. I can change the language to French... But what do mean exactly by "create a new ID"?

Bastien Montagne commented

2018-10-24 08:25:20 +02:00

@Warun arg sorry, did the fix in 2.8 only, now pushed to master as well ( 35d7211bfa ).

@Warun arg sorry, did the fix in 2.8 only, now pushed to master as well ( 35d7211bfa ).

Roland Terver commented

2018-10-25 18:01:07 +02:00

Hi, I tested blender-2.79.0-git20181025.65d4314b8e4-x86_64...
same result

Hi, I tested blender-2.79.0-git20181025.65d4314b8e4-x86_64... same result

Roland Terver commented

2018-11-01 06:07:14 +01:00

Hi,

Tested, blender-2.79.0-git20181031.5490708c399-x86_64 still crashing...

Hi, Tested, blender-2.79.0-git20181031.5490708c399-x86_64 still crashing...

Brecht Van Lommel commented

2018-11-01 11:27:06 +01:00

Can you attach the crash log from the new build? The original crash is supposed to be fixed, so it may be happening somewhere else now.

Roland Terver commented

2018-11-01 19:11:15 +01:00

Hi,
{F5327538}Here it is....

Hi, {[F5327538](https://archive.blender.org/developer/F5327538/Blender_crash_2.79_2018-10-31_a.rtf)}Here it is....

Bastien Montagne commented

2018-11-01 19:24:27 +01:00

proper link (since impossible to edit comments ;) ): Blender crash 2.79 2018-10-31_a.rtf

proper link (since impossible to edit comments ;) ): [Blender crash 2.79 2018-10-31_a.rtf](https://archive.blender.org/developer/F5327538/Blender_crash_2.79_2018-10-31_a.rtf)

Roland Terver commented

2018-11-01 19:26:15 +01:00

This comment was removed by @Warun

*This comment was removed by @Warun*

Bastien Montagne commented

2018-11-01 19:28:28 +01:00

Same issue as in original crash it’d seem…

@brecht I really do not know what to do here, this error makes no sense to me, we are supposed to catch (and discard) all exceptions… :/

Same issue as in original crash it’d seem… @brecht I really do not know what to do here, this error makes no sense to me, we are supposed to catch (and discard) **all** exceptions… :/

Bastien Montagne commented

2018-11-01 19:29:41 +01:00

@Warun eeeeeeek! please never ever do that, walls of text make tasks totally unreadable! removed your comment.

Roland Terver commented

2018-11-01 19:31:45 +01:00

Well as the attachment didn't work for you... I thought it would help...

Ray molenkamp commented

2018-11-01 19:35:22 +01:00

Added subscriber: @LazyDodo

Ray molenkamp commented

2018-11-01 19:35:22 +01:00

for future reference, when you drag in an attachment make sure the { and } have a space around it changing your comment from

Hi,
{F5327538}Here it is....

to

Hi,
{F5327538} Here it is....

will make the attachment show up properly .

for future reference, when you drag in an attachment make sure the { and } have a space around it changing your comment from ``` Hi, {F5327538}Here it is.... ``` to ``` Hi, {F5327538} Here it is.... ```` will make the attachment show up properly .

Bastien Montagne commented

2018-11-14 11:11:59 +01:00

Added subscribers: @JoanCastiblanco, @mont29, @lichtwerk

Bastien Montagne changed title from ~~Daily build of Blend 2.79 crashes on OSX Mojave~~ to Crash due to i18n translation at startup on OSX Mojave (versionning code, Data names translation enabled)

2018-11-14 11:12:52 +01:00

blender-admin commented

2018-11-24 19:21:35 +01:00

This issue was referenced by fa0fcbe4d6

This issue was referenced by fa0fcbe4d6ca3f183f02395fe9ba18fb5ea87748

Brecht Van Lommel commented

2018-11-24 20:08:31 +01:00

Changed status from 'Open' to: 'Resolved'

Brecht Van Lommel closed this issue

2018-11-24 20:08:31 +01:00

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Crash due to i18n translation at startup on OSX Mojave (versionning code, Data names translation enabled) #57066