Summary: | [opencl] segfault when running any opencl programs (like clinfo) | ||
---|---|---|---|
Product: | Mesa | Reporter: | Paulo Dias <paulo.miguel.dias> |
Component: | Other | Assignee: | mesa-dev |
Status: | RESOLVED FIXED | QA Contact: | mesa-dev |
Severity: | normal | ||
Priority: | medium | ||
Version: | git | ||
Hardware: | Other | ||
OS: | All | ||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Attachments: |
output of "valgrind clinfo"
gdb output and backtrace for clinfo attachment-27601-0.html |
Description
Paulo Dias
2015-11-24 07:25:51 UTC
Without debug symbols, the backtrace isn't that useful. Before you install the extra dbg packages or anything else try this patch http://patchwork.freedesktop.org/patch/65914/ (In reply to Emil Velikov from comment #1) > Without debug symbols, the backtrace isn't that useful. Before you install > the extra dbg packages or anything else try this patch > http://patchwork.freedesktop.org/patch/65914/ As it is Tested-by: Tom Stellard <thomas.stellard@amd.com> and I tried it, too. Soo... Tested-by: Dieter Nützel <Dieter@nuetzel-hh.de> It should go in? (In reply to Dieter Nützel from comment #2) > (In reply to Emil Velikov from comment #1) > > Without debug symbols, the backtrace isn't that useful. Before you install > > the extra dbg packages or anything else try this patch > > http://patchwork.freedesktop.org/patch/65914/ > > As it is > Tested-by: Tom Stellard <thomas.stellard@amd.com> > and > I tried it, too. Soo... > Tested-by: Dieter Nützel <Dieter@nuetzel-hh.de> > > It should go in? Indeed it should. Bth I'm not too excited pushing patches if no one has skimmed through (just like the large series that caused this regression). Either way I'll push it within an hour or two, barring any objection. Hmm. I'm still getting a segfault with the proposed patch. Valgrind and gdb output in a second. Created attachment 120097 [details]
output of "valgrind clinfo"
Created attachment 120098 [details]
gdb output and backtrace for clinfo
Bah, ignore me. I could still reproduce the issue yesterday to the best of my knowledge, but after an llvm/mesa rebuild with the patch applied this morning, things are working correctly... This segfault still happens for me using mesa git, commit ca976e6900dc8ff457ed9dba661d037c616abc59. OpenGL renderer string: Gallium 0.4 on NVE7 OpenGL core profile version string: 4.1 (Core Profile) Mesa 11.2.0-devel (git-ca976e6) #0 pipe_loader_create_screen (dev=0x0) at pipe_loader.c:79 #1 0x00007ffff6177b0a in clover::device::device (this=0x641cd0, platform=..., ldev=<optimized out>) at core/device.cpp:44 #2 0x00007ffff6183226 in clover::create<clover::device, clover::platform&, pipe_loader_device*&> () at ./util/pointer.hpp:230 #3 clover::platform::platform (this=0x7ffff7dc5520 <(anonymous namespace)::_clover_platform>) at core/platform.cpp:35 #4 0x00007ffff612e196 in __static_initialization_and_destruction_0 (__initialize_p=1, __priority=65535) at api/platform.cpp:29 #5 _GLOBAL__sub_I_platform.cpp(void) () at api/platform.cpp:120 #6 0x00007ffff7dea27a in call_init.part () from /lib64/ld-linux-x86-64.so.2 #7 0x00007ffff7dea38b in _dl_init () from /lib64/ld-linux-x86-64.so.2 #8 0x00007ffff7ddbdba in _dl_start_user () from /lib64/ld-linux-x86-64.so.2 #9 0x0000000000000001 in ?? () #10 0x00007fffffffe356 in ?? () #11 0x0000000000000000 in ?? () (In reply to Samuel Pitoiset from comment #8) > This segfault still happens for me using mesa git, commit > ca976e6900dc8ff457ed9dba661d037c616abc59. > > OpenGL renderer string: Gallium 0.4 on NVE7 > OpenGL core profile version string: 4.1 (Core Profile) Mesa 11.2.0-devel > (git-ca976e6) > > #0 pipe_loader_create_screen (dev=0x0) at pipe_loader.c:79 Strange... I wonder if we're getting hit by the issue pointed out to Tom - namely we should cap the ldevs iteration in platform::platform() to the value returned by the second call to pipe_loader_probe. Reason being that second call to pipe_loader_probe() may return smaller count (device has gone missing, enomem, other). Alternatively can someone pin-point the commit that causes this (note you might need to cherry-pick patch in comment 1 to fixup commit ff9cd8a67ca). Thanks Created attachment 120146 [details] attachment-27601-0.html well FWIW it fixed it for me, no more crashes and clinfo and tests works. might be hw specific or a different bug. On Nov 26, 2015 11:02, <bugzilla-daemon@freedesktop.org> wrote: > *Comment # 9 <https://bugs.freedesktop.org/show_bug.cgi?id=93091#c9> on > bug 93091 <https://bugs.freedesktop.org/show_bug.cgi?id=93091> from Emil > Velikov <emil.l.velikov@gmail.com> * > > (In reply to Samuel Pitoiset from comment #8 <https://bugs.freedesktop.org/show_bug.cgi?id=93091#c8>)> This segfault still happens for me using mesa git, commit > > ca976e6900dc8ff457ed9dba661d037c616abc59. > > > > OpenGL renderer string: Gallium 0.4 on NVE7 > > OpenGL core profile version string: 4.1 (Core Profile) Mesa 11.2.0-devel > > (git-ca976e6) > > > > #0 pipe_loader_create_screen (dev=0x0) at pipe_loader.c:79 > > Strange... I wonder if we're getting hit by the issue pointed out to Tom - > namely we should cap the ldevs iteration in platform::platform() to the value > returned by the second call to pipe_loader_probe. Reason being that second call > to pipe_loader_probe() may return smaller count (device has gone missing, > enomem, other). > > Alternatively can someone pin-point the commit that causes this (note you might > need to cherry-pick patch in comment 1 <https://bugs.freedesktop.org/show_bug.cgi?id=93091#c1> to fixup commit ff9cd8a67ca). > > Thanks > > ------------------------------ > You are receiving this mail because: > > - You reported the bug. > > As per comment 10, I'm closing this bug. Samuel, can you please open another bug (or catch me on IRC) with the requested information ? If you have some changes on top of master, please point me to a branch where I can skim through. Thanks |
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.