Gooseberry Branch - Apply button in modifiers crashes Blender #43878

Closed
opened 2015-03-04 01:06:29 +01:00 by Juan Pablo Bouza · 10 comments

System Information
Operating system and graphics card

Kubuntu 14.10 64bits

Gooseberry Branch
Broken: (hash 2cacb22 - march 3 buildbot)
Worked: (Feb 27 buildbot)

The problem seems only so occur in the Gooseberry Branch.

If you press the "apply" button in any modifier of the Deform or Modify category, Blender crashes. Note that modifiers such as Armature and Mesh Deform, must have their target assigned in order to crash.

Just add a Cube and assign a smooth modifier, press apply and it crashes. Apply as shape seems to be working fine though.

**System Information** Operating system and graphics card Kubuntu 14.10 64bits **Gooseberry Branch** Broken: (hash 2cacb22 - march 3 buildbot) Worked: (Feb 27 buildbot) The problem seems only so occur in the Gooseberry Branch. If you press the "apply" button in any modifier of the Deform or Modify category, Blender crashes. Note that modifiers such as Armature and Mesh Deform, must have their target assigned in order to crash. Just add a Cube and assign a smooth modifier, press apply and it crashes. Apply as shape seems to be working fine though.
Author
Member

Changed status to: 'Open'

Changed status to: 'Open'
Author
Member

Added subscriber: @jpbouza-4

Added subscriber: @jpbouza-4

Added subscriber: @mont29

Added subscriber: @mont29
Bastien Montagne self-assigned this 2015-03-04 09:14:58 +01:00

Added subscriber: @Sergey

Added subscriber: @Sergey

This is caused by the take_ownership change in DM_to_mesh. Seems we need to forbid passing ownership and do it all in a copy if DM depends on mesh, but not sure how to check on that yet. Can look later after smashing the current bug i'm looking into.

This is caused by the `take_ownership` change in `DM_to_mesh`. Seems we need to forbid passing ownership and do it all in a copy if DM depends on mesh, but not sure how to check on that yet. Can look later after smashing the current bug i'm looking into.

@mont29, here's a quick patch which prevents crash: http://www.pasteall.org/57028/diff which is likely safe.

But in theory we can do something lie this http://www.pasteall.org/57031/diff and avoid temp memory from allocation i think. Not sure there's no memory leaks here tho.

@mont29, here's a quick patch which prevents crash: http://www.pasteall.org/57028/diff which is likely safe. But in theory we can do something lie this http://www.pasteall.org/57031/diff and avoid temp memory from allocation i think. Not sure there's no memory leaks here tho.

@Sergey ah, so you were on it too…

Yes, first patch will work, but as you says it's abit stupid since a single referenced layer will force copying the whole cdarray for that mesh element type.

Second one wont work, a given DM may use referenced data from any kind of CD type, in theory.

Root of the issue here is behavior of CD_ASSIGN in CDLayer copy context - it falls back to CD_REFERENCE when source does not own the data (CD_FLAG_NOFREE is set on source). What we want here is the reverse - to fallback to CD_DUPLICATE in this case. Proposed patch: D1158.

@Sergey ah, so you were on it too… Yes, first patch will work, but as you says it's abit stupid since a single referenced layer will force copying the whole cdarray for that mesh element type. Second one wont work, a given DM may use referenced data from any kind of CD type, in theory. Root of the issue here is behavior of `CD_ASSIGN` in CDLayer copy context - it falls back to `CD_REFERENCE` when source does not own the data (`CD_FLAG_NOFREE` is set on source). What we want here is the reverse - to fallback to `CD_DUPLICATE` in this case. Proposed patch: [D1158](https://archive.blender.org/developer/D1158).

This issue was referenced by 02685aca523857672dd3e3b4ba2423f08262812b

This issue was referenced by 02685aca523857672dd3e3b4ba2423f08262812b

Changed status from 'Open' to: 'Resolved'

Changed status from 'Open' to: 'Resolved'

Closed by commit 02685aca52.

Closed by commit 02685aca52.
Sign in to join this conversation.
4 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: blender/blender#43878
No description provided.