Bug 25463 - crash with progs/perf/copytex
Summary: crash with progs/perf/copytex
Status: RESOLVED WORKSFORME
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/R600 (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-12-05 09:16 UTC by Pierre Ossman
Modified: 2012-09-11 08:48 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments

Description Pierre Ossman 2009-12-05 09:16:58 UTC
Running the glCopyTexImage test program results in a segfault in the r600 driver. I've had a look at it but I can't figure out how this is supposed to work in the first place.

Backtrace:

#0  0x00000032bbe326b5 in raise (sig=<value optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0x00000032bbe33e95 in abort () at abort.c:92
#2  0x00000032bbe2b7a5 in __assert_fail (assertion=0x7ffff7184df5 "src", file=<value optimized out>, line=54, function=<value optimized out>) at assert.c:81
#3  0x00007ffff6f24acb in copy_rows (dst=0x7ffff661d000, dststride=256, src=0x0, srcstride=64, numrows=16, rowsize=64) at radeon_texture.c:54
#4  0x00007ffff6f0fe16 in migrate_image_to_miptree (mt=0xa0bb70, image=0xa00670, face=0, level=0) at radeon_mipmap_tree.c:466
#5  0x00007ffff6f10493 in radeon_validate_texture_miptree (ctx=0x6783c0, texObj=0x9e16e0) at radeon_mipmap_tree.c:602
#6  0x00007ffff6f24f53 in radeonMapTexture (ctx=0x6783c0, texObj=0x9e16e0) at radeon_texture.c:167
#7  0x00007ffff6f2462f in radeonSpanRenderStart (ctx=0x6783c0) at radeon_span.c:888
#8  0x00007ffff705b431 in swrast_render_start (ctx=0x6783c0) at swrast/s_context.h:267
#9  0x00007ffff705cc31 in _swrast_ReadPixels (ctx=0x6783c0, x=0, y=0, width=16, height=16, format=6408, type=5121, packing=0x685da8, pixels=0xa00710) at swrast/s_readpix.c:579
#10 0x00007ffff70a2777 in copy_tex_image (ctx=0x6783c0, dims=2, target=3553, level=0, internalFormat=6408, x=0, y=0, width=16, height=16, border=0) at drivers/common/meta.c:2506
#11 0x00007ffff70a29f1 in _mesa_meta_CopyTexImage2D (ctx=0x6783c0, target=3553, level=0, internalFormat=6408, x=0, y=0, width=16, height=16, border=0) at drivers/common/meta.c:2568
#12 0x00007ffff6fc27f5 in _mesa_CopyTexImage2D (target=3553, level=0, internalFormat=6408, x=0, y=0, width=16, height=16, border=0) at main/teximage.c:2785
#13 0x0000000000428c41 in CopyTexImage ()
#14 0x0000000000428f67 in PerfMeasureRate ()
#15 0x0000000000428a6e in PerfDraw ()
#16 0x00000000004291c9 in Draw ()
#17 0x00007ffff7dcb1a7 in processWindowWorkList (window=0x65f280) at glut_event.c:1306
#18 0x00007ffff7dcb2c1 in __glutProcessWindowWorkLists () at glut_event.c:1356
#19 0x00007ffff7dcb337 in glutMainLoop () at glut_event.c:1377
#20 0x00000000004291a2 in main ()

(I added an extra assert in copy_rows which is why the top part is in the assertion code and not a segfault in memcpy)

The issue is that the radeon code tries to map the target texture and migrate it to a mipmap tree, but that texture hasn't yet gotten any memory as it is in the process of being created.
Comment 1 Pierre Ossman 2009-12-05 12:32:24 UTC
Looking through things, there are two questions that pop up:

1. Should the texture really be marked as complete when there is no data associated with it? Unfortunately mesa core cannot determine this by itself as the data might have been moved to some device specific area.

2. Is it necessary to map textures in radeonSpanRenderStart() to begin with?
Comment 2 Maciej Cencora 2009-12-11 17:23:59 UTC
Workaround pushed to mesa_7_7_branch (commit id 	8413a3aefaf4968f8b17263826b34baa99c2a907).
Comment 3 Andreas Boll 2012-09-11 08:48:52 UTC
Note: classic r600 driver has been abandoned.

works correctly with r600g (gallium driver) on my rv770
tested with mesa git master e81ee67b51651e99e7e8e52c1ccafc66835d57cd
and mesa 8.0.4


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.