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

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

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

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

Just to recap, the story so far:

I did a production build from a recent commit from just a few minutes ago (rBff98be), 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 rB7025a1, I can do all the above just fine.

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)

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.

◀ Merged tasks: T38109.