sound issues

frag.machine · Post by **frag.machine** » Sat Apr 17, 2010 9:08 pm

mh wrote:
Spike wrote:Thirdly, the behaviour of malloc differing between debug/release/compiler is a GOOD thing. Any memory bug you have is a memory bug. Generally involving breaking other bits of memory. Change some code somewhere and you get random differences elsewhere. Sure, okay, memory working the same way as debug builds always is easier, but results in minor errors that you'll never find. A malloc that is random every time is awesome.
Additionally, you can link your app against a third-party library that provides such debugging features instead of having to roll your own.
It depends. If the debug behaviour has tighter validation and constraints then yeah it's a good thing. If on the other hand you have a situation where debug malloc memsets 0 whereas release malloc doesn't, you've got a backdoor for subtle bugs to come in, and your debug build is effectively worthless for verifying correctness of your release build.

AFAIK this behavior is restrict to Microsoft's implementation and no other C runtime does this "automatic memset to 0 when malloc'ing" stuff in debug mode. Not to mention that it's both an useless performance penalty and a nasty way to induce novice (and even experienced) programmers in error.

Spike · Post by **Spike** » Sun Apr 18, 2010 12:03 am

msvc's debug malloc memsets to 0xcc (which is the x86 int3 debugging opcode).
Other compilers tend not to use different libraries for debug or release builds. You can force it though, or in linux, just use LD_PRELOAD.

With release builds, most secure operating systems will memset to 0 the first time you start it up. Well, less memset, more clear out for the sake of security. Of course, this only works the first time you use a page, rather than an actual allocation, as its the heap that is cleared, not the allocations. This means its quite likely you won't notice that its not cleared in a release build.

Anyway, point is, malloc > rewriting malloc, even if you wrap it. If you want cleared memory, use calloc instead.

revelator · Post by **revelator** » Sun Apr 18, 2010 3:27 am

yikes well as for strange stuff that can happen with bad memory pointers as i just found out the hard way.

command buffer goes boom literally last char of any command gets cut of example toggleconsole now fails with toggleconsol unknown command.
same for cvars.

keybindings also affected erf looks like i will have to redo the entire thing from scratch.

revelator · Post by **revelator** » Tue Apr 20, 2010 3:08 am

fixed the command crap now im left with the SZ_GetSpace errors

basically this happens whenever i try to load a map SZ_GetSpace 1 > max buffer size

well i dont quite get that one as the starting buffer is 256 bytes wide but an integer size of one is larger than it wtf

the only place i been able to hunt it down to is from some call to Msg_WriteByte the debugger stalls there however so bleargh.

might have to rewrite these functions to actually print the name of the function it failed in.

revelator · Post by **revelator** » Tue Apr 20, 2010 5:12 am

found the bugger maxclients was'nt initialized to zero.

works again now unfortunatly this had no affect on the sound problem whatsoever

may have to bite the sour apple and admit that something in my compiler is bitching loudly at this

revelator · Post by **revelator** » Tue Apr 20, 2010 9:55 pm

changed the malloc calls that initialize to zero to calloc and works quite good.

still stuck on sound will try and look into an older darkplaces with migw support for anything i missed,

revelator · Post by **revelator** » Wed Apr 21, 2010 4:19 am

well its definatly compiler related as i just tried linking with the ms sdk libraries (works fine) but it still sounds like a frying pan with popcorn on it

i did notice a few warnings about variables allready defined elsewhere in my system headers the funny thing is these are not even included

one thing i came about thinking off was your quakeasm library i believe some of the sound system comes from this ?

allthough not sure i wonder if the ms compiled asm code somehow freaks out the gcc compiler hmm

revelator · Post by **revelator** » Wed Apr 21, 2010 4:29 am

well ill be damned and someone color me red

it was indeed the quakeasm library after removing it and enabling the corresponding c functions the thing runs like hell on ice and sound works yay

Chip · Post by **Chip** » Wed Apr 21, 2010 12:24 pm

Here's a C-newb question.

Can I use your compiler as a standalone solution for C-based programs? I'd be interested in building the Qoole source, the one that's freely available. What about C++?

revelator · Post by **revelator** » Wed Apr 21, 2010 6:33 pm

it handles c/c++/ada/java so i would say yes

as for qoole not sure what compiler was used for it in the past but with some setup it should definatly be buildable with this.

Chip · Post by **Chip** » Wed Apr 21, 2010 11:02 pm

reckless wrote:it handles c/c++/ada/java so i would say yes

as for qoole not sure what compiler was used for it in the past but with some setup it should definatly be buildable with this.

I'll give it a shot and I'll let you know!

revelator · Post by **revelator** » Thu Apr 22, 2010 12:11 am

ill be happy to help as much as i can if any compatibility issues arise.

Spike · Post by **Spike** » Thu Apr 22, 2010 12:22 am

from what I remember, qoole was originally a dos program.

so this should be fun.
its already been ported once, so chances are it'll be the libraries used, rather than the code itself that present any issues.
may also need a makefile. *shudder*.

revelator · Post by **revelator** » Thu Apr 22, 2010 4:31 am

oh thats evil

i hope it dos'nt (phun phun) make calls to the 16 bit api else porting will be a bitch

revelator · Post by **revelator** » Thu Apr 22, 2010 4:44 am

just downloaded it to see if there would be any buggers i couldnt work around and hello and behold it uses mfc

it might be possible if you can link against the mssdk's mfc libraries but i suspect that wont be very easy.

tbh your better of with msvc in this case.