| Summary: | Segmentation fault in nv50_ir::NVC0LegalizeSSA::handleDIV when dividing result of textureSize | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | mmgrqnv |
| Component: | Drivers/DRI/nouveau | Assignee: | Nouveau Project <nouveau> |
| Status: | RESOLVED DUPLICATE | QA Contact: | Nouveau Project <nouveau> |
| Severity: | major | ||
| Priority: | medium | CC: | mmgrqnv |
| Version: | 19.0 | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: | Source of small program and somewhat minimized shaders | ||
|
Description
mmgrqnv
2019-07-25 18:38:46 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. 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? (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. 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?
(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) 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 *** (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.] This was on Ubuntu 18.04.2 LTS. Specific package version: libgl1-mesa-dri: 19.0.2-1ubuntu1.1~18.04.2. 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.