Created attachment 1772339 [details]
crash log blender auto output /tmp/Blender.crash.txt

Removed because I don't know if the gentoo case is relevant.

The Gentoo case is relevant because it includes an important upstream bug. Please put it back.
Also see https://developer.blender.org/T83488. 

I was able to reproduce the bug with AMD Ryzen 5 2550U with Vega 8 suggesting the problem is possibly linked with llvm and radeonsi.

OK. i rewrite my post.

Setting the bug as public as no sensitive data is found.

I'm seeing presumably the same issue, fedora 34 x86_64. The segfault appears with the 'cycles' render engine, either in the viewport or rendering the scene, the 'eevee' render engine is fine and otherwise blender appears to be ok.

This is unrelated to greasepencil, to reproduce:

1. Open blender with the default scene cube
2. Select 'Render Properties'
3. 'Render Engine', select 'Cycles'
4. segfault

I have older AMD graphics, using default radeon driver:

    VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Kaveri [Radeon R6 Graphics] (prog-if 00 [VGA controller])

*** Bug 1956451 has been marked as a duplicate of this bug. ***

Narrowing the traceback, the crashes occurred on 
File "/usr/share/blender/2.92/scripts/addons/cycles/engine.py", line 176 in render
File "/usr/share/blender/2.92/scripts/addons/cycles/__init__.py", line 83 in render

as listed by the original reporter. The possible curprit is depsgraph (https://wiki.blender.org/wiki/Source/Depsgraph) incompatibility with python 3.9 as the report on #1956451 noticed the same cycle rendering on Fedora 33 is unaffected.

Bug filed upstream for further investigation:
https://developer.blender.org/T88042

thanks for investigation.
Blender crash Bruno Postle says as same problem on my PC.

Same crash as above, completely consistent.  Graphics card is Radeon RX 550.

Updated to f34 from f32, was working in f32.

1. launch blender, click the banner if necessary to make it go away
1a. leave the initial cube object there
2. press z and move the mouse upwards (to select rendered view)
3. go to the render properties editor (the little camera icon probably on the pane on the lower right)
4. change render engine from Eevee to Cycles
5. in a moment, it will crash with segfault

Same crash report as shown above, most interesting lines
blender(_ZN3ccl11BlenderSync13sync_geometryERN2BL9DepsgraphERNS1_6ObjectES5_bbPNS_8TaskPoolE+0x87b) [0x5586945517bb]
blender(_ZN3ccl11BlenderSync11sync_objectERN2BL9DepsgraphERNS1_9ViewLayerERNS1_23DepsgraphObjectInstanceEfbbRNS_20BlenderObjectCullingEPbPNS_8TaskPoolE+0xb77) [0x558694552a27]
blender(_ZN3ccl11BlenderSync12sync_objectsERN2BL9DepsgraphERNS1_11SpaceView3DEf+0x569) [0x558694554759]
blender(_ZN3ccl11BlenderSync9sync_dataERN2BL14RenderSettingsERNS1_9DepsgraphERNS1_11SpaceView3DERNS1_6ObjectEiiPPv+0x1f2) [0x558694503f22]
blender(_ZN3ccl14BlenderSession11synchronizeERN2BL9DepsgraphE+0x459) [0x558694513499]

It's a blocker for migrating our other machines, since we need the Cycles render engine.

Of note: the blender console output errors of Apr 16 are there all the time, apparently unrelated.
So the crash.txt attachment seems to be the most relevant text.

One other possible useful tidbit: Same version (2.92), run via flatpak from flathub, does not crash in this way.

Oh!  I just reproduced it on a laptop with Intel UHD graphics.

So this seems like a basic bug, not related to a particular graphics card.

Uh, one more comment, sorry about the spam.

I think there are two separate bugs.  The original attached stdout is documenting a bug that is radeon specific.  It might be worthy of investigation, but doesn't cause a crash, and might not be important.

The original attached crash.txt is documenting a bug that is NOT radeon specific, and is more egregious.  Just imagine somebody switching to cycles rendering for a quick check after working for a while and then BOOM.  Forgot to save....  That would be painful--potentially a lot of lost work.

For what it's worth, the segfault is 100% reproduceable for me with blender-2.92.0-5.fc34.x86_64, but does not reproduce at all with a binary downloaded from https://www.blender.org/download/Blender2.92/blender-2.92.0-linux64.tar.xz/.

Something changed inside cycle rendering on Fedora 34 build. I don't know how yet.

Blender 2.93 recently landed with a fix related to cycle. It seems the crashing cycle rendering is specific to 2.92.0. I successfully tested blender 2.93.0 which addressed the issue. For those willing to test right way, a scratch build is available: https://koji.fedoraproject.org/koji/taskinfo?taskID=69269842.

FEDORA-2021-95e340dc3d has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-95e340dc3d

FEDORA-2021-95e340dc3d has been pushed to the Fedora 34 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-95e340dc3d`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-95e340dc3d

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2021-ec68aa382b has been pushed to the Fedora 33 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-ec68aa382b`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-ec68aa382b

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2021-ec68aa382b has been pushed to the Fedora 33 stable repository.
If problem still persists, please make note of it in this bug report.

FEDORA-2021-95e340dc3d has been pushed to the Fedora 34 stable repository.
If problem still persists, please make note of it in this bug report.