Robin Redeker wrote: > > Hi, > > i am just writing on a Gtk-application which uses > the GtkGLWidget for displaying OpenGL stuff. > When using the DRI-OpenGL-library which is delivered with > Xfree 4.1.0 and too tested with xfree 4.2.0, the programm crashes. > With a memory-debugger its saying "memory clobbered past end of allocated block" > used -lmcheck (MALLOC_CHECK_=2). > > Here is a sample backtrace of what happens when closing the GtkGL-window: > ------------------------------ > #0 0x403fca21 in __kill () from /lib/libc.so.6 > #1 0x403fc6c8 in raise (sig=6) at ../sysdeps/posix/raise.c:27 > #2 0x403fdfcb in abort () at ../sysdeps/generic/abort.c:88 > #3 0x4043d653 in Letext () at ../sysdeps/posix/libc_fatal.c:57 > #4 0x40446d44 in mabort () at mcheck.c:309 > #5 0x404468bb in checkhdr (hdr=0x82e1130) at mcheck.c:110 > #6 0x40446a1d in freehook (ptr=0x82e1140, caller=0x40757de3) at mcheck.c:188 > #7 0x4044407a in __libc_free (mem=0x82e1140) at malloc.c:3116 > #8 0x40757de3 in radeonDestroyTexObj (rmesa=0x81a32b8, t=0x82de050) > at radeon_texmem.c:65 > #9 0x4073f37a in radeonDestroyContext (rmesa=0x81a32b8) > at radeon_context.c:224 > #10 0x407638ab in XMesaDestroyContext (driContextPriv=0x817deb0) > at radeon_xmesa.c:149 > #11 0x405ae86c in driMesaDestroyContext (dpy=0x806c4b0, scrn=0, > contextPrivate=0x817deb0) at dri_mesa.c:761 > #12 0x400ba2c6 in DestroyContext (dpy=0x806c4b0, gc=0x817d978) at glxcmds.c:236 > #13 0x400ba3a2 in glXDestroyContext (dpy=0x806c4b0, gc=0x817d978) > at glxcmds.c:268 > ... > ------------------------------ > > Another crash i noticed was without mem-check stuff in the gluBuild2DMipmaps() > function: > ------------------------------ > #0 chunk_alloc (ar_ptr=0x404ef5a0, nb=80) at malloc.c:2926 > #1 0x40444f8d in __libc_calloc (n=1, elem_size=72) at malloc.c:3827 > #2 0x406bd08a in _mesa_alloc_texture_image () at teximage.c:346 > #3 0x406bf7c8 in _mesa_TexImage2D (target=3553, level=5, internalFormat=3, > width=1, height=2, border=0, format=6407, type=5121, pixels=0x830dd88) > at teximage.c:1497 > #4 0x400f43fd in gluBuild2DMipmapLevelsCore (target=3553, internalFormat=3, > width=16, height=64, widthPowerOf2=16, heightPowerOf2=64, format=6407, > type=5121, userLevel=0, baseLevel=0, maxLevel=6, data=0x8311760) > at mipmap.c:4487 > #5 0x400f4625 in gluBuild2DMipmaps (target=3553, internalFormat=3, width=16, > height=64, format=6407, type=5121, data=0x8311760) at mipmap.c:4562 > #6 0x080540e3 in S_T_AddData24 (tex=0x814bad8, width=16, height=64, > data_x=16, data_y=64, > data=0x8311760 "< \021< \021< \021< \021< \021< \021Q3<< \021< \021< \021< > \021</\034</\034</\034</\034</\034< \021< \021V") at fe/gl/texture.c:369 > ------------------------------ > > I first tryed to find the mem-bug in the program it self, but didn't found > any piece of code, which can corrupt mem so much. > The program works well when useing the env var LIBGL_ALWAYS_INDIRECT=1. > (Except its running horrible slow (what isnt a bug in it self) ;) > And i too heard, that its working withoug bugs with nVidias GL-lib. > So i dont think that its a mem-corruption bug of X/Gtk/GtkGlArea/My Program. > > I am using the ATI Radeon 7200 on a AMD Athlon 1400 Mhz with 256 MB Ram, > linux kernel 2.4.16, Xfree 4.1.0 and 4.2.0 tested. > localhost kernel: [drm] AGP 0.99 on VIA Apollo KT133 @ 0xe6000000 32MB > localhost kernel: [drm] Initialized radeon 1.1.1 20010405 on minor 0 > > I enabled the debugging symbols in the GL-DRI-lib later for see more a > about whats going on. > > The DRI works well with other Application like Quakeforge, Quake2 (compiled > from sources) and Quake3. > > If you have a Radeon too or want to see if its crashing to, get > the program at http://sourceforge.net/projects/quest-ed/ from CVS, > get the quest-3b. > (cvs -d:pserver:[EMAIL PROTECTED]:/cvsroot/quest-ed login > cvs -z3 -d:pserver:[EMAIL PROTECTED]:/cvsroot/quest-ed co >quest-3b) > Its a quake1-level-editor, you will need quake-textures-wad to test it. > (You can use the cwad2 tool from http://quest-ed.sourceforge.net/dl/index.html) > You will have to load the wad-file and open the texture-browser > and doing some stuff with the texture-browser, > like scrolling or closing or canceling or selectin a texture, > then it maybe crashes. > I dont suppose anyone to do this, but if anyone wants to ;) > > I am sorry if any informations lacks, simply ask. > > My knowledge isnt very good about drivers and opengl, but if i can > help somehow...
Could you link your app with "electric fence" (-lefence) and see if it detects the out-of-bounds write? -Brian _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
