Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://bugs.freedesktop.org/show_bug.cgi?id=8218
------- Additional Comments From [EMAIL PROTECTED] 2006-09-19 17:15 -------
(In reply to comment #5)
> Created an attachment (id=7086)
--> (https://bugs.freedesktop.org/attachment.cgi?id=7086&action=view) [edit]
> valgrind 3.1.0 output from arbvpwarpmesh
>
> Uninitialised values and invalid writes(?).
I'm not an expert for valgrind. Just some quick thoughts:
==17068== Conditional jump or move depends on uninitialised value(s)
==17068== at 0x4147992: r200Clear (r200_ioctl.c:698)
==17068== Conditional jump or move depends on uninitialised value(s)
==17068== at 0x4146ECA: r200WaitForFrameCompletion (r200_ioctl.c:391)
These two don't look unitialized to me - I think valgrind can't know that these
values (in the sarea) are indeed written by drm, and thus assumes they aren't
initialized.
Lots of those:
==17068== Invalid write of size 4
==17068== at 0x4167F6C: emit_vector (r200_maos_arrays.c:287)
Not sure. I guess it's the float/int casts causing trouble here?
Those in the swtcl path look fairly similar.
==17068== Invalid write of size 4
==17068== at 0x415F72A: r200_render_quad_strip_verts (t_dd_triemit.h:80)
IIRC gcc will actually report warnings when compiled with strict aliasing at
around these places.
These two are intersting:
==17068== Syscall param write(buf) points to uninitialised byte(s)
==17068== at 0x41485F13: __write_nocancel (in /lib/libc-2.4.so)
==17068== by 0x4157567E: _X11TransWrite (in /usr/lib/libX11.so.6.2.0)
==17068== Syscall param ioctl(generic) points to uninitialised byte(s)
==17068== at 0x4148D3B9: ioctl (in /lib/libc-2.4.so)
==17068== by 0x4141279: do_wait (vblank.c:243)
==17068== by 0x4141350: driWaitForVBlank (vblank.c:311)
==17068== by 0x4148618: r200CopyBuffer (r200_ioctl.c:453)
==17068== by 0x4145775: r200SwapBuffers (r200_context.c:653)
==17068== by 0x414148E: driSwapBuffers (dri_util.c:472)
==17068== by 0x4277AEDD: glXSwapBuffers (in /usr/lib/libGL.so.1.2)
==17068== by 0x410F453D: glutSwapBuffers (in /usr/lib/libglut.so.3.8.0)
==17068== by 0x80494F4: Display (arbvpwarpmesh.c:88)
==17068== by 0x410FCB85: (within /usr/lib/libglut.so.3.8.0)
==17068== by 0x41100161: fgEnumWindows (in /usr/lib/libglut.so.3.8.0)
==17068== by 0x410FD43A: glutMainLoopEvent (in /usr/lib/libglut.so.3.8.0)
==17068== Address 0xBEB412E4 is on thread 1's stack
==17068== Warning: noted but unhandled ioctl 0x6447 with no size/direction hints
==17068== This could cause spurious value errors to appear.
==17068== See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a
proper wrapper.
==17068== Warning: noted but unhandled ioctl 0x6447 with no size/direction hints
==17068== This could cause spurious value errors to appear.
==17068== See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a
proper wrapper.
==17068== Warning: noted but unhandled ioctl 0x6447 with no size/direction hints
==17068== This could cause spurious value errors to appear.
==17068== See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a
proper wrapper.
I've no idea what the problem here really is (yeah yeah I know I should read se
values (in the sarea) are indeed written by drm, and thus assumes they aren't
initialized.
Lots of those:
==17068== Invalid write of size 4
==17068== at 0x4167F6C: emit_vector (r200_maos_arrays.c:287)
Not sure. I guess it's the float/int casts causing trouble here?
Those in the swtcl path look fairly similar.
==17068== Invalid write of size 4
==17068== at 0x415F72A: r200_render_quad_strip_verts (t_dd_triemit.h:80)
IIRC gcc will actually report warnings when compiled with strict aliasing at
around these places.
These two are intersting:
==17068== Syscall param write(buf) points to uninitialised byte(s)
==17068== at 0x41485F13: __write_nocancel (in /lib/libc-2.4.so)
==17068== by 0x4157567E: _X11TransWrite (in /usr/lib/libX11.so.6.2.0)
==17068== Syscall param ioctl(generic) points to uninitialised byte(s)
==17068== at 0x4148D3B9: ioctl (in /lib/libc-2.4.so)
==17068== by 0x4141279: do_wait (vblank.c:243)
==17068== by 0x4141350: driWaitForVBlank (vblank.c:311)
==17068== by 0x4148618: r200CopyBuffer (r200_ioctl.c:453)
==17068== by 0x4145775: r200SwapBuffers (r200_context.c:653)
==17068== by 0x414148E: driSwapBuffers (dri_util.c:472)
==17068== by 0x4277AEDD: glXSwapBuffers (in /usr/lib/libGL.so.1.2)
==17068== by 0x410F453D: glutSwapBuffers (in /usr/lib/libglut.so.3.8.0)
==17068== by 0x80494F4: Display (arbvpwarpmesh.c:88)
==17068== by 0x410FCB85: (within /usr/lib/libglut.so.3.8.0)
==17068== by 0x41100161: fgEnumWindows (in /usr/lib/libglut.so.3.8.0)
==17068== by 0x410FD43A: glutMainLoopEvent (in /usr/lib/libglut.so.3.8.0)
==17068== Address 0xBEB412E4 is on thread 1's stack
==17068== Warning: noted but unhandled ioctl 0x6447 with no size/direction hints
==17068== This could cause spurious value errors to appear.
==17068== See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a
proper wrapper.
==17068== Warning: noted but unhandled ioctl 0x6447 with no size/direction hints
==17068== This could cause spurious value errors to appear.
==17068== See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a
proper wrapper.
==17068== Warning: noted but unhandled ioctl 0x6447 with no size/direction hints
==17068== This could cause spurious value errors to appear.
==17068== See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a
proper wrapper.
I've no idea what the problem here really is (yeah yeah I know I should read se
values (in the sarea) are indeed written by drm, and thus assumes they aren't
initialized.
Lots of those:
==17068== Invalid write of size 4
==17068== at 0x4167F6C: emit_vector (r200_maos_arrays.c:287)
Not sure. I guess it's the float/int casts causing trouble here?
Those in the swtcl path look fairly similar.
==17068== Invalid write of size 4
==17068== at 0x415F72A: r200_render_quad_strip_verts (t_dd_triemit.h:80)
IIRC gcc will actually report warnings when compiled with strict aliasing at
around these places.
These two are intersting:
==17068== Syscall param write(buf) points to uninitialised byte(s)
==17068== at 0x41485F13: __write_nocancel (in /lib/libc-2.4.so)
==17068== by 0x4157567E: _X11TransWrite (in /usr/lib/libX11.so.6.2.0)
==17068== Syscall param ioctl(generic) points to uninitialised byte(s)
==17068== at 0x4148D3B9: ioctl (in /lib/libc-2.4.so)
==17068== by 0x4141279: do_wait (vblank.c:243)
==17068== by 0x4141350: driWaitForVBlank (vblank.c:311)
==17068== by 0x4148618: r200CopyBuffer (r200_ioctl.c:453)
==17068== by 0x4145775: r200SwapBuffers (r200_context.c:653)
==17068== by 0x414148E: driSwapBuffers (dri_util.c:472)
==17068== by 0x4277AEDD: glXSwapBuffers (in /usr/lib/libGL.so.1.2)
==17068== by 0x410F453D: glutSwapBuffers (in /usr/lib/libglut.so.3.8.0)
==17068== by 0x80494F4: Display (arbvpwarpmesh.c:88)
==17068== by 0x410FCB85: (within /usr/lib/libglut.so.3.8.0)
==17068== by 0x41100161: fgEnumWindows (in /usr/lib/libglut.so.3.8.0)
==17068== by 0x410FD43A: glutMainLoopEvent (in /usr/lib/libglut.so.3.8.0)
==17068== Address 0xBEB412E4 is on thread 1's stack
==17068== Warning: noted but unhandled ioctl 0x6447 with no size/direction hints
==17068== This could cause spurious value errors to appear.
==17068== See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a
proper wrapper.
==17068== Warning: noted but unhandled ioctl 0x6447 with no size/direction hints
==17068== This could cause spurious value errors to appear.
==17068== See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a
proper wrapper.
==17068== Warning: noted but unhandled ioctl 0x6447 with no size/direction hints
==17068== This could cause spurious value errors to appear.
==17068== See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a
proper wrapper.
I've no idea what the problem here really is (yeah yeah I know I should read
README_MISSING_SYSCALL_OR_IOCTL), the first one of these is somewhere buried in
libX11, maybe that's part of Xorg's ioctl-wrapper-for-everything design.
As for ARB_vbo, you're right they are not implemented in the driver. Any bugs
you see when using them are likely either a bug in mesa core, an application
bug, or exhibiting a problem which does not exist without them because the app
would do something different when not using it (i.e. instead of just doing
basically the same but with standard vertex arrays, it might do something
completely different). Last possibility would be the r200 vtxfmt code, if it's
no longer buggy if you use tcl_mode=1 then that's the case.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
