Blender crashes when using "spline" or "segments" for bevel curve factor. #41085

New Issue

Jasper van Nieuwenhuizen · 2014-07-15T17:14:13+02:00

2014-07-15 17:14:13 +02:00

System Information
OS X 10.8.5
NVIDIA GeForce GT 650M 1024 MB

Blender Version
Broken: 2.71 2f03ccc and offical 2.71 9337574
Worked: ???

When animating the bevel factor of a complicated bezier curve, Blender crashes when using "spline" or "segments" for the beginning and end bevel factor. When using "resolution" there is no problem. If the end bevel factor is 1, it's okay, but as soon as you make it smaller, Blender crashes. On simple curves it's no problem, but on complicated/heavy curves it is.

If it helps, the error message from the console:

blender(1001,0x7fff75fe0180) malloc: ***error for object 0x108585608: incorrect checksum for freed object - object was probably modified after being freed.*** set a breakpoint in malloc_error_break to debug)

Exact steps for others to reproduce the error
Open attached blend-file and change the end bevel factor.
curve_bevel_crash.blend

**System Information** OS X 10.8.5 NVIDIA GeForce GT 650M 1024 MB **Blender Version** Broken: 2.71 2f03ccc and offical 2.71 9337574 Worked: ??? When animating the bevel factor of a complicated bezier curve, Blender crashes when using "spline" or "segments" for the beginning and end bevel factor. When using "resolution" there is no problem. If the end bevel factor is 1, it's okay, but as soon as you make it smaller, Blender crashes. On simple curves it's no problem, but on complicated/heavy curves it is. If it helps, the error message from the console: ``` blender(1001,0x7fff75fe0180) malloc: ***error for object 0x108585608: incorrect checksum for freed object - object was probably modified after being freed.*** set a breakpoint in malloc_error_break to debug) ``` **Exact steps for others to reproduce the error** Open attached blend-file and change the end bevel factor. [curve_bevel_crash.blend](https://archive.blender.org/developer/F97958/curve_bevel_crash.blend)

Jasper van Nieuwenhuizen commented

2014-07-15 17:14:13 +02:00

Changed status to: 'Open'

Jasper van Nieuwenhuizen commented

2014-07-15 17:14:13 +02:00

Added subscriber: @jasperge-2

Kévin Dietrich commented

2014-07-15 18:20:24 +02:00

Added subscriber: @kevindietrich

Kévin Dietrich commented

2014-07-15 18:20:24 +02:00

I'm getting:

BLI_assert failed: /home/kevin/src/blender-git/blender/source/blender/blenkernel/intern/displist.c:1443, calc_bevfac_mapping(), at 'bevp_i < bl->nr - 1'

Error in `/home/kevin/src/blender-git/build_linux_debug/bin/blender': free(): invalid next size (normal): 0x0000000007936860


Program received signal SIGABRT, Aborted.

0x00007ffff3203f79 in raise () from /lib/x86_64-linux-gnu/libc.so.6

I'm getting: ``` BLI_assert failed: /home/kevin/src/blender-git/blender/source/blender/blenkernel/intern/displist.c:1443, calc_bevfac_mapping(), at 'bevp_i < bl->nr - 1' ``` ***Error in `/home/kevin/src/blender-git/build_linux_debug/bin/blender': free(): invalid next size (normal): 0x0000000007936860*** ``` Program received signal SIGABRT, Aborted. ``` 0x00007ffff3203f79 in raise () from /lib/x86_64-linux-gnu/libc.so.6

Ejner Fergo commented

2014-07-16 03:32:51 +02:00

Added subscriber: @EjnerFergo

Ejner Fergo commented

2014-07-16 03:32:51 +02:00

OS: Arch Linux 64
GFX: Nvidia GeForce GTX 560 1024MB
Blender: git-master dfe1b9b

Didn't get a crash immediately, but had to slide the value up and down a bit. Tried 3 times, and 2 of the crash-logs looked like this:

  Blender 2.71 (sub 2), Commit date: 2014-07-16 00:52, Hash dfe1b9b

# backtrace

  
  ./blender() [0x8db788]
  /usr/lib/libc.so.6(+0x33df0) [0x7f53e47bedf0]
  ./blender() [0xe98b92]
  ./blender(BKE_displist_make_curveTypes+0x59) [0xe97629]
  ./blender(BKE_object_handle_update_ex+0x5f5) [0xf0f4d5]
  ./blender() [0xf4dd26]
  ./blender(BLI_task_pool_work_and_wait+0x95) [0x1059305]
  ./blender() [0xf4dea3]
  ./blender() [0xf4ef48]
  ./blender(BKE_scene_update_tagged+0x7e) [0xf4f1be]
  ./blender(wm_event_do_notifiers+0x48a) [0x8e216a]
  ./blender(WM_main+0x20) [0x8dd680]
  ./blender(main+0xd6f) [0x8c4a2f]
  /usr/lib/libc.so.6(__libc_start_main+0xf0) [0x7f53e47ab000]
  ./blender() [0x8db004]

And the last one was this:

  Blender 2.71 (sub 2), Commit date: 2014-07-16 00:52, Hash dfe1b9b

# backtrace

  ./blender() [0x8db788]
  /usr/lib/libc.so.6(+0x33df0) [0x7fa01ba19df0]
  /usr/lib/libpthread.so.0(pthread_mutex_lock+0x4) [0x7fa027e228b4]
  /usr/lib/libjemalloc.so.1(+0x266c2) [0x7fa01efe86c2]
  /usr/lib/libjemalloc.so.1(+0x26b0d) [0x7fa01efe8b0d]
  ./blender(uiBlockLayoutResolve+0x8e) [0xa8dc7e]
  ./blender(ED_region_panels+0x2ad) [0xb5c7cd]
  ./blender(ED_region_do_draw+0x895) [0xb5ba95]
  ./blender(wm_draw_update+0x457) [0x8e03f7]
  ./blender(WM_main+0x28) [0x8dd688]
  ./blender(main+0xd6f) [0x8c4a2f]
  /usr/lib/libc.so.6(__libc_start_main+0xf0) [0x7fa01ba06000]
  ./blender() [0x8db004]

OS: Arch Linux 64 GFX: Nvidia GeForce GTX 560 1024MB Blender: git-master dfe1b9b Didn't get a crash immediately, but had to slide the value up and down a bit. Tried 3 times, and 2 of the crash-logs looked like this: ``` Blender 2.71 (sub 2), Commit date: 2014-07-16 00:52, Hash dfe1b9b ``` # backtrace ``` ./blender() [0x8db788] /usr/lib/libc.so.6(+0x33df0) [0x7f53e47bedf0] ./blender() [0xe98b92] ./blender(BKE_displist_make_curveTypes+0x59) [0xe97629] ./blender(BKE_object_handle_update_ex+0x5f5) [0xf0f4d5] ./blender() [0xf4dd26] ./blender(BLI_task_pool_work_and_wait+0x95) [0x1059305] ./blender() [0xf4dea3] ./blender() [0xf4ef48] ./blender(BKE_scene_update_tagged+0x7e) [0xf4f1be] ./blender(wm_event_do_notifiers+0x48a) [0x8e216a] ./blender(WM_main+0x20) [0x8dd680] ./blender(main+0xd6f) [0x8c4a2f] /usr/lib/libc.so.6(__libc_start_main+0xf0) [0x7f53e47ab000] ./blender() [0x8db004] ``` And the last one was this: ``` Blender 2.71 (sub 2), Commit date: 2014-07-16 00:52, Hash dfe1b9b ``` # backtrace ``` ./blender() [0x8db788] /usr/lib/libc.so.6(+0x33df0) [0x7fa01ba19df0] /usr/lib/libpthread.so.0(pthread_mutex_lock+0x4) [0x7fa027e228b4] /usr/lib/libjemalloc.so.1(+0x266c2) [0x7fa01efe86c2] /usr/lib/libjemalloc.so.1(+0x26b0d) [0x7fa01efe8b0d] ./blender(uiBlockLayoutResolve+0x8e) [0xa8dc7e] ./blender(ED_region_panels+0x2ad) [0xb5c7cd] ./blender(ED_region_do_draw+0x895) [0xb5ba95] ./blender(wm_draw_update+0x457) [0x8e03f7] ./blender(WM_main+0x28) [0x8dd688] ./blender(main+0xd6f) [0x8c4a2f] /usr/lib/libc.so.6(__libc_start_main+0xf0) [0x7fa01ba06000] ./blender() [0x8db004] ```

Sergey Sharybin was assigned by Lukas Tönne

2014-07-16 18:39:17 +02:00

Lukas Tönne commented

2014-07-16 18:39:17 +02:00

Added subscriber: @LukasTonne

Lukas Tönne commented

2014-07-16 18:39:17 +02:00

Can confirm an assert failure here:
https://developer.blender.org/diffusion/B/browse/master/source/blender/blenkernel/intern/displist.c;57a3403bc08d71d851cbded1c08913f0402d994c$1443

Tried simplifying the curve because debugging an object like this is almost impossible. However, there seems to be a secondary bug: Selecting all except one vertex and deleting them gives another assert failure in GHash duplicates:
https://developer.blender.org/diffusion/B/browse/master/source/blender/blenlib/intern/BLI_ghash.c;57a3403bc08d71d851cbded1c08913f0402d994c$207

Can confirm an assert failure here: https://developer.blender.org/diffusion/B/browse/master/source/blender/blenkernel/intern/displist.c;57a3403bc08d71d851cbded1c08913f0402d994c$1443 Tried simplifying the curve because debugging an object like this is almost impossible. However, there seems to be a secondary bug: Selecting all except one vertex and deleting them gives another assert failure in GHash duplicates: https://developer.blender.org/diffusion/B/browse/master/source/blender/blenlib/intern/BLI_ghash.c;57a3403bc08d71d851cbded1c08913f0402d994c$207

Sergey Sharybin commented

2014-07-18 10:08:56 +02:00

Added subscriber: @cnd

Sergey Sharybin commented

2014-07-18 10:08:56 +02:00

Here's the simplified .blend

The thing here is: bevel list will remove points if they're appearing to be on the same position. So pointsu*resoution could be totally dirrerent from the actual number of bevel points. This fact is totally ignored in calc_bevfac_mapping. This function should really always use bl->nr actually..

@cnd, do you have time to look into this code?

spline_mapping_crash.blend1

Here's the simplified .blend The thing here is: bevel list will remove points if they're appearing to be on the same position. So pointsu*resoution could be totally dirrerent from the actual number of bevel points. This fact is totally ignored in `calc_bevfac_mapping`. This function should really always use `bl->nr` actually.. @cnd, do you have time to look into this code? [spline_mapping_crash.blend1](https://archive.blender.org/developer/F98382/spline_mapping_crash.blend1)

Lukas Treyer commented

2014-07-19 09:45:56 +02:00

Yes I will have a look at it.
EDIT: What about calculating the length of curves directly in BKE_curve_bevelList_make() in STEP 2 ? I don't see any other reliable possibility to find out whether some bevpoints where omitted for optimization reasons. Would you agree on this?

Yes I will have a look at it. EDIT: What about calculating the length of curves directly in BKE_curve_bevelList_make() in STEP 2 ? I don't see any other reliable possibility to find out whether some bevpoints where omitted for optimization reasons. Would you agree on this?

Lukas Treyer commented

2014-07-28 17:24:23 +02:00

I've been working on a fix. Had some other work to do first. Struggling with Phabricator again, therefore only a diff: #41085.diff

EDIT: What does it do?: By calculating the bevels of a curve it also stores the offset between bevels in BevPoint->offset. BevList now also stores the length of segments and the amount of bevels per segment (aka resolution per segment), since this number can differ if two curve points are equal.

I've been working on a fix. Had some other work to do first. Struggling with Phabricator again, therefore only a diff: [#41085.diff](https://archive.blender.org/developer/F100025/T41085.diff) EDIT: What does it do?: By calculating the bevels of a curve it also stores the offset between bevels in BevPoint->offset. BevList now also stores the length of segments and the amount of bevels per segment (aka resolution per segment), since this number can differ if two curve points are equal.

Sergey Sharybin commented

2014-07-29 10:54:51 +02:00

@cnd, here's an updated patch fr you.T41085_2.diff Changes:

C standard forbids declaring variables in the middle of the block, fixed it now
Added a proper bevel list free function now
In the if (nu->type == CU_BEZIER) { you've used the wrong length, which lead to bad memory access on differentiation, it should be len = segcount * resolu + 1; Without this blender crashed for me instantly on opening the file i've attached here.

There's at least one renaming issue: with the file i've attached above tweak End Factor. It'll make first start segment to disappear.

Same i see when replacing MEM_callocN with MEM_mallocN for the new arrays. And the thing is, it seems all the elements of new arrays are expected to be initialized and it shouldn't matter if you use calloc or malloc apart form using malloc wouldn't waste time on memsetting the allocated memory. I guess it's some non-initialized segment or length or so is happening?

@cnd, here's an updated patch fr you.[T41085_2.diff](https://archive.blender.org/developer/F100119/T41085_2.diff) Changes: - C standard forbids declaring variables in the middle of the block, fixed it now - Added a proper bevel list free function now - In the `if (nu->type == CU_BEZIER) {` you've used the wrong length, which lead to bad memory access on differentiation, it should be `len = segcount * resolu + 1;` Without this blender crashed for me instantly on opening the file i've attached here. There's at least one renaming issue: with the file i've attached above tweak End Factor. It'll make first start segment to disappear. Same i see when replacing `MEM_callocN` with `MEM_mallocN` for the new arrays. And the thing is, it seems all the elements of new arrays are expected to be initialized and it shouldn't matter if you use calloc or malloc apart form using malloc wouldn't waste time on memsetting the allocated memory. I guess it's some non-initialized segment or length or so is happening?

Lukas Treyer commented

2014-07-30 18:55:32 +02:00

Thank you for the corrections. The issue with the first segment disappearing was an small mistake of mine: move "bevp++;" from line 1398 to line 1393 and it should work out fine.
When I replace MEM_callocN with MEMmallocN I get a strange flickering of the beveled curve when sliding the factor sliders. I propose to leave it with MEM_callocN. There must be a reason why "bl" is initialized with MEM_callocN.

Thank you for the corrections. The issue with the first segment disappearing was an small mistake of mine: move "bevp++;" from line 1398 to line 1393 and it should work out fine. When I replace MEM_callocN with MEMmallocN I get a strange flickering of the beveled curve when sliding the factor sliders. I propose to leave it with MEM_callocN. There must be a reason why "bl" is initialized with MEM_callocN.

Sergey Sharybin commented

2014-07-31 14:39:48 +02:00

Attaching T41085_3.diff

If calloc works and malloc gives flickering it might mean you're not initializing some values in the loops..

Attaching [T41085_3.diff](https://archive.blender.org/developer/F100712/T41085_3.diff) If calloc works and malloc gives flickering it might mean you're not initializing some values in the loops..

Lukas Treyer commented

2014-07-31 17:28:17 +02:00

T41085_4.diff
malloc: I was adding with "+= value" to uninitialized values when using malloc. I init them now with *seglen = 0 (on line 2726 for instance).

in curve.c --> BKE_curve_bevelList_make --> STEP2 I took out the redundant calculation of bevp->offset. it is being calculated already in STEP 1.

[T41085_4.diff](https://archive.blender.org/developer/F100725/T41085_4.diff) malloc: I was adding with "+= value" to uninitialized values when using malloc. I init them now with *seglen = 0 (on line 2726 for instance). in curve.c --> BKE_curve_bevelList_make --> STEP2 I took out the redundant calculation of bevp->offset. it is being calculated already in STEP 1.

Campbell Barton commented

2014-08-05 11:26:01 +02:00

Added subscriber: @ideasman42

Campbell Barton commented

2014-08-05 11:26:01 +02:00

re: T41085_4.diff

Possible to make it that bl->seglen and bl->segbevcount are only allocated when needed? - so if you aren't setting curve bevel factors (which isnt especially common), it doesn't bother allocating?

re: T41085_4.diff Possible to make it that `bl->seglen` and `bl->segbevcount` are only allocated when needed? - so if you aren't setting curve bevel factors (which isnt especially common), it doesn't bother allocating?

Campbell Barton commented

2014-08-05 11:27:31 +02:00

Another note if (a != segcount) printf("a != segcount"); -- rather just keep asserts here.

Another note `if (a != segcount) printf("a != segcount");` -- rather just keep asserts here.

Sergey Sharybin removed their assignment 2014-08-05 17:40:27 +02:00

Sergey Sharybin commented

2014-08-05 17:40:27 +02:00

Added subscriber: @Sergey

Sergey Sharybin commented

2014-08-05 17:40:27 +02:00

Attaching patch which tries to avoid unneeded calculations T41085_5.diff. Seems to be rather fine for beziers now, but nurbs fails a lot. Basically all the part under

/* match seglen and segbevcount to the cleaned up bevel lists (see STEP 2) */

is just wrong. It writes far pas the seglen array. Also not really sure, do we need to handle seglen and segbevcount in a different way for path/bezier/nurbs?

Attaching patch which tries to avoid unneeded calculations [T41085_5.diff](https://archive.blender.org/developer/F101533/T41085_5.diff). Seems to be rather fine for beziers now, but nurbs fails a lot. Basically all the part under ``` /* match seglen and segbevcount to the cleaned up bevel lists (see STEP 2) */ ``` is just wrong. It writes far pas the `seglen` array. Also not really sure, do we need to handle `seglen` and `segbevcount` in a different way for path/bezier/nurbs?

Sergey Sharybin commented

2014-08-05 18:31:19 +02:00

Seems made it working now T41085_6.diff

@ideasman42, mind having your hands on tests? :)

Seems made it working now [T41085_6.diff](https://archive.blender.org/developer/F101540/T41085_6.diff) @ideasman42, mind having your hands on tests? :)

Campbell Barton commented

2014-08-13 12:24:33 +02:00

Managed to crash, add splint, duplicate, set bev depth 0.1, Set start end fact to anything. Alt+Mousewheel over bevel factor.

You may want to change bevel factor a bit... but for me it crashes quite fast, untitled.blend

Managed to crash, add splint, duplicate, set bev depth 0.1, Set start end fact to anything. Alt+Mousewheel over bevel factor. You may want to change bevel factor a bit... but for me it crashes quite fast, [untitled.blend](https://archive.blender.org/developer/F102836/untitled.blend)

Sergey Sharybin commented

2014-08-13 12:50:01 +02:00

Attaching fix for this T41085_7.diff

Attaching fix for this [T41085_7.diff](https://archive.blender.org/developer/F102850/T41085_7.diff)

Sergey Sharybin commented

2014-08-13 13:39:32 +02:00

Fixed issue reported by asan T41085_8.patch

Fixed issue reported by asan [T41085_8.patch](https://archive.blender.org/developer/F102863/T41085_8.patch)

Jasper van Nieuwenhuizen commented

2014-08-14 16:03:05 +02:00

Just applied T41085_8.patch and tried hard to crash Blender, luckily without success. :)