Description of problem: After upgrading to this package, I get Segfaults every time I start blender. [daniel@fuzzy ~]$ rpm -q blender blender-2.65-2.mga3 [daniel@fuzzy ~]$ blender Segmentation fault Under strace I can see the following: [daniel@fuzzy ~]$ strace /usr/bin/blender ..... stat("/home/daniel/.thumbnails/normal/", {st_mode=S_IFDIR|0700, st_size=483328, ...}) = 0 stat("/home/daniel/.thumbnails/fail/blender/", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x63616c6d} --- +++ killed by SIGSEGV +++ Segmentation fault Here is the backtrace: Starting program: /usr/bin/blender [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". [New Thread 0x7fffdfc13700 (LWP 10062)] [New Thread 0x7fffdf412700 (LWP 10063)] Program received signal SIGSEGV, Segmentation fault. 0x00007ffff151a238 in memchr () from /lib64/libc.so.6 (gdb) bt #0 0x00007ffff151a238 in memchr () from /lib64/libc.so.6 #1 0x0000000000e3525e in BLI_strnlen (str=str@entry=0x63616c65 <Address 0x63616c65 out of bounds>, maxlen=maxlen@entry=1024) at /usr/src/debug/blender-2.65/source/blender/blenlib/intern/string.c:433 #2 0x0000000000e2a7d6 in BLI_join_dirfile (dst=dst@entry=0x63616c65 <Address 0x63616c65 out of bounds>, maxlen=maxlen@entry=1024, dir=dir@entry=0x63616c65 <Address 0x63616c65 out of bounds>, file=file@entry=0x171f2e6 "languages") at /usr/src/debug/blender-2.65/source/blender/blenlib/intern/path_util.c:1515 #3 0x0000000001258511 in fill_locales () at /usr/src/debug/blender-2.65/source/blender/blenfont/intern/blf_lang.c:93 #4 BLF_lang_init () at /usr/src/debug/blender-2.65/source/blender/blenfont/intern/blf_lang.c:191 #5 0x0000000000826543 in WM_init (C=C@entry=0x25d1ba8, argc=argc@entry=1, argv=argv@entry=0x7fffffffdb18) at /usr/src/debug/blender-2.65/source/blender/windowmanager/intern/wm_init_exit.c:149 #6 0x0000000000810129 in main (argc=1, argv=0x7fffffffdb18) at /usr/src/debug/blender-2.65/source/creator/creator.c:1327 (gdb) I am afraid this might be a bug in blender: in the function fill_locales() I can see the following: static void fill_locales(void) { char *languages_path = '/usr/share/blender/locale'; LinkNode *lines = NULL, *line; char *str; int idx = 0; free_locales(); BLI_join_dirfile(languages_path, FILE_MAX, languages_path, "languages"); I really doubt it is OK to append anything to the end of the string that languages_path is pointing to, but that's what this BLI_join_dirfile function seems to do. Thanks, Vladimir
*** Bug 8387 has been marked as a duplicate of this bug. ***
CC: (none) => bertauxx
CC: (none) => jani.valimaaSummary: blender-2.65-2.mga3 => blender 2.65 segfaultsSource RPM: (none) => blender-2.65-2.mga3
I just looked at the blender sources http://projects.blender.org/scm/viewvc.php/trunk/blender/source/blender/blenfont/intern/blf_lang.c?view=markup&root=bf-blender and the code for this function (fill locales) looks different and more reasonable: static void fill_locales(void) { char *languages_path = BLI_get_folder(BLENDER_DATAFILES, "locale"); What's interesting is that I can't find that strange initializer that is present in Mageia build anywhere in the source history. Is that something that was patched in by the packagers? Thanks, Vladimir
Assignee: bugsquad => fundawang
Yes this is a mageia patch to change the locale data path to "/usr/share/locales". It was changed to also set the path for the file /usr/share/blender/locale/languages in fill_locales() for 2.65. Writing to a const string is not allowed and gcc would warn about the assignment. But I guess you didn't notice that there are single quotes around the string which means it's seen as a single character (no warning in the build log). Since this patch is not suitable for upstream anyway it is easier to remove languages_path completely and use: line = lines = BLI_file_read_as_lines("/usr/share/blender/locale/languages"); instead of BLI_file_read_as_lines(languages_path);
CC: (none) => cjw
Hello Christian, You are right, I didn't notice the single quotes around the string, but that's even worse, since what the compiler did, it assigned a totally meaningless integer, consisting of the bytes 'c', 'a', 'l', and 'e' (0x63616c65) to the pointer *languages_path and that's exactly what you can see in the trace (you can see 6d instead of 65 in strace output, because there was probably an attempt to do a readahed of the next 8 bytes). I am really surprized that GCC didn't issue a warniing, e.g. "converting from pointer to integer". Did we disable that? As for the patch itself, I wonder: does it make sense to patch blender all the time instead of letting it keep its files where it wants them to be and just create an appropriate symbolic link from /usr/share/locales (or otherwise, put the files where Mageia wants them to be abd create a symbolic link from usr/share blender/locale/languages)? Thanks, Vladimir
Yes the new localedir patch is faulty. I've given a look at the Fedora and fixed the patch using the same string syntax : --- blender-2.65-localedir.patch.bak 2012-12-12 15:46:44.000000000 +0100 +++ blender-2.65-localedir.patch 2012-12-20 19:56:17.389044654 +0100 @@ -24,7 +24,7 @@ static void fill_locales(void) { - char *languages_path = BLI_get_folder(BLENDER_DATAFILES, "locale"); -+ char *languages_path = '/usr/share/blender/locale'; ++ char languages_path[FILE_MAX] = "/usr/share/blender/locale"; LinkNode *lines = NULL, *line; char *str; int idx = 0; I've rebuilt the package and the problem is solved.
CC: (none) => sardine213
I'm raising the priority to high.
Priority: Normal => High
Unfortunately, the newly built belnder-2.65a-1.mga3 package still has the same problem. I assume it was built prior to this discussion.
Source RPM: blender-2.65-2.mga3 => blender-2.65a-1.mga3
Apparently this bug report went unnoticed. But I fixed the problem in blender-2.65a-2.mga3 with my own proposed patch now.
Status: NEW => RESOLVEDResolution: (none) => FIXED