Home
Guides
Forum
Blogs
Game content
Media
Site
View forums
Search
Rules
User panel stuff on forum
Index  ‹  Client Talk  ‹  Fix for overlapping memcpy in q_shared.c in ezquake 3.0
  7 posts on 1 page  1
Client Talk
2014-12-04, 15:09
Member
188 posts

Registered:
Feb 2008
As the trace shows, the buffers overlap, so use memmove instead of memcpy here.

(gdb) bt
#0 0x000017a3c5eb670a in kill () at <stdin>:2
#1 0x000017a3c5f18089 in abort () at /usr/src/lib/libc/stdlib/abort.c:53
#2 0x000017a3c5eed2b8 in memcpy (dst0=0xf4684, src0=0x6, length=0) at /usr/src/lib/libc/string/memcpy.c:65
#3 0x000017a0c7c45b40 in qwcslcpy (dst=0x17a0cb4e681c, src=0x17a0cb4e681e, size=2048) at q_shared.c:502
#4 0x000017a0c7cc15ac in CL_ParsePrint () at cl_parse.c:2832
#5 0x000017a0c7cc5dbc in CL_ParseServerMessage () at cl_parse.c:3284
#6 0x000017a0c7cbd60c in CL_ReadPackets () at cl_main.c:1666
#7 0x000017a0c7cbf8aa in CL_Frame (time=) at cl_main.c:2423
#8 0x000017a0c7c3fc58 in Host_Frame (time=0.0081969999999955689) at host.c:435
#9 0x000017a0c7d7e6c5 in main (argc=5, argv=0x7f7fffff9838) at sys_posix.c:319
Current language: auto; currently asm


Fix:

--- q_shared.c.orig Thu Dec 4 16:01:14 2014
+++ q_shared.c Thu Dec 4 16:01:27 2014
@@ -499,7 +499,7 @@

if (len < size) {
// it'll fit
- memcpy (dst, src, (len + 1) * sizeof(wchar));
+ memmove (dst, src, (len + 1) * sizeof(wchar));
return len;
}

2015-03-06, 14:25
Administrator
1025 posts

Registered:
Apr 2006
Thanks, applied on master.
2015-03-06, 16:01
Member
344 posts

Registered:
Nov 2006
// it'll fit


famous last words..
2015-03-07, 06:13
Member
357 posts

Registered:
Mar 2006
+1 memmove
dim, i got glsl working for r_waterwarp, will work on gamma/blur next.
its in Qrack but should port jive with ezQuake as shares Zquake as a core...
2015-03-07, 20:48
Administrator
1025 posts

Registered:
Apr 2006
SputnikUtah wrote:
+1 memmove
dim, i got glsl working for r_waterwarp, will work on gamma/blur next.
its in Qrack but should port jive with ezQuake as shares Zquake as a core...

Feel free I tested glsl gamma code from quakespasm yesterday (in ezQuake), however its a post processing shader and currently costs about 50-70% performance :/
2015-03-08, 03:45
Member
357 posts

Registered:
Mar 2006
hmm ya i was wondering about that. grabs a scene copies to texture modifies it then paints back over.
kinda how blooms work. drawing with vertex buffers helps but all just for gama so the second monitor has indepentent gamma seems like a waste
2015-03-08, 09:24
Administrator
1025 posts

Registered:
Apr 2006
SputnikUtah wrote:
hmm ya i was wondering about that. grabs a scene copies to texture modifies it then paints back over.
kinda how blooms work. drawing with vertex buffers helps but all just for gama so the second monitor has indepentent gamma seems like a waste

Xewie started working on rendering things with shaders and fix gamma there, didn't cost much at all but required shaders for everything and it wasn't complete. I've got about zero knowledge of OpenGL/gfx so I skipped it. It's in the git history though if interested, some commits ago I reverted it.

Spike told me to use FBOs and it would "solve" the perf problems with post processing gamma shader. Still, thats sort of greek atm :/

I really oughta get interested in gfx and learn it...
  7 posts on 1 page  1