Bug 111218 - Segmentation fault in nv50_ir::NVC0LegalizeSSA::handleDIV when dividing result of textureSize
Summary: Segmentation fault in nv50_ir::NVC0LegalizeSSA::handleDIV when dividing resul...
Status: RESOLVED DUPLICATE of bug 111167
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/nouveau (show other bugs)
Version: 19.0
Hardware: x86-64 (AMD64) Linux (All)
: medium major
Assignee: Nouveau Project
QA Contact: Nouveau Project
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-07-25 18:38 UTC by mmgrqnv
Modified: 2019-08-08 09:19 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:

Attachments
Source of small program and somewhat minimized shaders (3.52 KB, application/x-compressed-tar)
2019-07-25 18:38 UTC, mmgrqnv 		Details
View All

Description mmgrqnv 2019-07-25 18:38:46 UTC 
Created attachment 144869 [details]
Source of small program and somewhat minimized shaders

Hi!

I was looking into a crash[1] in latest version of Blender, which turned out to be a crash in the Nouveau shader code generator.
The crash occurs when linking shaders. I traced the crash to the following lines in the shader code:

  ivec2 cell_co = ivec2(3, 2);
  int cell_per_row = textureSize(irradianceGrid, 0).x / cell_co.x;
  cell_co.x *= cell % cell_per_row;
  cell_co.y *= cell / cell_per_row;

The crash seems to occur when the result of dividing textureSize() value is later used in division or modulo operations. Replacing the textureSize() call with a constant avoids the crash. Replacing the division and modulo operations with simple assignment (but keeping the first division / cell_co.x) also avoids the crash.
This is the relevant stack trace:

(gdb) bt
#0  nv50_ir::NVC0LegalizeSSA::handleDIV (this=this@entry=0x7fffffffba50, i=i@entry=0x555555e592c0) at ../src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp:54
#1  0x00007ffff2e6b38b in nv50_ir::NVC0LegalizeSSA::visit (this=0x7fffffffba50, bb=<optimized out>) at ../src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp:334
#2  0x00007ffff2dc40d8 in nv50_ir::Pass::doRun (this=this@entry=0x7fffffffba50, func=<optimized out>, ordered=ordered@entry=false, skipPhi=skipPhi@entry=true)
    at ../src/gallium/drivers/nouveau/codegen/nv50_ir_bb.cpp:495
#3  0x00007ffff2dc41b4 in nv50_ir::Pass::doRun (this=this@entry=0x7fffffffba50, prog=prog@entry=0x555555e6e9f0, ordered=ordered@entry=false, skipPhi=skipPhi@entry=true)
    at ../src/gallium/drivers/nouveau/codegen/nv50_ir_bb.cpp:466
#4  0x00007ffff2dc4273 in nv50_ir::Pass::run (this=this@entry=0x7fffffffba50, prog=prog@entry=0x555555e6e9f0, ordered=ordered@entry=false, skipPhi=skipPhi@entry=true)
    at ../src/gallium/drivers/nouveau/codegen/nv50_ir_bb.cpp:457
#5  0x00007ffff2e66dd4 in nv50_ir::TargetNVC0::runLegalizePass (this=<optimized out>, prog=0x555555e6e9f0, stage=<optimized out>) at ../src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp:3145
#6  0x00007ffff2dc150f in nv50_ir_generate_code (info=info@entry=0x555555dcd9f0) at ../src/gallium/drivers/nouveau/codegen/nv50_ir.cpp:1265
#7  0x00007ffff2e0988a in nvc0_program_translate (prog=prog@entry=0x555555d79fc0, chipset=<optimized out>, debug=debug@entry=0x5555557a74c8) at ../src/gallium/drivers/nouveau/nvc0/nvc0_program.c:624
#8  0x00007ffff2e1121d in nvc0_sp_state_create (pipe=0x5555557a7100, cso=0x7fffffffc490, type=1) at ../src/gallium/drivers/nouveau/nvc0/nvc0_state.c:605
#9  0x00007ffff3042963 in st_create_fp_variant (st=<optimized out>, stfp=stfp@entry=0x555555d74db0, key=key@entry=0x7fffffffc630) at ../src/mesa/state_tracker/st_program.c:1231
#10 0x00007ffff3045253 in st_get_fp_variant (st=<optimized out>, stfp=0x555555d74db0, key=0x7fffffffc630) at ../src/mesa/state_tracker/st_program.c:1258
#11 0x00007ffff3045a7c in st_precompile_shader_variant (st=st@entry=0x5555557a4c10, prog=prog@entry=0x555555d74db0) at ../src/mesa/state_tracker/st_program.c:1965
#12 0x00007ffff30ece0b in st_program_string_notify (ctx=<optimized out>, target=<optimized out>, prog=0x555555d74db0) at ../src/mesa/state_tracker/st_cb_program.c:250
#13 0x00007ffff3112f85 in st_link_shader (ctx=0x55555578aed0, prog=0x5555557b6fd0) at ../src/mesa/state_tracker/st_glsl_to_tgsi.cpp:7461
#14 0x00007ffff30b5729 in _mesa_glsl_link_shader (ctx=ctx@entry=0x55555578aed0, prog=prog@entry=0x5555557b6fd0) at ../src/mesa/program/ir_to_mesa.cpp:3174
#15 0x00007ffff3000f8d in link_program (no_error=<optimized out>, shProg=<optimized out>, ctx=<optimized out>) at ../src/mesa/main/shaderapi.c:1206
#16 link_program_error (ctx=0x55555578aed0, shProg=0x5555557b6fd0) at ../src/mesa/main/shaderapi.c:1286
#17 0x00005555555553f2 in test_compile ()
#18 0x000055555555586b in main ()

I attach a small program along with preprocessed and *somewhat* minimized shader code that reproduces the problem on my computer. This code crashes 100% of the time.

To reproduce the crash:
$ gcc -Wall -o shad shad.c -lX11 -lGL -lGLU -lGLEW
$ ./shad s0vert.i s1frag.i s2geom.i
Compilation successful!
Segmentation fault


System information:
Ubuntu 18.04.2 LTS
Linux-4.15.0-55-generic-x86_64
Graphics card: NVIDIA Corporation GF108 [GeForce GT 730] (rev a1)
Graphics card driver: NVC1 nouveau 4.3 (Core Profile) Mesa 19.0.2
Using GNOME under X
libgl1-mesa-dri: 19.0.2-1ubuntu1.1~18.04.2

The original Blender crash report along with full shader source dump can be found here:
[1] https://developer.blender.org/T67534
Comment 1 Ilia Mirkin 2019-07-25 18:50:19 UTC 
I suspect that the issue is that cell is 0 (perhaps it's in a loop that's unrolled). This is fixed by https://cgit.freedesktop.org/mesa/mesa/commit/?id=7493fbf032f5bcbf4c48187bc089c9a34f04a1d5

Note that this will only happen in debug mesa builds.
Comment 2 mmgrqnv 2019-07-25 19:00:27 UTC 
Hi! Thank you for the very quick response!

You are right! The value of cell was 0. Replacing that with 1 also avoids the crash.
Do you know if there are any binary packages available that include that commit?
Comment 3 Ilia Mirkin 2019-07-25 19:07:43 UTC 
(In reply to mmgrqnv from comment #2)
> Hi! Thank you for the very quick response!
> 
> You are right! The value of cell was 0. Replacing that with 1 also avoids
> the crash.

[By the way, implicit in that isn't just that it's 0, but that it's statically determinable to be 0.]

> Do you know if there are any binary packages available that include that
> commit?

Sorry, that's not my forté... I think there are some Ubuntu PPA's which track mesa master? Perhaps something for Fedora Rawhide? There are a thousand binary distros, and I use none of them, so it's hard to keep track.
Comment 4 mmgrqnv 2019-07-26 06:29:11 UTC 
I'm trying to build from source, but I can't get meson to produce the nouveau_dri.so library. The documentation says:

  If you built the DRI hardware drivers, you'll also see the DRI drivers:
    -rwxr-xr-x   1 brian users 16895413 Jul 21 12:11 i915_dri.so
    -rwxr-xr-x   1 brian users 16895413 Jul 21 12:11 i965_dri.so
    -rwxr-xr-x   1 brian users 11849858 Jul 21 12:12 r200_dri.so
    -rwxr-xr-x   1 brian users 11757388 Jul 21 12:12 radeon_dri.so

... but that is not what I am seeing, the only libraries I get are:

  $ find . -iname "*dri*.so" 
  ./builddir/src/mesa/drivers/dri/libmesa_dri_drivers.so
  ./builddir/src/gallium/targets/dri/libgallium_dri.so

I tried:

  $ meson configure builddir/ -Ddri-drivers=nouveau -Dgallium-drivers=nouveau

but that does not help.
Could you please point me somewhere that explains how to get the nouveau_dri.so library?
Comment 5 Ilia Mirkin 2019-07-26 12:43:12 UTC 
(In reply to mmgrqnv from comment #4)
> I'm trying to build from source, but I can't get meson to produce the
> nouveau_dri.so library. The documentation says:
> 
>   If you built the DRI hardware drivers, you'll also see the DRI drivers:
>     -rwxr-xr-x   1 brian users 16895413 Jul 21 12:11 i915_dri.so
>     -rwxr-xr-x   1 brian users 16895413 Jul 21 12:11 i965_dri.so
>     -rwxr-xr-x   1 brian users 11849858 Jul 21 12:12 r200_dri.so
>     -rwxr-xr-x   1 brian users 11757388 Jul 21 12:12 radeon_dri.so
> 
> ... but that is not what I am seeing, the only libraries I get are:
> 
>   $ find . -iname "*dri*.so" 
>   ./builddir/src/mesa/drivers/dri/libmesa_dri_drivers.so
>   ./builddir/src/gallium/targets/dri/libgallium_dri.so

This looks correct.

> 
> I tried:
> 
>   $ meson configure builddir/ -Ddri-drivers=nouveau -Dgallium-drivers=nouveau
> 
> but that does not help.
> Could you please point me somewhere that explains how to get the
> nouveau_dri.so library?

I think you forgot to "install". I'd recommend putting it into some prefix, e.g. ~/install (which you can tell meson to do with --prefix=foo), and then you can test with LD_LIBRARY_PATH=~/install ... (not 100% the '~' actually works in the LD_LIBRARY_PATH though)
Comment 6 mmgrqnv 2019-07-26 13:09:04 UTC 
That was it. I can confirm that the commit you linked fixes my problem.
I will mark this bug as a duplicate of 111167 and close.
Thank you very much for your help!

*** This bug has been marked as a duplicate of bug 111167 ***
Comment 7 Ilia Mirkin 2019-07-26 13:13:41 UTC 
(In reply to mmgrqnv from comment #6)
> That was it. I can confirm that the commit you linked fixes my problem.
> I will mark this bug as a duplicate of 111167 and close.
> Thank you very much for your help!
> 
> *** This bug has been marked as a duplicate of bug 111167 ***

By the way, what distro is shipping mesa built with asserts enabled? Our (mesa's) assumption has always been that distros would NOT have asserts enabled in the binaries they ship to users. [And this issue only pops up in an assert.]
Comment 8 mmgrqnv 2019-07-26 14:31:35 UTC 
This was on Ubuntu 18.04.2 LTS.
Specific package version: libgl1-mesa-dri: 19.0.2-1ubuntu1.1~18.04.2.
Comment 9 Timo Aaltonen 2019-08-08 09:19:47 UTC 
for the record, we already set '-Db_ndebug=true' which was supposed to disable debug builds (and asserts) with meson

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.