Summary: | valgrind reports invalid write of size 4 in r200_swtcl.c (of mesa-7.2) | ||
---|---|---|---|
Product: | Mesa | Reporter: | Hugo Mildenberger <Hugo.Mildenberger> |
Component: | Drivers/DRI/r200 | Assignee: | Default DRI bug account <dri-devel> |
Status: | NEW --- | QA Contact: | |
Severity: | normal | ||
Priority: | medium | ||
Version: | unspecified | ||
Hardware: | x86 (IA32) | ||
OS: | Linux (All) | ||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Attachments: | outpout of valgrind --logfile=glxgears.log /usr/bin/valgrind |
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.
Created attachment 20471 [details] outpout of valgrind --logfile=glxgears.log /usr/bin/valgrind Being after a strange problem with mesa on Gentoo x86 hardened, I did run valgrind on glxgears demo program, having compiled all mesa-7.2 with gcc-4.3.2, option -g -O0, and --disable-asm configure option. Valgrind reports (beneath other inconsistencies) a bunch of illegal writes in r200, which, however, may be DMA related and thus simply a problem of valgrind itself. I wouldn't look too closely at this, if I would not had constantly seen an sse-related crash due to a dangling function pointer. Invalid write of size 4 ==3606== at 0x4FF1DA2: r200_quad (r200_swtcl.c:18340) The high line number given by valgrind stems from r200_swtcl.c being compiled as an already preprocessed file (due to gdb limitations). Since it is very large, I'll attach it upon request only. Inspecting the program using gdb does not give any clue what is going on: 18340 do { for ( j = 0 ; j < vertsize ; j++ ) vb[j] = ((GLuint *)v0)[j]; vb += vertsize ; } while (0); gdb says, that "vb" would be invalid, but this simply can not be, and is probably a consequence of gdb not dealing well with DMA-related address ranges."vertsize" if 4, as is "j" at the end of this statement.