open .blend file will be crash with blender 2.77a #48176

New Issue

Leroy · 2016-04-17T09:24:42+02:00

Leroy commented

2016-04-17 09:24:42 +02:00

System Information
windows 7 sp1 64bit

Blender Version
Broken: blender 2.77a abf6f08
Worked: (optional)

open the .blend file will be crash, I do not know what causes, and the .blend file is download from blendswap. I have tried on several computer with different windows system.

The file link : http://www.blendswap.com/blends/view/67739

Exact steps for others to reproduce the error
Just open it with blender 2.77a, than blender will be crash, but sometimes can open it in normal, and sometimes switch layer will be crash too, I don't know who causes, but if you delete the ground object than save it, it's will be work fine.

Thanks

**System Information** windows 7 sp1 64bit **Blender Version** Broken: blender 2.77a abf6f08 Worked: (optional) open the .blend file will be crash, I do not know what causes, and the .blend file is download from blendswap. I have tried on several computer with different windows system. The file link : http://www.blendswap.com/blends/view/67739 **Exact steps for others to reproduce the error** Just open it with blender 2.77a, than blender will be crash, but sometimes can open it in normal, and sometimes switch layer will be crash too, I don't know who causes, but if you delete the ground object than save it, it's will be work fine. Thanks

Leroy commented

2016-04-17 09:24:42 +02:00

Changed status to: 'Open'

Leroy commented

2016-04-17 09:24:42 +02:00

Added subscriber: @Leroy-Xie

Campbell Barton commented

2016-04-17 21:55:56 +02:00

Added subscribers: @Sergey, @ideasman42

Sergey Sharybin was assigned by Campbell Barton

2016-04-17 21:55:56 +02:00

Campbell Barton commented

2016-04-17 21:55:56 +02:00

Confirmed, the issue is that 2+ shrinkwrap constraint are releasing the subsurf derived mesh, which frees temporary data.
However this happens without any locking, causing a double-free in own tests (target->release(target); at constraint.c:3526).

For now, if you want to use this file, you can run Blender with the -t 1 argument to disable multi-threading.

Assigning to @Sergey

Confirmed, the issue is that 2+ shrinkwrap constraint are releasing the subsurf derived mesh, which frees temporary data. However this happens without any locking, causing a double-free in own tests (`target->release(target);` at constraint.c:3526). For now, if you want to use this file, you can run Blender with the `-t 1` argument to disable multi-threading. Assigning to @Sergey

Sergey Sharybin commented

2016-04-25 12:12:39 +02:00

@ideasman42, i can't really reproduce the issue, so having some additional info would help.

But basically, from what i see. Shrinkwrap constraint only need DerivedMesh to construct BVHTree. BVHTree will create a copied of vert/loops/looptris arrays if those layers do not exist yet (meaning, no write to DM will happen). This means dm->release() is not really needed, and likely to be fully avoid, since currently it caused temporary layers to be freed. So in order to fix crash it should be enough to remove dm->release() call. This is in fact a correct thing to do.

However, temporary layers created in the DM by the DM users (not by DM itself) is a bug. This is because policy must be nobody can write to other's DM. So it's important to understand who writes to the DM. That's where some back traces form you might give some enlightenment.

So can you perhaps share some crash backtraces for further investigation?

@ideasman42, i can't really reproduce the issue, so having some additional info would help. But basically, from what i see. Shrinkwrap constraint only need DerivedMesh to construct BVHTree. BVHTree will create a copied of vert/loops/looptris arrays if those layers do not exist yet (meaning, no write to DM will happen). This means `dm->release()` is not really needed, and likely to be fully avoid, since currently it caused temporary layers to be freed. So in order to fix crash it should be enough to remove `dm->release()` call. This is in fact a correct thing to do. However, temporary layers created in the DM by the DM users (not by DM itself) is a bug. This is because policy must be `nobody can write to other's DM`. So it's important to understand who writes to the DM. That's where some back traces form you might give some enlightenment. So can you perhaps share some crash backtraces for further investigation?

blender-admin commented

2016-04-26 14:44:49 +02:00

This issue was referenced by 680b135ec1

This issue was referenced by 680b135ec1cf220c7ebd579b88bc5481fc379fc3

Sergey Sharybin commented

2016-04-26 14:44:59 +02:00

Changed status from 'Open' to: 'Resolved'

Sergey Sharybin closed this issue

2016-04-26 14:44:59 +02: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

open .blend file will be crash with blender 2.77a #48176