Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Losing video signal during loading (League of legends and Starcraft 2) #7

Closed
pwnz7777 opened this issue Aug 27, 2014 · 13 comments
Closed
Labels

Comments

@pwnz7777
Copy link

Hi. Using wine i lost video signal and message appears in my monitor OSD (HDMI signal lost). it happens during loading screen ( nearly 100% ) steps to repdroduce:

0 Run Lol/Sc2 choose new game and it start loading (everything normal here)
1 Between 95-100% Screen completly freeze ( even mouse but sound still works )
2 Message (from OSD monitor) HDMI lost video signal
3 After 5 seconds the image comes back but still freeze like (1)
4 loop between 1,2,3 untill i switch to tty console (alt+f1) and kill game, then everything comes back to normally again.

Wine versions that i use

Logs
Winedebug with d3d9 and d3d9adapter - http://pastebin.com/h8kkee05
dmesg - http://pastebin.com/mSCd6UWB

My tests :)

I noticed that if i switch to a normal wine version (which works perfect, only low fps)
and set graphic settings to low if i switch back to patched wine again it works!!!
No video signal lost anymore ... and of course game runs better (from 20-40 fps to 60 stable fps) ...
but if try to set graphic settings to high or medium, computer crash.

With 3DMark06 Benchmark no lost signal here but only show artifacts.

What i think
reading dmesg log i see that every time video signal is lost appears a line what says

[ 1478.334271] radeon 0000:01:00.0: GPU softreset: 0x0000004D (line 5)
[ 1488.565294] radeon 0000:01:00.0: GPU softreset: 0x00000009 (line 46)

it only stops when game process is killed.

i think probably is something wrong with gallium drivers, which is weird cause they work
better than fglrx (more stability in desktop and almost double performance on native games). the
only problem is wine ...

OS:Linux mint 17 qiana
GPU: HD6670
Drivers: Mesa Gallium from from oibaf's ppa
Kernel: 3.13.0-24-generic

Thanks and srry for my english :)

@pwnz7777
Copy link
Author

I just reinstall mint and upgraded kernel to 3.16, problem still persist

@okias
Copy link
Member

okias commented Sep 15, 2014

3DMark06 possibly not fully working - yet, try 3DMark05 or other things.
this seems to be radeon bug. Please try run it with
NINE_TGSI_DUMP=1 NINE_DEBUG=all WINEDEBUG=+d3dadapter,+d3d9,-dbghelp_dwarf wine game.exe

At least SC2 works just fine on HD 6550D, so it's maybe some specific gpu bug.

@okias okias added the bug label Sep 15, 2014
@pwnz7777
Copy link
Author

I used the command you posted above with LOL and SC2, usually i capture wine logs using:
script wine.log
and then running command
NINE_TGSI_DUMP=1 NINE_DEBUG=all WINEDEBUG=+d3dadapter,+d3d9,-dbghelp_dwarf wine game.exe
but it does not work with SC2, it crash even before game start, so just running your command i can only show last few lines from my terminal. those lines appears before and during lost video signal loop
SC2 - http://pastebin.com/fcVqKB8L

With LOL i'm able to capture entire log but it's too big 17 Mb~ so i uploaded it to mega
LOL - https://mega.co.nz/#!J4ghkKhJ!gead66BXkszGvP_xDbPohnxJqa8fWyT1qtTYAOyoAxM

pd: I can make a video and upload it if is necessary

@axeldavy
Copy link

Hi, can you test the last version (based on DRI3 one) and see if the bug is still present ?

@jp-bennett
Copy link

Different game, but almost exactly the same issue. Fedora 21 with mesa recompiled with the patch set recently sent in to mesa. Running Wine 1.7.33 built from this repo. An AMD hd6850.

When starting the game, the menu comes up, and I can pick a character. When loading in world, it loads up to around 95%, then both monitors go dark for a couple seconds, and then turn back on, but with the gpu totally hung. Mouse won't move, etc.

The first few relevant lines of dmesg:
[ 431.118659] radeon 0000:01:00.0: ring 0 stalled for more than 10445msec
[ 431.118664] radeon 0000:01:00.0: GPU lockup (current fence id 0x000000000000da10 last fence id 0x000000000000db02 on ring 0)
[ 431.620258] radeon 0000:01:00.0: ring 0 stalled for more than 10946msec
[ 431.620263] radeon 0000:01:00.0: GPU lockup (current fence id 0x000000000000da10 last fence id 0x000000000000db23 on ring 0)
[ 431.948039] radeon 0000:01:00.0: failed to get a new IB (-35)
[ 431.948043] [drm:radeon_cs_ib_fill] ERROR Failed to get ib !

I am hosting the wine/mesa debug here:
http://incomsystems.biz/rift.log

@Uramekus
Copy link

Im not an adequate one to reply this but can you please debug with iXit repo mesa installed?
And check if you are properly using dri3 or dri2 fallback.

@jp-bennett
Copy link

This is Mesa 10.4 plus the fixes sent in on the 8th.
I am fairly certain that it is dri3.

@axeldavy
Copy link

does it happen with other games (not with nine) ?

I think it is a kernel bug.

@jp-bennett
Copy link

I have not had it happen with any other game with or without nine. Rift runs ok without the nine adapter, as well.

@Uramekus
Copy link

Never happened to me with nouveau (hacked branch) w/ nine or nineless.
I think it really cant be a kernel bug (only if its DRM).
I cant replicate your error. (Considering i have 30+ LoL games with nine upstream and ixit versions)

@Uramekus
Copy link

I think It can be a gpu driver/implementation thing.
Considering that i never had that problm with my 770 or my iGPU

@ghost
Copy link

ghost commented Feb 2, 2015

For me League of Legends works perfectly the only problem is the in-game shop that crash the game
my grafic is a HD7770 (RadeonSI) Ubuntu 14.10
PPAs:
https://launchpad.net/~oibaf/+archive/ubuntu/graphics-drivers
https://launchpad.net/~commendsarnex/+archive/ubuntu/winedri3
https://launchpad.net/~commendsarnex/+archive/ubuntu/mesadri3test
https://launchpad.net/~commendsarnex/+archive/ubuntu/ixitmaster

@axeldavy
Copy link

axeldavy commented Feb 2, 2015

likely the error described in the bug was some bad multisampling support detection. We fixed these, and r600 lockups seems gone. Closing this bug report.

@axeldavy axeldavy closed this as completed Feb 2, 2015
axeldavy pushed a commit that referenced this issue Dec 6, 2016
I was getting a weird segfault from GCC 4.9.3:

 0x00007ffff54f27aa in strlen () from /lib64/libc.so.6
 (gdb) bt
 #0  0x00007ffff54f27aa in strlen () from /lib64/libc.so.6
 #1  0x00007ffff4f128e5 in get_cie_encoding (cie=cie@entry=0x7ffff6e09813)
     at /gcc-4.9.3/libgcc/unwind-dw2-fde.c:272
 #2  0x00007ffff4f1318e in classify_object_over_fdes (ob=ob@entry=0xd7bb90, this_fde=0x7ffff7f11010)
     at /gcc-4.9.3/libgcc/unwind-dw2-fde.c:628
 #3  0x00007ffff4f135ba in init_object (ob=0xd7bb90)
     at /gcc-4.9.3/libgcc/unwind-dw2-fde.c:749
 #4  search_object (ob=ob@entry=0xd7bb90, pc=pc@entry=0x7ffff4f11f4d <_Unwind_RaiseException+61>)
     at /gcc-4.9.3/libgcc/unwind-dw2-fde.c:961
 #5  0x00007ffff4f13e62 in _Unwind_Find_registered_FDE (bases=0x7fffffffd358, pc=0x7ffff4f11f4d <_Unwind_RaiseException+61>)
     at /gcc-4.9.3/libgcc/unwind-dw2-fde.c:1025
 #6  _Unwind_Find_FDE (pc=0x7ffff4f11f4d <_Unwind_RaiseException+61>, bases=bases@entry=0x7fffffffd358)
     at /gcc-4.9.3/libgcc/unwind-dw2-fde-dip.c:450
 #7  0x00007ffff4f11197 in uw_frame_state_for (context=context@entry=0x7fffffffd2b0, fs=fs@entry=0x7fffffffd100)
     at /gcc-4.9.3/libgcc/unwind-dw2.c:1245
 #8  0x00007ffff4f11b15 in uw_init_context_1 (context=context@entry=0x7fffffffd2b0, outer_cfa=outer_cfa@entry=0x7fffffffd660, outer_ra=0x7ffff518d23b <__cxa_throw+91>)
     at /gcc-4.9.3/libgcc/unwind-dw2.c:1566
 #9  0x00007ffff4f11f4e in _Unwind_RaiseException (exc=0xd7c250)
     at /gcc-4.9.3/libgcc/unwind.inc:88
 #10 0x00007ffff518d23b in __cxa_throw () from /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/libstdc++.so.6
 #11 0x00007ffff51ed556 in std::__throw_out_of_range(char const*) ()
    from /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/libstdc++.so.6
 #12 0x00007fffea778be0 in std::map<pipe_format, SWR_FORMAT, std::less<pipe_format>, std::allocator<std::pair<pipe_format const, SWR_FORMAT> > >::at (
     this=0x7fffebeb4c40 <mesa_to_swr_format(pipe_format)::mesa2swr>,
     __k=@0x7fffffffd73c: PIPE_FORMAT_RGTC1_UNORM)
     at /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/include/g++-v4/bits/stl_map.h:549
 #13 0x00007fffea776aee in mesa_to_swr_format (format=PIPE_FORMAT_RGTC1_UNORM) at swr_screen.cpp:597

We can just void this whole issue by not using exceptions in the
first place.

Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Bruce Cherniak <bruce.cherniak@intel.com>
axeldavy pushed a commit that referenced this issue May 21, 2017
So atexit() is horrible and 4aea8fe is probably not a good idea.  But
add an extra layer of duct-tape to the problem.  Otherwise we hit a
situation where app using an atexit() handler that runs later than ours
doesn't hang when trying to tear down a context.

 (gdb) bt
 #0  util_queue_killall_and_wait (queue=queue@entry=0x52bc80) at ../../../src/util/u_queue.c:264
 #1  0x0000007fb6c380c0 in atexit_handler () at ../../../src/util/u_queue.c:51
 #2  0x0000007fb7730e2c in __run_exit_handlers () from /lib64/libc.so.6
 #3  0x0000007fb7730e5c in exit () from /lib64/libc.so.6
 #4  0x0000007fb7ce17dc in piglit_report_result (result=PIGLIT_PASS) at /home/robclark/src/piglit/tests/util/piglit-util.c:267
 #5  0x0000007fb7ef99f8 in process_next_event (x11_fw=0x432c20) at /home/robclark/src/piglit/tests/util/piglit-framework-gl/piglit_x11_framework.c:139
 #6  0x0000007fb7ef9a90 in enter_event_loop (winsys_fw=0x432c20) at /home/robclark/src/piglit/tests/util/piglit-framework-gl/piglit_x11_framework.c:153
 #7  0x0000007fb7ef8e50 in run_test (gl_fw=0x432c20, argc=1, argv=0x7ffffff588) at /home/robclark/src/piglit/tests/util/piglit-framework-gl/piglit_winsys_framework.c:88
 #8  0x0000007fb7edb890 in piglit_gl_test_run (argc=1, argv=0x7ffffff588, config=0x7ffffff400) at /home/robclark/src/piglit/tests/util/piglit-framework-gl.c:203
 #9  0x0000000000401224 in main (argc=1, argv=0x7ffffff588) at /home/robclark/src/piglit/tests/bugs/drawbuffer-modes.c:46
 (gdb) c
 Continuing.
 [Thread 0x7fb67580c0 (LWP 3471) exited]
 ^C
 Thread 1 "drawbuffer-mode" received signal SIGINT, Interrupt.
 0x0000007fb72dda34 in pthread_cond_wait@@GLIBC_2.17 () from /lib64/libpthread.so.0
 (gdb) bt
 #0  0x0000007fb72dda34 in pthread_cond_wait@@GLIBC_2.17 () from /lib64/libpthread.so.0
 #1  0x0000007fb6c38304 in cnd_wait (mtx=0x5bdc90, cond=0x5bdcc0) at ../../../include/c11/threads_posix.h:159
 #2  util_queue_fence_wait (fence=0x5bdc90) at ../../../src/util/u_queue.c:106
 #3  0x0000007fb6daac70 in fd_batch_sync (batch=0x5bdc70) at ../../../../../src/gallium/drivers/freedreno/freedreno_batch.c:233
 #4  batch_reset (batch=batch@entry=0x5bdc70) at ../../../../../src/gallium/drivers/freedreno/freedreno_batch.c:183
 #5  0x0000007fb6daa5e0 in batch_flush (batch=0x5bdc70) at ../../../../../src/gallium/drivers/freedreno/freedreno_batch.c:290
 #6  fd_batch_flush (batch=0x5bdc70, sync=<optimized out>) at ../../../../../src/gallium/drivers/freedreno/freedreno_batch.c:308
 #7  0x0000007fb6daba2c in fd_bc_flush (cache=0x461220, ctx=0x52b920) at ../../../../../src/gallium/drivers/freedreno/freedreno_batch_cache.c:141
 #8  0x0000007fb6dac954 in fd_context_flush (pctx=0x52b920, fence=0x0, flags=<optimized out>) at ../../../../../src/gallium/drivers/freedreno/freedreno_context.c:54
 #9  0x0000007fb6b43294 in st_glFlush (ctx=<optimized out>) at ../../../src/mesa/state_tracker/st_cb_flush.c:121
 #10 0x0000007fb69a84e8 in _mesa_make_current (newCtx=newCtx@entry=0x0, drawBuffer=drawBuffer@entry=0x0, readBuffer=readBuffer@entry=0x0) at ../../../src/mesa/main/context.c:1654
 #11 0x0000007fb6b7ca58 in st_api_make_current (stapi=<optimized out>, stctxi=0x0, stdrawi=0x0, streadi=0x0) at ../../../src/mesa/state_tracker/st_manager.c:827
 #12 0x0000007fb6cc87e8 in dri_unbind_context (cPriv=<optimized out>) at ../../../../../src/gallium/state_trackers/dri/dri_context.c:217
 #13 0x0000007fb6cc80b0 in driUnbindContext (pcp=0x5271e0) at ../../../../../../src/mesa/drivers/dri/common/dri_util.c:591
 #14 0x0000007fb7d1da08 in MakeContextCurrent (dpy=0x433380, draw=0, read=0, gc_user=0x0) at ../../../src/glx/glxcurrent.c:214
 #15 0x0000007fb7a8d5e0 in glx_platform_make_current () from /lib64/libwaffle-1.so.0
 #16 0x0000007fb7a894e4 in waffle_make_current () from /lib64/libwaffle-1.so.0
 #17 0x0000007fb7ef8c60 in piglit_wfl_framework_teardown (wfl_fw=0x432c20) at /home/robclark/src/piglit/tests/util/piglit-framework-gl/piglit_wfl_framework.c:628
 #18 0x0000007fb7ef939c in piglit_winsys_framework_teardown (winsys_fw=0x432c20) at /home/robclark/src/piglit/tests/util/piglit-framework-gl/piglit_winsys_framework.c:238
 #19 0x0000007fb7ef9c30 in destroy (gl_fw=0x432c20) at /home/robclark/src/piglit/tests/util/piglit-framework-gl/piglit_x11_framework.c:212
 #20 0x0000007fb7edb7c4 in destroy () at /home/robclark/src/piglit/tests/util/piglit-framework-gl.c:184
 #21 0x0000007fb7730e2c in __run_exit_handlers () from /lib64/libc.so.6
 #22 0x0000007fb7730e5c in exit () from /lib64/libc.so.6
 #23 0x0000007fb7ce17dc in piglit_report_result (result=PIGLIT_PASS) at /home/robclark/src/piglit/tests/util/piglit-util.c:267
 #24 0x0000007fb7ef99f8 in process_next_event (x11_fw=0x432c20) at /home/robclark/src/piglit/tests/util/piglit-framework-gl/piglit_x11_framework.c:139
 #25 0x0000007fb7ef9a90 in enter_event_loop (winsys_fw=0x432c20) at /home/robclark/src/piglit/tests/util/piglit-framework-gl/piglit_x11_framework.c:153
 #26 0x0000007fb7ef8e50 in run_test (gl_fw=0x432c20, argc=1, argv=0x7ffffff588) at /home/robclark/src/piglit/tests/util/piglit-framework-gl/piglit_winsys_framework.c:88
 #27 0x0000007fb7edb890 in piglit_gl_test_run (argc=1, argv=0x7ffffff588, config=0x7ffffff400) at /home/robclark/src/piglit/tests/util/piglit-framework-gl.c:203
 #28 0x0000000000401224 in main (argc=1, argv=0x7ffffff588) at /home/robclark/src/piglit/tests/bugs/drawbuffer-modes.c:46
 (gdb) r

Fixes: 4aea8fe ("gallium/u_queue: fix random crashes when the app calls exit()")
Signed-off-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
axeldavy pushed a commit that referenced this issue Jan 5, 2019
First step to unify the way fd5 and fd6 blitter works.  Currently a6xx
bypasses the blit API in order to also accelerate resource_copy_region()

But this approach can lead to infinite recursion:

  #0  fd_alloc_staging (ctx=0x5555936480, rsc=0x7fac485f90, level=0, box=0x7fbab29220) at ../src/gallium/drivers/freedreno/freedreno_resource.c:291
  #1  0x0000007fbdebed04 in fd_resource_transfer_map (pctx=0x5555936480, prsc=0x7fac485f90, level=0, usage=258, box=0x7fbab29220, pptrans=0x7fbab29240) at ../src/gallium/drivers/freedreno/freedreno_resource.c:479
  #2  0x0000007fbe5c5068 in u_transfer_helper_transfer_map (pctx=0x5555936480, prsc=0x7fac485f90, level=0, usage=258, box=0x7fbab29220, pptrans=0x7fbab29240) at ../src/gallium/auxiliary/util/u_transfer_helper.c:243
  #3  0x0000007fbde2dcb8 in util_resource_copy_region (pipe=0x5555936480, dst=0x7fac485f90, dst_level=0, dst_x=0, dst_y=0, dst_z=0, src=0x7fac47c780, src_level=0, src_box_in=0x7fbab2945c) at ../src/gallium/auxiliary/util/u_surface.c:350
  #4  0x0000007fbdf2282c in fd_resource_copy_region (pctx=0x5555936480, dst=0x7fac485f90, dst_level=0, dstx=0, dsty=0, dstz=0, src=0x7fac47c780, src_level=0, src_box=0x7fbab2945c) at ../src/gallium/drivers/freedreno/freedreno_blitter.c:173
  #5  0x0000007fbdf085d4 in fd6_resource_copy_region (pctx=0x5555936480, dst=0x7fac485f90, dst_level=0, dstx=0, dsty=0, dstz=0, src=0x7fac47c780, src_level=0, src_box=0x7fbab2945c) at ../src/gallium/drivers/freedreno/a6xx/fd6_blitter.c:587
  #6  0x0000007fbde2f3d0 in util_try_blit_via_copy_region (ctx=0x5555936480, blit=0x7fbab29430) at ../src/gallium/auxiliary/util/u_surface.c:864
  #7  0x0000007fbdec02c4 in fd_blit (pctx=0x5555936480, blit_info=0x7fbab29588) at ../src/gallium/drivers/freedreno/freedreno_resource.c:993
  #8  0x0000007fbdf08408 in fd6_blit (pctx=0x5555936480, info=0x7fbab29588) at ../src/gallium/drivers/freedreno/a6xx/fd6_blitter.c:546
  #9  0x0000007fbdebdc74 in do_blit (ctx=0x5555936480, blit=0x7fbab29588, fallback=false) at ../src/gallium/drivers/freedreno/freedreno_resource.c:129
  #10 0x0000007fbdebe58c in fd_blit_from_staging (ctx=0x5555936480, trans=0x7fac47b7e8) at ../src/gallium/drivers/freedreno/freedreno_resource.c:326
  #11 0x0000007fbdebea38 in fd_resource_transfer_unmap (pctx=0x5555936480, ptrans=0x7fac47b7e8) at ../src/gallium/drivers/freedreno/freedreno_resource.c:416
  #12 0x0000007fbe5c5c68 in u_transfer_helper_transfer_unmap (pctx=0x5555936480, ptrans=0x7fac47b7e8) at ../src/gallium/auxiliary/util/u_transfer_helper.c:516
  #13 0x0000007fbde2de24 in util_resource_copy_region (pipe=0x5555936480, dst=0x7fac485f90, dst_level=0, dst_x=0, dst_y=0, dst_z=0, src=0x7fac47b8e0, src_level=0, src_box_in=0x7fbab2997c) at ../src/gallium/auxiliary/util/u_surface.c:376
  #14 0x0000007fbdf2282c in fd_resource_copy_region (pctx=0x5555936480, dst=0x7fac485f90, dst_level=0, dstx=0, dsty=0, dstz=0, src=0x7fac47b8e0, src_level=0, src_box=0x7fbab2997c) at ../src/gallium/drivers/freedreno/freedreno_blitter.c:173
  #15 0x0000007fbdf085d4 in fd6_resource_copy_region (pctx=0x5555936480, dst=0x7fac485f90, dst_level=0, dstx=0, dsty=0, dstz=0, src=0x7fac47b8e0, src_level=0, src_box=0x7fbab2997c) at ../src/gallium/drivers/freedreno/a6xx/fd6_blitter.c:587
  ...

Instead rework the API to push the fallback back to core code, so that
we can rework resource_copy_region() to have it's own fallback path,
and then finally convert fd6 over to work in the same way.

This also makes ctx->blit() optional, and cleans up some unnecessary
callers.

Signed-off-by: Rob Clark <robdclark@gmail.com>
axeldavy pushed a commit that referenced this issue Feb 2, 2019
Fixes an assert we start hitting with kms/gbm:

  #0  0x0000007fbf3d6e3c in raise () from /lib64/libc.so.6
  #1  0x0000007fbf3c4a68 in abort () from /lib64/libc.so.6
  #2  0x0000007fbf3d04e8 in __assert_fail_base () from /lib64/libc.so.6
  #3  0x0000007fbf3d0550 in __assert_fail () from /lib64/libc.so.6
  #4  0x0000007fbf5a73c4 in gbm_dri_bo_create (gbm=0x5820f0, width=2160, height=1440, format=875713112, usage=0, modifiers=0x695e00, count=1) at ../src/gbm/backends/dri/gbm_dri.c:1150
  #5  0x0000007fbf5a49c4 in gbm_bo_create_with_modifiers (gbm=0x5820f0, width=2160, height=1440, format=875713112, modifiers=0x695e00, count=1) at ../src/gbm/main/gbm.c:491
  #6  0x0000007fbbac3d64 in get_back_bo (dri2_surf=0x6f4cc0) at ../src/egl/drivers/dri2/platform_drm.c:258
  #7  0x0000007fbbac4318 in dri2_drm_image_get_buffers (driDrawable=0x704490, format=4098, stamp=0x6fc730, loaderPrivate=0x6f4cc0, buffer_mask=1, buffers=0x7fffffe210) at ../src/egl/drivers/dri2/platform_drm.c:409
  #8  0x0000007fbf5a5318 in image_get_buffers (driDrawable=0x704490, format=4098, stamp=0x6fc730, loaderPrivate=0x70e150, buffer_mask=1, buffers=0x7fffffe210) at ../src/gbm/backends/dri/gbm_dri.c:135
  #9  0x0000007fbe4308c4 in dri_image_drawable_get_buffers (drawable=0x6fc730, images=0x7fffffe210, statts=0x6f2660, statts_count=1) at ../src/gallium/state_trackers/dri/dri2.c:339
  #10 0x0000007fbe430c44 in dri2_allocate_textures (ctx=0x614b30, drawable=0x6fc730, statts=0x6f2660, statts_count=1) at ../src/gallium/state_trackers/dri/dri2.c:466
  #11 0x0000007fbe435580 in dri_st_framebuffer_validate (stctx=0x714160, stfbi=0x6fc730, statts=0x6f2660, count=1, out=0x7fffffe3b8) at ../src/gallium/state_trackers/dri/dri_drawable.c:85
  #12 0x0000007fbe7b2c84 in st_framebuffer_validate (stfb=0x6f2190, st=0x714160) at ../src/mesa/state_tracker/st_manager.c:222
  #13 0x0000007fbe7b4884 in st_api_make_current (stapi=0x7fbf0430d8 <st_gl_api>, stctxi=0x714160, stdrawi=0x6fc730, streadi=0x6fc730) at ../src/mesa/state_tracker/st_manager.c:1074
  #14 0x0000007fbe434f44 in dri_make_current (cPriv=0x703c20, driDrawPriv=0x704490, driReadPriv=0x704490) at ../src/gallium/state_trackers/dri/dri_context.c:301
  #15 0x0000007fbe42c910 in driBindContext (pcp=0x703c20, pdp=0x704490, prp=0x704490) at ../src/mesa/drivers/dri/common/dri_util.c:579
  #16 0x0000007fbbabab40 in dri2_make_current (drv=0x69d170, disp=0x69c6e0, dsurf=0x6f4cc0, rsurf=0x6f4cc0, ctx=0x70cb40) at ../src/egl/drivers/dri2/egl_dri2.c:1456
  #17 0x0000007fbbaa8ef4 in eglMakeCurrent (dpy=0x69c6e0, draw=0x6f4cc0, read=0x6f4cc0, ctx=0x70cb40) at ../src/egl/main/eglapi.c:862
  #18 0x0000007fbf5736ac in InternalMakeCurrentVendor (dpy=dpy@entry=0x614fb0, draw=draw@entry=0x6f4cc0, read=read@entry=0x6f4cc0, context=context@entry=0x70cb40, apiState=apiState@entry=0x6fc940, vendor=0x6975f0) at libegl.c:861
  #19 0x0000007fbf573764 in InternalMakeCurrentDispatch (dpy=0x614fb0, draw=0x6f4cc0, read=0x6f4cc0, context=0x70cb40, vendor=0x6975f0) at libegl.c:630
  #20 0x0000000000403640 in init_egl (egl=0x5805a8 <gl>, gbm=0x580528 <gbm>, samples=0) at ../common.c:263
  #21 0x0000000000403c1c in init_cube_smooth (gbm=0x580528 <gbm>, samples=0) at ../cube-smooth.c:225
  #22 0x0000000000408618 in main (argc=1, argv=0x7fffffe8d8) at ../kmscube.c:145

Fixes: 1ce5d75 freedreno: core buffer modifier support
Signed-off-by: Rob Clark <robdclark@gmail.com>
axeldavy pushed a commit that referenced this issue Dec 20, 2020
If you dlclose your driver, the leak reports look like:

    #0 0xffff9c7e5e7c in malloc (/lib/aarch64-linux-gnu/libasan.so.6+0x9ee7c)
    #1 0xffff94aaaa48  (<unknown module>)
    #2 0xffff94aa5ff4  (<unknown module>)
    #3 0xffff94d1867c  (<unknown module>)
    #4 0xffff94d184f0  (<unknown module>)
    #5 0xffff94c9a990  (<unknown module>)
    #6 0xffff94c92e30  (<unknown module>)
    #7 0xffff94c91d48  (<unknown module>)
    #8 0xffff946eb800  (/home/anholt/src/mesa/build-aarch64-asan/src/egl/libEGL.so.1.0.0+0xfe800)
    #9 0xffff94c72874  (<unknown module>)
    #10 0xffff946ede68  (/home/anholt/src/mesa/build-aarch64-asan/src/egl/libEGL.so.1.0.0+0x100e68)
    #11 0xffff94bf7134  (<unknown module>)
    #12 0xffff9c686450 in dri2_create_screen ../src/egl/drivers/dri2/egl_dri2.c:1079

which is not terribly useful.  Probe if we're building with asan and just
skip closing the driver in the happy path (which seems to be the standard
practice for loadable modules with this tool).

Acked-by: Michel Dänzer <mdaenzer@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7695>
axeldavy pushed a commit that referenced this issue Dec 20, 2020
This prevents funky segfaults in seemingly unrelated codepaths like:

    pid: 20058, tid: 20086, name: Binder:20058_2  >>> /system/bin/surfaceflinger <<<
    uid: 1000
    signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x184
    Cause: null pointer dereference
    [...]
    #00 pc 000000000020b078  /vendor/lib64/dri/gallium_dri.so (ir3_shader_variant+56)
    #1 pc 00000000001dc168  /vendor/lib64/dri/gallium_dri.so (fd5_draw_vbo+920)
    #2 pc 00000000001a30f8  /vendor/lib64/dri/gallium_dri.so (fd_draw_vbo+1264)
    #3 pc 000000000077e714  /vendor/lib64/dri/gallium_dri.so (util_primconvert_draw_vbo+596)
    #4 pc 00000000001a2d60  /vendor/lib64/dri/gallium_dri.so (fd_draw_vbo+344)
    #5 pc 00000000007671e4  /vendor/lib64/dri/gallium_dri.so (dd_context_draw_vbo+300)
    #6 pc 00000000007b6c9c  /vendor/lib64/dri/gallium_dri.so (u_vbuf_draw_vbo+2268)
    #7 pc 000000000074d230  /vendor/lib64/dri/gallium_dri.so (cso_draw_arrays+96)
    #8 pc 00000000007a4258  /vendor/lib64/dri/gallium_dri.so (util_draw_user_vertex_buffer+96)
    #9 pc 00000000007b0968  /vendor/lib64/dri/gallium_dri.so (util_run_tests+480)
    #10 pc 000000000019e24c  /vendor/lib64/dri/gallium_dri.so (pipe_msm_create_screen+68)
    #11 pc 00000000006ada8c  /vendor/lib64/dri/gallium_dri.so (pipe_loader_create_screen+60)
    #12 pc 000000000020e958  /vendor/lib64/dri/gallium_dri.so (dri2_init_screen+120)
    #13 pc 00000000006ad088  /vendor/lib64/dri/gallium_dri.so (driCreateNewScreen2+544)

Fixes: eeecc21 ("util: Add property_get() fallback for android")
Reviewed-by: Rob Clark <robclark@freedesktop.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7928>
axeldavy pushed a commit that referenced this issue Mar 2, 2021
asan on llvmpipe with piglit tests/spec/arb_gl_spirv/execution/ssbo/array-indirect.shader_test
reported.

=================================================================
==3288325==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 48 byte(s) in 1 object(s) allocated from:
    #0 0x7f5b2d6513cf in __interceptor_malloc (/lib64/libasan.so.6+0xab3cf)
    #1 0x7f5b2a1ae810 in ralloc_size ../src/util/ralloc.c:133
    #2 0x7f5b2a1ae7e1 in ralloc_context ../src/util/ralloc.c:120
    #3 0x7f5b2b210177 in gl_nir_link_uniform_blocks ../src/compiler/glsl/gl_nir_link_uniform_blocks.c:585
    #4 0x7f5b2af7f52d in gl_nir_link_spirv ../src/compiler/glsl/gl_nir_linker.c:614
    #5 0x7f5b2a3b76fa in st_link_nir ../src/mesa/state_tracker/st_glsl_to_nir.cpp:765
    #6 0x7f5b2a3ace7b in st_link_shader ../src/mesa/state_tracker/st_glsl_to_ir.cpp:65
    #7 0x7f5b2a471165 in _mesa_glsl_link_shader ../src/mesa/program/ir_to_mesa.cpp:3122
    #8 0x7f5b2a97a6d8 in link_program ../src/mesa/main/shaderapi.c:1311
    #9 0x7f5b2a97a6d8 in link_program_error ../src/mesa/main/shaderapi.c:1419
    #10 0x7f5b2a97df45 in _mesa_LinkProgram ../src/mesa/main/shaderapi.c:1911
    #11 0x7f5b299b59e5 in stub_glLinkProgram /mnt/devel/gl/piglit/tests/util/piglit-dispatch-gen.c:33956
    #12 0x40a71a in link_and_use_shaders /mnt/devel/gl/piglit/tests/shaders/shader_runner.c:1604
    #13 0x415722 in init_test /mnt/devel/gl/piglit/tests/shaders/shader_runner.c:5225
    #14 0x4164ce in piglit_init /mnt/devel/gl/piglit/tests/shaders/shader_runner.c:5597
    #15 0x7f5b29a214e9 in run_test /mnt/devel/gl/piglit/tests/util/piglit-framework-gl/piglit_winsys_framework.c:73
    #16 0x7f5b29a103fe in piglit_gl_test_run /mnt/devel/gl/piglit/tests/util/piglit-framework-gl.c:229
    #17 0x407847 in main /mnt/devel/gl/piglit/tests/shaders/shader_runner.c:72
    #18 0x7f5b2928f1e1 in __libc_start_main (/lib64/libc.so.6+0x281e1)

SUMMARY: AddressSanitizer: 48 byte(s) leaked in 1 allocation(s).

Fixes: 5723919 ("nir/linker: add gl_nir_link_uniform_blocks.c")
Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8974>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants