fresh 2.83 compilation, immediate crash #73939

New Issue

Piotr Arłukowicz · 2020-02-17T19:30:12+01:00

Piotr Arłukowicz commented

2020-02-17 19:30:12 +01:00

System Information
Operating system: Linux-4.19.0-6-amd64-x86_64-with-debian-10.3 64 Bits
Graphics card: GeForce GTS 350M/PCIe/SSE2 NVIDIA Corporation 3.3.0 NVIDIA 340.108 rev3

Blender Version
Blender 2.83 (sub 3), Commit date: 2020-02-17 10:16, Hash cec7db2004
Worked: runs with no errors from command line with -b, or -h. Rendering works properly.

Short description of error
Hard crash after very fresh compilation (configured carefully with cmake-gui). Logs attached. NO idea what's wrong, I suspect GL system and legacy (yet updated) drivers. But 2.82 works (unstable).

debug.txt

blender.crash.txt

Xorg.0.log

**System Information** Operating system: Linux-4.19.0-6-amd64-x86_64-with-debian-10.3 64 Bits Graphics card: GeForce GTS 350M/PCIe/SSE2 NVIDIA Corporation 3.3.0 NVIDIA 340.108 rev3 **Blender Version** Blender 2.83 (sub 3), Commit date: 2020-02-17 10:16, Hash cec7db200452 Worked: runs with no errors from command line with -b, or -h. Rendering works properly. **Short description of error** Hard crash after very fresh compilation (configured carefully with cmake-gui). Logs attached. NO idea what's wrong, I suspect GL system and legacy (yet updated) drivers. But 2.82 works (unstable). [debug.txt](https://archive.blender.org/developer/F8345521/debug.txt) [blender.crash.txt](https://archive.blender.org/developer/F8345523/blender.crash.txt) [Xorg.0.log](https://archive.blender.org/developer/F8345525/Xorg.0.log)

Piotr Arłukowicz commented

2020-02-17 19:30:12 +01:00

Added subscriber: @piotao

Piotr Arłukowicz commented

2020-02-17 21:31:32 +01:00

Very similar behaviour to https://developer.blender.org/T70209 but none of workaround works.

Compilation of Blender 2.83 (sub 4), Commit date: 2020-02-17 19:54, Hash 00227edf4c
gives the same results.

Very similar behaviour to https://developer.blender.org/T70209 but none of workaround works. Compilation of Blender 2.83 (sub 4), Commit date: 2020-02-17 19:54, Hash 00227edf4c1b gives the same results.

Campbell Barton commented

2020-02-18 05:00:28 +01:00

Added subscriber: @ideasman42

Campbell Barton commented

2020-02-18 05:00:28 +01:00

This graphics card model (GForce-350m) is from around ~2010 (link )

Closing since this doesn't meet the system requirements of hardware under 10 years old.

See: https://www.blender.org/download/requirements/

If you're able to bisect the commit which caused this, it may be possible to support, however this cant be guaranteed.

This graphics card model (GForce-350m) is from around ~2010 ([link ](https://www.techpowerup.com/gpu-specs/geforce-gts-350m.c1314)) Closing since this doesn't meet the system requirements of hardware under 10 years old. See: https://www.blender.org/download/requirements/ If you're able to bisect the commit which caused this, it may be possible to support, however this cant be guaranteed.

Campbell Barton commented

2020-02-18 05:00:41 +01:00

Changed status from 'Needs Triage' to: 'Archived'

Campbell Barton closed this issue

2020-02-18 05:00:41 +01:00

Campbell Barton self-assigned this 2020-02-18 05:00:41 +01:00

Piotr Arłukowicz commented

2020-02-18 09:27:04 +01:00

Thank you. I think it's better to look for a newer laptop. No real reason to looking back and hold the development. The only sad thing will be the losss of all nice stickers placed on laptop's lid gained during lots of Blender Conferences.

Piotr Arłukowicz commented

2020-02-18 18:25:56 +01:00

However, after a bit closer investigation, it seems that this crash is caused in the line which is not related to graphics at all. Just SIGSEGV due to some garbled pointer I believe. Here is gdb output.

Thread 1 "blender" received signal SIGSEGV, Segmentation fault.
0x0000555558f1d487 in GPU_draw_list_command_add ()
(gdb) backtrace

0 0x0000555558f1d487 in GPU_draw_list_command_add ()
1 0x0000555556ccffcd in draw_call_batching_flush.isra ()
2 0x0000555556cd105f in drw_draw_pass_ex ()
3 0x0000555556cee452 in workbench_deferred_draw_scene ()
4 0x0000555556ceabd3 in workbench_solid_draw_scene ()
5 0x0000555556cc9a10 in drw_engines_draw_scene ()
6 0x0000555556cc9e0a in DRW_draw_render_loop_ex ()
7 0x00005555572b2167 in view3d_main_region_draw ()
8 0x0000555556ed9e21 in ED_region_do_draw ()
9 0x0000555556bf116a in wm_draw_update ()
10 0x0000555556bef1d0 in WM_main ()
11 0x00005555569f092e in main ()

Please check this line:

list->cmd_len++;
from GPU_draw_list_command_add function in blender/source/blender/gpu/intern/gpu_batch.c
It seems that this is the cause of the crash. Therefore list is an invalid pointer. This is so far the result of my poor-man-investigation. I printed out the values which are passed to this function. They are:

list=0xc5cf6318, v_first=0, v_count=3, i_first=0, i_const=1

And the contents of list is the problem. Am I right?

However, after a bit closer investigation, it seems that this crash is caused in the line which is not related to graphics at all. Just SIGSEGV due to some garbled pointer I believe. Here is gdb output. Thread 1 "blender" received signal SIGSEGV, Segmentation fault. 0x0000555558f1d487 in GPU_draw_list_command_add () (gdb) backtrace - 0 0x0000555558f1d487 in GPU_draw_list_command_add () - 1 0x0000555556ccffcd in draw_call_batching_flush.isra () - 2 0x0000555556cd105f in drw_draw_pass_ex () - 3 0x0000555556cee452 in workbench_deferred_draw_scene () - 4 0x0000555556ceabd3 in workbench_solid_draw_scene () - 5 0x0000555556cc9a10 in drw_engines_draw_scene () - 6 0x0000555556cc9e0a in DRW_draw_render_loop_ex () - 7 0x00005555572b2167 in view3d_main_region_draw () - 8 0x0000555556ed9e21 in ED_region_do_draw () - 9 0x0000555556bf116a in wm_draw_update () - 10 0x0000555556bef1d0 in WM_main () - 11 0x00005555569f092e in main () Please check this line: list->cmd_len++; from GPU_draw_list_command_add function in blender/source/blender/gpu/intern/gpu_batch.c It seems that this is the cause of the crash. Therefore list is an invalid pointer. This is so far the result of my poor-man-investigation. I printed out the values which are passed to this function. They are: list=0xc5cf6318, v_first=0, v_count=3, i_first=0, i_const=1 And the contents of list is the problem. Am I right?

Campbell Barton commented

2020-02-28 02:45:17 +01:00

Changed status from 'Archived' to: 'Needs Developer To Reproduce'

Campbell Barton reopened this issue

2020-02-28 02:45:17 +01:00

Campbell Barton removed their assignment 2020-02-28 02:45:17 +01:00

Clément Foucault was assigned by Campbell Barton

2020-02-28 02:45:17 +01:00

Campbell Barton commented

2020-02-28 02:45:17 +01:00

Added subscriber: @fclem

Campbell Barton commented

2020-02-28 02:45:17 +01:00

Thanks for looking into this.

There are some different code-paths for older hardware, for e.g. USE_MULTI_DRAW_INDIRECT is checked in GPU_draw_list_create and other draw list API calls.

If you are able, could you bisect this to find which commit broke this?

@fclem is this an issue you're aware of?

Thanks for looking into this. There are some different code-paths for older hardware, for e.g. `USE_MULTI_DRAW_INDIRECT` is checked in `GPU_draw_list_create` and other draw list API calls. If you are able, could you bisect this to find which commit broke this? @fclem is this an issue you're aware of?

Piotr Arłukowicz commented

2020-02-29 20:17:19 +01:00

Thank you for support. I did bisect (multiple compilations took nearly a day).
I include bisect log.
However, I'm stuck at a strange revision which do not compile anymore! Compilation was successful from both ends - from 2.82 #77d23b0bd76 to latest 2.83 #e4605cb155b. But apparently something went terribly wrong, or maybe I have some unmet deps in this middle point, because compilation is no longer possible. I include compilation log from where it started to be noisy to the end when it broke.
Due to inability to compile this commit, I'm not sure I've found good bisect, however git was talking I'm one/two steps away at most.
And after git visualize, in gitk I spotted Clement's commits and this constant USE_MULTI_DRAW_INDIRECT somewhere. So we are close!


{F8380557}

Thank you for support. I did bisect (multiple compilations took nearly a day). I include bisect log. However, I'm stuck at a strange revision which do not compile anymore! Compilation was successful from both ends - from 2.82 #77d23b0bd76 to latest 2.83 #e4605cb155b. But apparently something went terribly wrong, or maybe I have some unmet deps in this middle point, because compilation is no longer possible. I include compilation log from where it started to be noisy to the end when it broke. Due to inability to compile this commit, I'm not sure I've found good bisect, however git was talking I'm one/two steps away at most. And after git visualize, in gitk I spotted Clement's commits and this constant USE_MULTI_DRAW_INDIRECT somewhere. So we are close! ```{F8380556} {F8380557} ```

Piotr Arłukowicz commented

2020-02-29 20:19:04 +01:00

I'm not sure I included files correctly, where they go again:

bisect.log

compil.txt

My current git status is telling this:

pio@zoan᛬blender❯ git status
HEAD detached at e4605cb155b
You are currently bisecting, started from branch '77d23b0bd76'.
  (use "git bisect reset" to get back to the original branch)

nothing to commit, working tree clean

I'm not sure I included files correctly, where they go again: [bisect.log](https://archive.blender.org/developer/F8380562/bisect.log) [compil.txt](https://archive.blender.org/developer/F8380564/compil.txt) My current git status is telling this: ``` pio@zoan᛬blender❯ git status HEAD detached at e4605cb155b You are currently bisecting, started from branch '77d23b0bd76'. (use "git bisect reset" to get back to the original branch) nothing to commit, working tree clean ```

Piotr Arłukowicz commented

2020-03-04 23:21:52 +01:00

Well, I've solved this issue using unusual brute force method: I've bought a new powerful laptop with RTX 2060. I hope this will live at least as long, as previous GTX350M.

However, I observe a very similar problem (the same error exactly) on our old computer laboratories which are equipped with GTX 260 cards, which have also OpenGL 3.3 (according to https://feedback.wildfiregames.com/report/opengl/device/GeForce%20GTX%20260). So, this will be very valuable to somehow manage Blender to work in this configuration. The error is even more annoying, because Blender 'works' for a minute or two, and then crashes. Usually this happens when new window has to be drawn, huge redraw of the screen area happens or shader compilation starts. The error has something with GLX errors and goes right from driver. Newer versions just do not work, causing crash mentioned above.

Well, I've solved this issue using unusual brute force method: I've bought a new powerful laptop with RTX 2060. I hope this will live at least as long, as previous GTX350M. However, I observe a very similar problem (the same error exactly) on our old computer laboratories which are equipped with GTX 260 cards, which have also OpenGL 3.3 (according to https://feedback.wildfiregames.com/report/opengl/device/GeForce%20GTX%20260). So, this will be very valuable to somehow manage Blender to work in this configuration. The error is even more annoying, because Blender 'works' for a minute or two, and then crashes. Usually this happens when new window has to be drawn, huge redraw of the screen area happens or shader compilation starts. The error has something with GLX errors and goes right from driver. Newer versions just do not work, causing crash mentioned above.

Campbell Barton commented

2020-03-04 23:57:27 +01:00

If you run into revisions which don't build while bisecting use git bisect skip.

If you run into revisions which don't build while bisecting use `git bisect skip`.

Clément Foucault commented

2020-05-25 16:21:28 +02:00

Changed status from 'Needs Developer To Reproduce' to: 'Archived'

Clément Foucault closed this issue

2020-05-25 16:21:28 +02:00

Clément Foucault commented

2020-05-25 16:21:28 +02:00

I'm closing this one since this GPU is not supported anymore. However if anyone feels like picking it up feel free.

The thing that I would test is if just setting glew_arb_base_instance_is_supported to false fixes the issue. Also would be nice to know if the release version of blender (from the buildbot) does work.

I'm closing this one since this GPU is not supported anymore. However if anyone feels like picking it up feel free. The thing that I would test is if just setting glew_arb_base_instance_is_supported to false fixes the issue. Also would be nice to know if the release version of blender (from the buildbot) does work.

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

fresh 2.83 compilation, immediate crash #73939