4.0.2 crash while retopo (subdivision + shrinkwrap) #116859

New Issue

sentharn · 2024-01-07T03:38:06+01:00

sentharn commented

2024-01-07 03:38:06 +01:00

System Information
Operating system: Windows-10-10.0.22621-SP0 64 Bits
Graphics card: Intel(R) Arc(TM) A770 Graphics Intel 4.6.0 - Build 31.0.101.4900

Also broken on Ubuntu 23.04/Nvidia GTX 1080, but in a different way (freeze instead of crash, see below).

Blender Version
Broken: version: 4.0.2, branch: blender-v4.0-release, commit date: 2023-12-05 07:41, hash: 9be62e85b727
Worked: Tested back to 3.5, crashes.

Short description of error
Blender has been crashing semi-regularly while retopologizing a sculpted mesh. It seems to do it more when loose edges are involved. Exact cause is unknown hence the vague title, but I do know how to reproduce it.

Exact steps for others to reproduce the error

Open the blend file.
Go into side view.
Use alt + mouse to select the lowest edge loop (i.e., above knee).
Duplicate with shift+D and move the resulting loop around and/or pan the camera around.
You may need to do this a few times but it should crash.

The following do not fix or cause a difference in the crashing:

Factory reset
GPU subdivision

On a Linux system with an NVidia GTX 1080, the same steps should cause blender 4.0.2 to freeze but not crash.

On a debug build, I have gotten various crashes on different stack traces, including:

In glyph_index_from_charcode nearby the code to print the "Manage Asset Libraries from the File Paths section in Preferences" warning
In img_save_png for automatic thumbnail creation (for asset browser presumably)
In depsgraph BKE_scene_update_sound during updates after window refresh

I've also observed but failed to save several other crash locations, mostly related to depsgraph refresh.

All of this makes me think that a mesh operation is corrupting memory that is later used, rather than the crash being caused by any of the above.

EDIT: Potentially wild hair, but I have more consistent crashing with the window zoomed out to view the entire object rather than zoomed in.

EDIT2: Wrong file. Uploaded new one. The correct name is "Crash Test Case.blend" (no 2).

**System Information** Operating system: Windows-10-10.0.22621-SP0 64 Bits Graphics card: Intel(R) Arc(TM) A770 Graphics Intel 4.6.0 - Build 31.0.101.4900 Also broken on Ubuntu 23.04/Nvidia GTX 1080, but in a different way (freeze instead of crash, see below). **Blender Version** Broken: version: 4.0.2, branch: blender-v4.0-release, commit date: 2023-12-05 07:41, hash: `9be62e85b727` Worked: Tested back to 3.5, crashes. **Short description of error** Blender has been crashing semi-regularly while retopologizing a sculpted mesh. It seems to do it more when loose edges are involved. Exact cause is unknown hence the vague title, but I do know how to reproduce it. **Exact steps for others to reproduce the error** 1. Open the blend file. 2. Go into side view. 3. Use alt + mouse to select the lowest edge loop (i.e., above knee). 4. Duplicate with shift+D and move the resulting loop around and/or pan the camera around. 5. You may need to do this a few times but it should crash. The following do not fix or cause a difference in the crashing: * Factory reset * GPU subdivision On a **Linux** system with an NVidia GTX 1080, the same steps should cause blender 4.0.2 to **freeze but not crash.** On a debug build, I have gotten various crashes on different stack traces, including: * In glyph_index_from_charcode nearby the code to print the "Manage Asset Libraries from the File Paths section in Preferences" warning * In img_save_png for automatic thumbnail creation (for asset browser presumably) * In depsgraph BKE_scene_update_sound during updates after window refresh I've also observed but failed to save several other crash locations, mostly related to depsgraph refresh. All of this makes me think that a mesh operation is corrupting memory that is later used, rather than the crash being caused by any of the above. EDIT: Potentially wild hair, but I have more consistent crashing with the window zoomed out to view the entire object rather than zoomed in. EDIT2: Wrong file. Uploaded new one. The correct name is "Crash Test Case.blend" (no 2).

crash_asset.jpg

149 KiB

Crash Test Case.blend

7.9 MiB

crash_thumb.jpg

148 KiB

blender_debug_output.txt

203 B

blender_system_info.txt

15 KiB

crash_audio.jpg

16 KiB

👀 1

sentharn added the

labels 2024-01-07 03:38:07 +01:00

sentharn commented

2024-01-07 03:41:39 +01:00

Edit: This is the correct test case file! My bad. The other file is for 3.5.

Crash Test Case.blend

7.9 MiB

Iliya Katushenock added

and removed

labels 2024-01-07 13:10:14 +01:00

Pratik Borhade commented

2024-01-08 06:33:15 +01:00

Not able to redo the crash in 4.1 build

sentharn commented

2024-01-08 07:32:52 +01:00

Not able to redo the crash in 4.1 build

Aaaa why didn't I think to test it in 4.1? I can confirm. 4.1 does not crash as of January 3rd, the most convenient build I had locally.

> Not able to redo the crash in 4.1 build Aaaa why didn't I think to test it in 4.1? I can confirm. 4.1 does not crash as of January 3rd, the most convenient build I had locally.

Iliya Katushenock added this to the 4.0 milestone 2024-01-08 09:48:24 +01:00

Philipp Oeser commented

2024-01-08 10:17:18 +01:00

@ThomasDinges : if we are sure 4.0.3 is not going to happen, then this can be closed I think

Pratik Borhade commented

2024-01-11 04:07:11 +01:00

There won't be another 4.0 corrective release (4.0.3) so closing this report.
We can still keep it open if you're able to confirm the crash in 3.6LTS build

There won't be another 4.0 corrective release (4.0.3) so closing this report. We can still keep it open if you're able to confirm the crash in 3.6LTS build

Philipp Oeser commented

2024-02-12 11:42:42 +01:00