Bug 18212 - Crash inside r300MapTexture()
Summary: Crash inside r300MapTexture()
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/r300 (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-10-24 12:49 UTC by Owen Taylor
Modified: 2009-11-23 11:25 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments

Description Owen Taylor 2008-10-24 12:49:39 UTC
mesa-libGL-7.2-0.13.fc10.i386

Hit the following crash

(gdb) bt
#0  teximage_set_map_data () at r300_tex.c:439
#1  r300MapTexture (ctx=0x81324b0, texObj=0x851f000) at r300_tex.c:482
#2  0x006543f9 in radeonSpanRenderStart (ctx=0x81324b0) at radeon_span.c:308
#3  0x00f0175c in _swrast_ReadPixels (ctx=0x81324b0, x=487, y=925, width=1, height=1, format=6408, type=5121, packing=0x813e130, pixels=0xbfffe698)
    at swrast/s_readpix.c:562
#4  0x00e84585 in _mesa_ReadPixels (x=487, y=925, width=1, height=1, format=6408, type=5121, pixels=0xbfffe698) at main/readpix.c:188
#5  0x0014ecba in _clutter_do_pick (stage=0x812e018, x=487, y=925, mode=CLUTTER_PICK_REACTIVE) at clutter-main.c:388

Where line 439 is:

439		image->base.Data = image->mt->bo->virtual + lvl->faces[image->mtface].offset;

If we look at image:

$56 = {base = {_BaseFormat = 6406, InternalFormat = 6406, Border = 0, Width = 128, Height = 128, Depth = 1, Width2 = 128, Height2 = 128, Depth2 = 1, 
    WidthLog2 = 7, HeightLog2 = 7, DepthLog2 = 0, MaxLog2 = 7, WidthScale = 128, HeightScale = 128, DepthScale = 1, IsClientData = 0 '\0', 
    _IsPowerOfTwo = 1 '\001', TexFormat = 0xfd9db0, TexObject = 0x851f000, FetchTexelc = 0xe90565 <fetch_texel_2d_a8>, 
    FetchTexelf = 0xe9ef46 <fetch_texel_chan_to_float>, IsCompressed = 0 '\0', CompressedSize = 0, RowStride = 128, ImageOffsets = 0x8546418, 
    Data = 0x85f7c00, DriverData = 0x0}, mt = 0x0, mtlevel = 1, mtface = 0}

We see that image->mt is 0, though there is data for the image. This is the level 1 image. The level 0 image has image->mt != 0. The parent texture object is:

$58 = {base = {Mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __kind = 0, __nusers = 0, {__spins = 0, __list = {__next = 0x0}}}, 
      __size = '\0' <repeats 23 times>, __align = 0}, RefCount = 2, Name = 2, Target = 3553, Priority = 1, BorderColor = {0, 0, 0, 0}, 
    _BorderChan = "\000\000\000", WrapS = 33071, WrapT = 33071, WrapR = 10497, MinFilter = 9987, MagFilter = 9729, MinLod = -1000, MaxLod = 1000, 
    LodBias = 0, BaseLevel = 0, MaxLevel = 1000, MaxAnisotropy = 1, CompareFlag = 0 '\0', CompareOperator = 33180, ShadowAmbient = 0, CompareMode = 0, 
    CompareFunc = 515, _Function = 0, DepthMode = 6409, _MaxLevel = 8, _MaxLambda = 8, CropRect = {0, 0, 0, 0}, GenerateMipmap = 1 '\001', 
    _Complete = 1 '\001', Image = {{0x851f210, 0x851ff90, 0x8540908, 0x8544a08, 0x8544a98, 0x8544b28, 0x8520308, 0x8520398, 0x8546448, 0x0, 0x0, 0x0}, {
        0x0 <repeats 12 times>}, {0x0 <repeats 12 times>}, {0x0 <repeats 12 times>}, {0x0 <repeats 12 times>}, {0x0 <repeats 12 times>}}, Palette = {
      InternalFormat = 0, _BaseFormat = 0, Size = 0, TableF = 0x0, TableUB = 0x0, RedSize = 0 '\0', GreenSize = 0 '\0', BlueSize = 0 '\0', 
      AlphaSize = 0 '\0', LuminanceSize = 0 '\0', IntensitySize = 0 '\0'}, DriverData = 0x0}, mt = 0x852f810, validated = 1 '\001', 
  image_override = 0 '\0', override_offset = 0, filter = 21522, filter_1 = 0, pitch_reg = 0, size = 537393407, format = 1196032, pp_border_color = 0, 
  tile_bits = 0}

I suspect that GenerateMipmap=1 is relevant here. Image data for levels other than 1 have apparently been generated, but never stored into the mipmap tree.

I'm not sure if the fix is to simply check image->mt as in r300_teximage_map(), or whether we need to actually force the other levels into the mipmap tree at this point before doing the software rendering/ReadPixels.
Comment 1 Maciej Cencora 2009-10-10 03:13:53 UTC
Can you reproduce it with newest mesa?
Comment 2 Maciej Cencora 2009-11-18 13:30:09 UTC
Should be fixed on mesa_7_7_branch now, can you check?
Comment 3 Owen Taylor 2009-11-23 11:25:35 UTC
This was a one-off crash I happened to get a good backtrace for, not something I was hitting reliably.

If you say it's fixed, it's probably fixed.


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.