Hang on trying to write crash report #38116

New Issue

Lawrence D'Oliveiro · 2014-01-08T04:09:28+01:00

2014-01-08 04:09:28 +01:00

System Information
Debian Unstable AMD64, Intel Core i7 with HD4000 graphics

Blender Version
Broken: 2.69.8 built from a Git update just a few hours ago.

Description of error
The enclosed file causes Blender to hang trying to open it.

I was hitting a crash when trying to merge needless duplicates of object data on some mesh objects. In an effort to pin down the minimum .blend file that would reproduce the error, I ended up creating the enclosed file mesh_users_crash.blend, that seems to trigger a hang immediately you try to open it.

Actually it looks like Blender crashes, tries to write a crash dump, and hangs. I see the message “Writing: /tmp/mesh_users_crash.crash.txt” appear in the terminal window I launched it from, then no further response. There is no file /tmp/mesh_users_crash.crash.txt, so presumably it never got as far as opening the file for writing.

**System Information** Debian Unstable AMD64, Intel Core i7 with HD4000 graphics **Blender Version** Broken: 2.69.8 built from a Git update just a few hours ago. **Description of error** The enclosed file causes Blender to hang trying to open it. I was hitting a crash when trying to merge needless duplicates of object data on some mesh objects. In an effort to pin down the minimum `.blend` file that would reproduce the error, I ended up creating the enclosed file [mesh_users_crash.blend](https://archive.blender.org/developer/F63636/mesh_users_crash.blend), that seems to trigger a hang immediately you try to open it. Actually it looks like Blender crashes, tries to write a crash dump, and hangs. I see the message “Writing: /tmp/mesh_users_crash.crash.txt” appear in the terminal window I launched it from, then no further response. There is no file `/tmp/mesh_users_crash.crash.txt`, so presumably it never got as far as opening the file for writing.

Lawrence D'Oliveiro commented

2014-01-08 04:09:28 +01:00

Changed status to: 'Open'

Lawrence D'Oliveiro commented

2014-01-08 04:09:28 +01:00

Added subscriber: @ldo

blender-admin commented

2014-01-08 04:09:28 +01:00

#38109 was marked as duplicate of this issue

Joshua Leung commented

2014-01-08 04:13:55 +01:00

Added subscriber: @JoshuaLeung

Joshua Leung commented

2014-01-08 04:13:55 +01:00

No crash here on Windows 64-bit (mingw64), build 7647a2b

To allow normal debugging via GDB, run blender with the --disable-crash-handler flag

No crash here on Windows 64-bit (mingw64), build 7647a2b To allow normal debugging via GDB, run blender with the --disable-crash-handler flag

Lawrence D'Oliveiro commented

2014-01-08 05:42:03 +01:00

I rebuilt with GDB, it now succeeds in opening the file without a crash.

However, I then tried linking all the Manhole Cover.nnn objects to the single Manhole Cover mesh (to get rid of the duplicate Manhole Cover.nnn meshes). After about doing one or two, it crashes. A backtrace is enclosed crash_backtrace.txt. The key message seems to be “free(): invalid next size (normal)”.

I rebuilt with GDB, it now succeeds in opening the file without a crash. However, I then tried linking all the Manhole Cover.*nnn* objects to the single Manhole Cover mesh (to get rid of the duplicate Manhole Cover.*nnn* meshes). After about doing one or two, it crashes. A backtrace is enclosed [crash_backtrace.txt](https://archive.blender.org/developer/F63658/crash_backtrace.txt). The key message seems to be “free(): invalid next size (normal)”.

Sergey Sharybin self-assigned this 2014-01-13 20:23:58 +01:00

Sergey Sharybin commented

2014-01-13 20:23:58 +01:00

This is very much the same heisenbug i was fighting two days already. Assigning to self for now, this could give some clues to me.

Lawrence D'Oliveiro commented

2014-01-13 20:57:29 +01:00

Let me know if there are any further tests I can do.

Lawrence D'Oliveiro commented

2014-01-13 23:31:19 +01:00

Just to recap, the story so far:

I did a production build from a recent commit from just a few minutes ago (ff98be), launched it with no command-line options, did a Load Factory Settings, then tried to load the above problem file F63636, whereupon it hung. In the terminal window, the last message was “Writing: /tmp/mesh_users_crash.crash.txt”. There was no such file.

If I relaunched the same build with the ##--disable-crash-handler## option, it manages to load the file. Then I tried selecting each of the “Manhole Cover.nnn” mesh objects, and changing the mesh datablock to the one named “Manhole Cover” instead of “Manhole Cover.nnn”, where it wasn’t already so linked. After doing no more than one or two of these, Blender crashes.

If I make a build from 7025a1, I can do all the above just fine.

Just to recap, the story so far: I did a production build from a recent commit from just a few minutes ago (ff98be), launched it with no command-line options, did a Load Factory Settings, then tried to load the above problem file [F63636](https://archive.blender.org/developer/F63636/mesh_users_crash.blend), whereupon it hung. In the terminal window, the last message was “Writing: /tmp/mesh_users_crash.crash.txt”. There was no such file. If I relaunched the same build with the ##--disable-crash-handler## option, it manages to load the file. Then I tried selecting each of the “Manhole Cover.*nnn*” mesh objects, and changing the mesh datablock to the one named “Manhole Cover” instead of “Manhole Cover.*nnn*”, where it wasn’t already so linked. After doing no more than one or two of these, Blender crashes. If I make a build from 7025a1, I can do all the above just fine.

Lawrence D'Oliveiro commented

2014-01-14 00:32:55 +01:00

In case it might be relevant, here is some info on my GCC version:

ldo@theon:blender> gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.8.2-10' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.8 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.8.2 (Debian 4.8.2-10)

In case it might be relevant, here is some info on my GCC version: ldo@theon:blender> gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.8.2-10' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.8 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.8.2 (Debian 4.8.2-10)

Sergey Sharybin commented

2014-01-14 12:31:56 +01:00

The actual issue is not about hung when gathering crash report, it is not controlled by blender actually and it might work really unpredictable depending on how much corrupted the memory is.

Actual issue is why blender crashes. And this is to be solved.

The actual issue is not about hung when gathering crash report, it is not controlled by blender actually and it might work really unpredictable depending on how much corrupted the memory is. Actual issue is why blender crashes. And this is to be solved.

Sergey Sharybin commented

2014-01-16 12:46:56 +01:00

Added subscribers: @zanqdo, @brecht, @Sergey, @mont29, @ideasman42