Bug 33494

If I add a sprintf before memcpy in r600_upload.c I was able to debug in r600_upload_buffer.

The call stack was :

#0  memcpy() at ../sysdeps/x86_64/memcpy.S:267
#1  fprintf() at /usr/include/bits/string3.h:52
#2  r600_upload_buffer() at r600_upload.c:109
#3  r600_upload_user_buffers() at r600_buffer.c:239
#4  evergreen_vertex_buffer_update() at evergreen_state.c:1372
#5  st_draw_vbo() at state_tracker/st_draw.c:712
...


Patch :
diff --git a/src/gallium/drivers/r600/r600_upload.c b/src/gallium/drivers/r600/r600_upload.c
index 44102ff..ba19185 100644
--- a/src/gallium/drivers/r600/r600_upload.c
+++ b/src/gallium/drivers/r600/r600_upload.c
@@ -103,7 +103,11 @@ int r600_upload_buffer(struct r600_upload *upload, unsigned offset,
        }
 
        in_ptr = in_buffer->user_buffer;
-       memcpy(upload->ptr + upload->offset, (uint8_t *) in_ptr + offset, size);
+       uint8_t * ptr_src = (uint8_t *) upload->ptr + upload->offset;
+       uint8_t * ptr_dest = (uint8_t *) in_ptr + offset;
+       //R600_ERR("memcpy src %d dest %d size %d\n", ptr_src, ptr_dest, size);
+       fprintf(stdout, "memcpy src %p dest %p size %d\n", ptr_src, ptr_dest, size);
+       memcpy(ptr_src, ptr_dest, size);
        *out_offset = upload->offset;
        *out_size = upload->size;
        *out_buffer = NULL;

Can you do me a favor an check what your UseVBO setting is? It's a config setting of the OpenGL renderer (check $HOME/.ut2004/System/UT2004.ini).

I'm interested because I'm also experiencing crashes in ut04 (see bug #33172) with certain settings.

With "UseVBO=True" I was be able to finish the loading.
But my system has freeze when i have try to spawn my player character.

I forgot to présise before : i have run test on a ATI Mobility Radeon HD 5730 (Evergreen).

(In reply to comment #4)
> If I haven't debbuggeur attach ut2004 terminate on a DBUS error (Signal SIGBUS)

A bus error indicates something may have gone wrong in the kernel. Is there something interesting in dmesg or the kernel log file?

(In reply to comment #4)
> (In reply to comment #4)
> > If I haven't debbuggeur attach ut2004 terminate on a DBUS error (Signal SIGBUS)
> 
> A bus error indicates something may have gone wrong in the kernel. Is there
> something interesting in dmesg or the kernel log file?

I have not seen anything significant in the log.

but with a 2.6.37 kernel with this patch from agd5f :
http://people.freedesktop.org/~agd5f/0001-drm-radeon-kms-re-emit-full-context-state-for-evergr.patch

ut2004 is killed by SIGBUS only in "very high"(the most hight level) texture detailed mode 
And crash isn't systematic, I haven't reproduce it with a debuggeur attach.

(In reply to comment #5)
> ut2004 is killed by SIGBUS only in "very high"(the most hight level) texture
> detailed mode 
> And crash isn't systematic, I haven't reproduce it with a debuggeur attach.

With last git version of mesa and r600g I can play with full detail at ut2004.
Thank's All

Was probably fixed by the same changes that also fixed bug #33172.