Page MenuHome

Memory leak and crash when playing with X-ray value in Wireframe mode
Closed, ArchivedPublic


System Information
sys_info.txt file attached

Blender Version
One crash in 4dd0a90f4213 and one in 11f2c65128dc (see the attached crash reports)

When modifying the X-ray alpha amount while in Wireframe mode, Blender crashed or a memory leak was triggered freezing the entire system. When was crashing, it managed to write a crash report. When the memory leak is triggered and progressively starts "eating" all the free memory (I see this in an OS sys-tray widget which shows me in real time the amount of used and free memory), the entire system freezes and no crash report is written before blender crash.

Exact steps for others to reproduce the error
I have a hard time finding the exact steps to duplicate this and by now I only made it crash 4 or 5 times from around 20 attempts, but the general path is this:

  1. Start new file with Eevee as default
  2. Switch to Workbench
  3. Select the Transform tool and play with the Gizmo modes
  4. Scale/move/rotate the default cube
  5. Delete camera, delete light
  6. Switch back and forth between solid mode and wireframe mode
  7. Go to the Shading pop-over and set from keyboard the X-ray alpha value

Suspecting some issues with the video drivers, I run blender with --debug-gpu. I wasn't able to make it crash again while running in this mode, but few lines caught my attention (see file attached):
Received X11 Error: error text: GLXBadFBConfig
Received X11 Error: error text: BadMatch (invalid parameter attributes)
uiItemEnumR_string_prop: enum property value not found: MATERIAL
nouveau: kernel rejected pushbuf: Invalid argument
Warning: Pass : Edit Mesh Face Overlay Pass, Uniform 'viewportSize' not found!
Warning: Pass : Edit Mesh Face Overlay Pass, Uniform 'edgeScale' not found!

If not enough useful info is available in the attached files, please give me some instructions about what I should do next.



Event Timeline

voxel9 created this task.Jan 3 2019, 5:39 PM
Sebastian Parborg (zeddb) triaged this task as Needs Information from User priority.

I can't seem to reproduce this on my AMD 290X in linux. So I'm also guessing this is a driver issue.

I have a few questions:

  1. Why are you using nouveau instead of the official nvidia drivers? Does this happen with the official drivers?
  2. You have APU. I'm not sure, but I don't think that the GPU on you CPU would be that much slower than you nvidia card. So you could try to use the AMD GPU instead which should have better drivers.
  1. That was the default driver enabled by the LinuxMint (LM) distribution. When I tried a switch to nVidia drivers (in LM 18.3 though) I got a blank screen with jagged colored sparkles :) I didn't make another attempt to switch after the upgrade to 19.1. But I'll take a deep breath tomorrow and I'll make some experiments ...
  2. I tried using only APU GPU in LM 18.3, but Blender was displaying only black objects in edit mode, and black triangles on faces in object mode. So, basically, not able to work at all. I'll try tomorrow to see if it is happening the same in LM 19.1.

My hope was that a developer might see something useful in those dumps that could give us a hint about the issue and where to dig further...

Note for anyone investigating this, when reproducing those steps you may run into the following crash unrelated bug - D4167.

This is related to the uiItemEnumR_string_prop: enum property value not found: MATERIAL warning present in this report.

@voxel9 we only care about the latest crash you get. So for now let's stick the conversation to the problems you have with 11f2c65128dc .
In fact the crash you get with 4dd0a90f4213 is unrelated.

@Clément Foucault (fclem) next time you are with your MESA driver station can you see if you can repro this?

I changed the video drivers from nouveau 1:1.0.15-2 to nvidia 340.107 as well as Blender to 4431c5825bf2 2019-01-03 and no crash occurred regardless how much I played with the Transform tool and gizmo or changed the display mode, shading options or the render engine.
Is there any particular interest in finding what's happening with the nouveau driver? I can switch back and try making it crash again for further investigations. Or is it enough to stick with the nvidia driver and only mention in the documentation's Troubleshooting section that the users may encounter issues when using nouveau?

This is then a bug with nouveau and not blender.
Nvidia has been really stubborn with making it hard to develop open source drivers for their cards. So the driver is not working that great.
And because nouveau is not able to get reclocking working on newer generation cards (the performance will be horrible if the driver works at all), I don't really see why we should support it.

@Clément Foucault (fclem) ?

Clément Foucault (fclem) closed this task as Archived.Jan 8 2019, 12:06 PM

Well seems to be a problem in nouveau handling the multiple gl contexts.

I don't see how much we can do from our end.

The X11 errors and warnings are to be ingnored.