Can you break on _mesa_error and find what the GL call is that's triggering the invalid value?

Created attachment 33291 [details]
debug output with backtrace output

added code to imports.c to output backtrace information

I had problems to break - perhaps its because of wine or something. I downloaded the 7.7 Mesa from http://www.mesa3d.org/relnotes-7.7.html and compiled it by myself. To output the stacktrace I added this short snipped of code (taken from glibc documentation :) )

what exacly do you need to know?

--- Mesa-7.7/src/mesa/main/imports.c	2010-02-14 22:38:30.487775140 +0100
***************
*** 1161,1166 ****
--- 1161,1188 ----
   * \param error the error value.
   * \param fmtString printf() style format string, followed by optional args
   */
+ 
+      /* Obtain a backtrace and print it to stdout. */
+      void
+      print_trace (void)
+      {
+        void *array[10];
+        size_t size;
+        char **strings;
+        size_t i;
+      
+        size = backtrace (array, 10);
+        strings = backtrace_symbols (array, size);
+      
+        printf ("Obtained %zd stack frames.\n", size);
+      
+        for (i = 0; i < size; i++)
+           printf ("%s\n", strings[i]);
+      
+        free (strings);
+      }
+ 
+ 
  void
  _mesa_error( GLcontext *ctx, GLenum error, const char *fmtString, ... )
  {
***************
*** 1201,1206 ****
--- 1223,1230 ----
  
           _mesa_snprintf(s2, MAXSTRING, "%s in %s", error_string(error), s);
           output_if_debug("Mesa: User error", s2, GL_TRUE);
+ 
+ 	 print_trace();
           
           ctx->ErrorDebugFmtString = fmtString;
           ctx->ErrorDebugCount = 0;
***************
*** 1211,1216 ****
--- 1235,1241 ----
  }

Reassigning it away from the Intel driver, since you aren't using it in the log with backtraces (you're using swrast).

Ah ok. Is swrast a compatibility layer which forwards the calls? Because the i965_dri is also in use (as of lsof) 

ExeFile.e  1655       done  mem       REG        8,7  11480092  238362647 /home/done/Mesa-7.7/lib/swrast_dri.so
ExeFile.e  1655       done  mem       REG        8,7  16742226  238266415 /home/done/Mesa-7.7/lib/i965_dri.so

(In reply to comment #5)
> Ah ok. Is swrast a compatibility layer which forwards the calls? Because the
> i965_dri is also in use (as of lsof) 
> 
> ExeFile.e  1655       done  mem       REG        8,7  11480092  238362647
> /home/done/Mesa-7.7/lib/swrast_dri.so
> ExeFile.e  1655       done  mem       REG        8,7  16742226  238266415
> /home/done/Mesa-7.7/lib/i965_dri.so

This probably means there is some missing symbol in your i965_dri.so.  libGL tries to load it, but the driver initialization fails.  libGL then falls back to swrast_dri.so and completely ignores i965_dri.so.  'LIBGL_DEBUG=verbose glxinfo' may shed some light on the issue.

(In reply to comment #0)
> fixme:d3d_surface:surface_allocate_surface >>>>>>>>>>>>>>>>> GL_INVALID_VALUE
> (0x501) from glTexImage2D @ surface.c / 602
> fixme:d3d_surface:surface_upload_data >>>>>>>>>>>>>>>>> GL_INVALID_ENUM (0x500)
> from glCompressedTexSubImage2DARB @ surface.c / 532

I'll bet a shinny nickle that the app is trying to give S3TC data to a driver that doesn't support S3TC.  A printf in _mesa_CompressedTexSubImage2DARB of format will settle it right quick.  If format is from the following list, the app is erroneously sending S3TC:

#define GL_COMPRESSED_RGB_S3TC_DXT1_EXT   0x83F0
#define GL_COMPRESSED_RGBA_S3TC_DXT1_EXT  0x83F1
#define GL_COMPRESSED_RGBA_S3TC_DXT3_EXT  0x83F2
#define GL_COMPRESSED_RGBA_S3TC_DXT5_EXT  0x83F3
#define GL_RGB_S3TC                       0x83A0
#define GL_RGB4_S3TC                      0x83A1
#define GL_RGBA_S3TC                      0x83A2
#define GL_RGBA4_S3TC                     0x83A3
#define GL_COMPRESSED_SRGB_S3TC_DXT1_EXT  0x8C4C
#define GL_COMPRESSED_SRGB_ALPHA_S3TC_DXT1_EXT 0x8C4D
#define GL_COMPRESSED_SRGB_ALPHA_S3TC_DXT3_EXT 0x8C4E
#define GL_COMPRESSED_SRGB_ALPHA_S3TC_DXT5_EXT 0x8C4F

Waited 9 months for a reply and got none.  Closing.