crash, texture paint mode #57157

New Issue

noki paike · 2018-10-11T04:08:48+02:00

noki paike commented

2018-10-11 04:08:48 +02:00

System Information
windows 10 radeon HD 7670
Blender Version
Broken: blender-2.80.0-git.121c94b0829-windows64

Short description of error

crash on texture paint mode

Exact steps for others to reproduce the error

eliminate the cube and create a uv sphere
go to texture paint workspace
add a base color texture, generate type: color grid
zoom a little the sphere and type a little paint
go with the cursor to the 2d paint window, press 2 times tab for display the texture
go with the cursor to 3d window and try to paint
crash

the console display this:
Error : EXCEPTION_ACCESS_VIOLATION
Address : 0x00007FF669169C40 (the address always changes)

system-info.txt
debugmodeall.txt

**System Information** windows 10 radeon HD 7670 **Blender Version** Broken: blender-2.80.0-git.121c94b0829-windows64 **Short description of error** crash on texture paint mode **Exact steps for others to reproduce the error** 1) eliminate the cube and create a uv sphere 2) go to texture paint workspace 3) add a base color texture, generate type: color grid 4) zoom a little the sphere and type a little paint 5) go with the cursor to the 2d paint window, press 2 times tab for display the texture 6) go with the cursor to 3d window and try to paint 7) **crash** the console display this: Error : EXCEPTION_ACCESS_VIOLATION Address : 0x00007FF669169C40 (the address always changes) [system-info.txt](https://archive.blender.org/developer/F5019519/system-info.txt) [debugmodeall.txt](https://archive.blender.org/developer/F5019810/debugmodeall.txt)

noki paike commented

2018-10-11 04:08:48 +02:00

Added subscriber: @nokipaike

Philipp Oeser commented

2018-10-12 12:27:51 +02:00

Added subscriber: @lichtwerk

Philipp Oeser self-assigned this 2018-10-12 12:27:51 +02:00

Philipp Oeser commented

2018-10-12 12:27:51 +02:00

Confirmed, will have a look later...

1  project_paint_prepare_all_faces paint_image_proj.c 3745 0x1ffbd23 
2  project_paint_begin             paint_image_proj.c 3891 0x1ffc392 
3  paint_proj_new_stroke           paint_image_proj.c 5217 0x200037e 
4  texture_paint_init              paint_image.c      475  0x1fe5611 
5  paint_stroke_test_start         paint_image.c      632  0x1fe5d48 
6  paint_stroke_modal              paint_stroke.c     1215 0x200d1c2 
7  paint_invoke                    paint_image.c      652  0x1fe5df6

Confirmed, will have a look later... ``` 1 project_paint_prepare_all_faces paint_image_proj.c 3745 0x1ffbd23 2 project_paint_begin paint_image_proj.c 3891 0x1ffc392 3 paint_proj_new_stroke paint_image_proj.c 5217 0x200037e 4 texture_paint_init paint_image.c 475 0x1fe5611 5 paint_stroke_test_start paint_image.c 632 0x1fe5d48 6 paint_stroke_modal paint_stroke.c 1215 0x200d1c2 7 paint_invoke paint_image.c 652 0x1fe5df6 ```

Justin Jones commented

2018-10-14 09:46:27 +02:00

Added subscriber: @JJones

Justin Jones commented

2018-10-14 09:46:27 +02:00

My observation: ps.mvert_eval.co- [x] is getting corrupted in a memcpy during python gui call.

Steps:
Put a breakpoint at line 3387 of blender/editors/sculpt_paint/paint_image_proj.c

if (ps->seam_bleed_px > 0.0f) {
    const int lt_vtri[3] = { PS_LOOPTRI_AS_VERT_INDEX_3(ps, lt) };
    ...

Create a single triangle instead in step 1 ( fewest vertices ).
In Step 4 you'll trigger the breakpoint.
In debugger local vars, go to ps.mvert_eval.co and set a data breakpoint on that data.
In step 5 you'll trigger the data breakpoint - this is where the corruption occurs:

1   __memcpy_avx_unaligned         memcpy-avx-unaligned.S  101  0x7ffff6694fa8 
2   MEM_lockfree_dupallocN         mallocn_lockfree_impl.c 188  0x4179ea1      
3   template_ID_tabs               interface_templates.c   868  0x2e380f3      
4   ui_template_id                 interface_templates.c   940  0x2e38420      
5   uiTemplateIDTabs               interface_templates.c   1005 0x2e386ad      
6   UILayout_template_ID_tabs_call rna_ui_gen.c            2280 0x3dd563e      
7   RNA_function_call              rna_access.c            6689 0x3c2a6e1      
8   pyrna_func_call                bpy_rna.c               5818 0x31d6196      
9   _PyObject_FastCallDict         abstract.c              2316 0x7d12292         
... <More>

Now continue on to step 6 and you'll hit the breakpoint again. The lt_vtri triplet it builds is corrupted because it was built from the corrupted ps.mvert_eval.co triplet which occurred at step 4.

the following edited for conciseness:

Locals		
	lt_vtri	@0x7fffffffd8d0	int[3]
			-217353720	int
			4	int
			0	int
ps	@0x7fffd4133808	ProjPaintState
	mvert_eval	@0x7fffe04816f8	MVert
		bweight	'￤' 	-28/228	0xe4	char
		co	@0x7fffe04816f8	float[3]
				0	float
				0	float
				2.86917e-30	float

My observation: ps.mvert_eval.co- [x] is getting corrupted in a memcpy during python gui call. Steps: Put a breakpoint at line 3387 of blender/editors/sculpt_paint/paint_image_proj.c ``` if (ps->seam_bleed_px > 0.0f) { const int lt_vtri[3] = { PS_LOOPTRI_AS_VERT_INDEX_3(ps, lt) }; ... ``` Create a single triangle instead in step 1 ( fewest vertices ). In Step 4 you'll trigger the breakpoint. In debugger local vars, go to ps.mvert_eval.co and set a data breakpoint on that data. In step 5 you'll trigger the data breakpoint - this is where the corruption occurs: ``` 1 __memcpy_avx_unaligned memcpy-avx-unaligned.S 101 0x7ffff6694fa8 2 MEM_lockfree_dupallocN mallocn_lockfree_impl.c 188 0x4179ea1 3 template_ID_tabs interface_templates.c 868 0x2e380f3 4 ui_template_id interface_templates.c 940 0x2e38420 5 uiTemplateIDTabs interface_templates.c 1005 0x2e386ad 6 UILayout_template_ID_tabs_call rna_ui_gen.c 2280 0x3dd563e 7 RNA_function_call rna_access.c 6689 0x3c2a6e1 8 pyrna_func_call bpy_rna.c 5818 0x31d6196 9 _PyObject_FastCallDict abstract.c 2316 0x7d12292 ... <More> ``` Now continue on to step 6 and you'll hit the breakpoint again. The lt_vtri triplet it builds is corrupted because it was built from the corrupted ps.mvert_eval.co triplet which occurred at step 4. the following edited for conciseness: ``` Locals lt_vtri @0x7fffffffd8d0 int[3] -217353720 int 4 int 0 int ps @0x7fffd4133808 ProjPaintState mvert_eval @0x7fffe04816f8 MVert bweight '￤' -28/228 0xe4 char co @0x7fffe04816f8 float[3] 0 float 0 float 2.86917e-30 float ```

noki paike commented

2018-11-12 16:31:54 +01:00

how is the situation with this bug?
I personally can not verify the event anymore,
but because now when you enter texture paint mode in the 3d view you have to select the painting brush tool for the first paint
so I can not figure out if this bug still exists or not

how is the situation with this bug? I personally can not verify the event anymore, but because now when you enter texture paint mode in the 3d view you have to select the painting brush tool for the first paint so I can not figure out if this bug still exists or not

Justin Jones commented

2018-11-13 04:59:21 +01:00

Yes, Bug is still there:
I updated and used my test file to get crash.. bug is still there. I also tried the original UVsphere steps from scratch and it didn't immediately crash.. but didn't paint either. I then rotated the sphere a bit and tried to draw and then it crashed.

COW:
I had done a bit more debugging since my last post and saw that the context was getting corrupted.. and the MVert data was being reloaded from there. I was looking further into it and it was leading me into the copy on write (COW) stuff which is new and a work in progress. This bug may be due to the unfinished state of COW or due to a memory handling bug or ? In any case I would expect it to cause crashes elsewhere as well.

I hope to get time to look into this bug later this week.

Yes, Bug is still there: I updated and used my test file to get crash.. bug is still there. I also tried the original UVsphere steps from scratch and it didn't immediately crash.. but didn't paint either. I then rotated the sphere a bit and tried to draw and then it crashed. COW: I had done a bit more debugging since my last post and saw that the context was getting corrupted.. and the MVert data was being reloaded from there. I was looking further into it and it was leading me into the copy on write (COW) stuff which is new and a work in progress. This bug may be due to the unfinished state of COW or due to a memory handling bug or ? In any case I would expect it to cause crashes elsewhere as well. I hope to get time to look into this bug later this week.

Philipp Oeser removed their assignment 2018-11-13 09:31:26 +01:00

Sergey Sharybin was assigned by Philipp Oeser

2018-11-13 09:31:26 +01:00

Philipp Oeser commented

2018-11-13 09:31:26 +01:00

Added subscriber: @Sergey

Philipp Oeser commented

2018-11-13 09:31:26 +01:00

Sorry this has been lying around for quite some time (it slipped under my radar...)
Also big thanx for doing the additional debugging!

I can confirm this is still happening with the same backtrace, but wont have enough time to dig deep enough into CoW atm.
I'm stepping down and would kindly ask @Sergey to have a look.

Sorry this has been lying around for quite some time (it slipped under my radar...) Also big thanx for doing the additional debugging! I can confirm this is still happening with the same backtrace, but wont have enough time to dig deep enough into CoW atm. I'm stepping down and would kindly ask @Sergey to have a look.

Dalai Felinto commented

2018-11-13 11:51:32 +01:00

Added subscriber: @dfelinto

Dalai Felinto commented

2018-11-13 11:51:32 +01:00

This seems similar to the underlying issue here: #57565

Justin Jones commented

2018-12-02 05:37:29 +01:00

This bug is now fixed!
I was able to reproduce it before but not after this commit:

dabd661 ("Fix T58150: crash in Texture Paint after changing selection in Edit Mode.", 2018-11-30)

Thanks to Alexander Gavrilov angavrilov@gmail.com!
From his commit:

Texture paint code was retrieving the evaluated mesh from the
original object, which isn't supposed to happen, so the cached
mesh isn't properly cleaned up by Edit Mode toggle.

I assume I should leave it to Sergey or owner to mark resolved.

This bug is now fixed! I was able to reproduce it before but not after this commit: ``` dabd661 ("Fix T58150: crash in Texture Paint after changing selection in Edit Mode.", 2018-11-30) ``` Thanks to Alexander Gavrilov <angavrilov@gmail.com>! From his commit: > Texture paint code was retrieving the evaluated mesh from the > original object, which isn't supposed to happen, so the cached > mesh isn't properly cleaned up by Edit Mode toggle. I assume I should leave it to Sergey or owner to mark resolved.

Brecht Van Lommel commented

2018-12-02 10:32:19 +01:00

Changed status from 'Open' to: 'Resolved'

Brecht Van Lommel closed this issue

2018-12-02 10:32:19 +01: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

crash, texture paint mode #57157