Page MenuHome

Crash when opening file
Closed, ResolvedPublic

Description

System Information
Operating system: Windows-10-10.0.18362-SP0 64 Bits
Graphics card: GeForce RTX 2060 SUPER/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 442.92

Blender Version
Broken: version: 2.90.0 Beta, branch: master, commit date: 2020-08-04 18:05, hash: rB97be726f9319

Short description of error
Blender crashes when opening file directly

Exact steps for others to reproduce the error

Open file by dragging it on to blender.exe file. Or run command blender T79533.blend in console

Event Timeline

What are steps to reproduce? Just keep switching from wireframe to rendered shading?

When crash happens, crash file should be mentioned in the end of blender_debug_output.txt file. can you upload that file as well?

That .text is included in .zip that was after crash, i used especially blender_debug_log.cmd to launch blender before. Logs from today and when video goes dark = crash but sometimes you have to switch much much more to even get crash if not at all. Maybe this is unresolveable dont know or just GPU hiccup.


Little update, digged up old Udemy pyramid from last year and that can trigger crash too when switching view modes.


Updating crash logs from 4f59e4bddcb0 and crashes still same. Tested 2.83.4 and no problems at all.


This looks like T77910: Sometimes the Viewport is damaged. could be the same / related?

Do not know, in some angles reminds that too but for me sometimes mesh faces could reach infinite distance like on my picture. I really do not know and i give info as much blender debug launchers give. Last test i made was Aug 7 and those bugs prevented me testing further and now i use 2.83.4. I too started from clean settings like i always do if moving major versions and set up my personal settings again.

Drag and dropping .blend to blender.exe causes instant crash sometimes, even if .blend is saved fresh from 2.9 c5519d4b6f7f. User prefs was set up fresh again too. Strange is that only glitch workaround gives more info than others but stops in middle as you see in log. I am no programmer.

Very weird is that when launching with blender_debug_gpu.cmd then it is very hard to get crash, weird or it is really a coincidence.

I am not sure but could this be connected somehow when opening files and something happens in time when opening? Appending objects then all works fine.

YAFU (YAFU) added a subscriber: YAFU (YAFU).EditedAug 18 2020, 12:21 PM

This looks like the problem that many of us are randomly having:
https://developer.blender.org/T77910

Edit:
Oh, Philipp already mentioned it.

Richard Antalik (ISS) renamed this task from Crash and autosaved corruptions/defects to Crash when opening file.Aug 19 2020, 12:08 AM
Richard Antalik (ISS) changed the task status from Needs Triage to Confirmed.
Richard Antalik (ISS) updated the task description. (Show Details)

I was able to reproduce crash when running command blender.exe T79533.blend

 	atio6axx.dll!00007ffaa7f1b1e7()	Unknown
>	blender.exe!GPU_framebuffer_bind(GPUFrameBuffer * fb) Line 527	C++
 	blender.exe!DRW_draw_render_loop_ex(Depsgraph * depsgraph, RenderEngineType * engine_type, ARegion * region, View3D * v3d, GPUViewport * viewport, const bContext * evil_C) Line 1510	C
 	blender.exe!DRW_draw_view(const bContext * C) Line 1404	C
 	[Inline Frame] blender.exe!view3d_draw_view(const bContext *) Line 1598	C
 	blender.exe!view3d_main_region_draw(const bContext * C, ARegion * region) Line 1622	C
 	blender.exe!ED_region_do_draw(bContext * C, ARegion * region) Line 543	C
 	blender.exe!wm_draw_window_offscreen(bContext * C, wmWindow * win, bool stereo) Line 697	C
 	blender.exe!wm_draw_window(bContext * C, wmWindow * win) Line 825	C
 	blender.exe!wm_draw_update(bContext * C) Line 1028	C
 	blender.exe!WM_main(bContext * C) Line 483	C
 	blender.exe!main(int argc, const unsigned char * * UNUSED_argv_c) Line 548	C
 	[External Code]

This does not look to be the same issue as with CHEST.blend in T77910. but that file may have different issues. File udemy_pyramid.blend opened without problems.
Perhaps these glitches occur only with somehow broken files?

In any case this stack trace looks like it may be closer to the actual problem, so I will confirm this.

CC @Clément Foucault (fclem)

I think those were not broken as i saved even fresh files from latest 2.9 build and still sometimes crashes occurred or those infinite reaching planes. If i have way to get better info i would give but now i do not know what to give anymore. 2.83.4 do not have any of that if compared to 2.9 latest builds.

Just in case i post my config if it gives something useful at all(it is made fresh on e157573fab2a build, not just moved from older one)

No error on my drive as i tested even with other fresh ssd drive.

Edit 20.08.2020: Friend confirmed same thing, about 30-40% happens when opening file and there will be crashes.

Still same as with build ebf10b72b05f, this time crash is again when switching modes and when i hit shading mode then crash came.

Again, i set up my settings from fresh and did not port my previous to current build. Just to be sure.

Ok I was able to reproduce on Windows + NVidia but only on release mode.

It seems to me that the issue is threading related (cc @Jeroen Bakker (jbakker)) as it vanished as soon as I'm using -t 1 parameter. I could not get any debug callstack trace.

One thing that got me thinking it was threading related, is that during one of my test, the biggest box got smooth shaded even if it is not in reallity.

So it might be related to something like T79038.

@Clément Foucault (fclem) to get the stack trace you can always comment out drw_mesh_batch_cache_check_available(task_graph, me); in draw_cache_impl_mesh.c

No idea about that, but i really hope that 2.90 final do not include this anomaly as i am quick runner with new versions because features will get better and usability becomes more and more comfortable with every new release. Somehow something is changed that 2.83.4 is solid as rock but 2.90 has some weird corruptions when opening, sometimes crash, sometimes models reach to infinite and sometimes are with borked shading in workbench like in first post images or switching shading mode causes a crash.

Config again if that matters at all.

EDIT: some more test, this time crash was when entered edit mode and boom, crash.

And i opened my old Udemy chess(just for another sample) about 17 times until i got heavy anomalies.


second opening

Jeroen Bakker (jbakker) edited projects, added BF Blender (2.91); removed BF Blender.

Workaround added for 2.90. I keep this ticket open to research a better solution or to make the workaround permanent.

Definitely i test this when builder builds new build to see if it helped.

It really seems that 21cb6f09ffa8 really has fixed this horrible menace bug, i opened file and rapidly changed shadinga and ZERO crash. Little bug can cause so many errors and anomalies. Glad it is over. Thank you developers for detecting this and finding a cause.

I could not reproduce any of those issues anymore. I opened different files about 40-60x and all fine in every way. Please decide what you do with this report, close it or?

EDIT: 26.08.2020 18:35: Update note, used today lot of times and still very solid and zero anomalies and crashes.

EDIT: 28.08.2020 13.05: Still using latest 2.90 build and solid as rock. Actually would be really interested what was that if it is possible to describe to non-programmer generalist? Really this fixed that bug?

BLI_task_graph_work_and_wait(task_graph); ? Makes some threading wait until finishes? if i read it correctly.

Jeroen Bakker (jbakker) closed this task as Resolved.Sep 18 2020, 4:33 PM

We promoted the current work-around to a proper fix.