> When enabling and compiling this with mingw on Win32, my debugger > complains about heap overruns when calling speex_encoder_destroy(). This > could be a mingw issue though, as I also found a stackalignment bug which > prevents me from _USING_SSE (apparantly -mpreferred-stack-size is just > "prefered" and therefore ignored... *Sigh*).Just so I understand, the debugger complains, but the code still runs? What's the message?> But, before that point, there seems to be.. well.. I seem to think it's > better, but that could be just because I expect it to be better.Well, that's a start... what bit-rate are you using?> If the heap problem can be fixed, I can ninja-include this in the next > version of Mumble and then poll users' opinions :)That would indeed give nice testing. Just be aware that it's very experimental and I don't know all the side effects of that. Jean-Marc
>> When enabling and compiling this with mingw on Win32, my debugger >> complains about heap overruns when calling speex_encoder_destroy(). This >> could be a mingw issue though, as I also found a stackalignment bug which >> prevents me from _USING_SSE (apparantly -mpreferred-stack-size is just >> "prefered" and therefore ignored... *Sigh*). > > Just so I understand, the debugger complains, but the code still runs? > What's the message?That's right. Ah, I don't have the code here right now, but it was "heap overrun of 200 bytes", meaning it wrote 200 bytes beond the allocated block. If I am to guess, the debugger adds safety markers at the start and end of each heap block and checks those during deallocation, so the actual overrun probably happens sometime earlier.>> But, before that point, there seems to be.. well.. I seem to think it's >> better, but that could be just because I expect it to be better. > > Well, that's a start... what bit-rate are you using?VBR, quality 6.0, wideband, with preprocessor.>> If the heap problem can be fixed, I can ninja-include this in the next >> version of Mumble and then poll users' opinions :) > > That would indeed give nice testing. Just be aware that it's very > experimental and I don't know all the side effects of that.I guess we'll find out.
> That's right. Ah, I don't have the code here right now, but it was "heap > overrun of 200 bytes", meaning it wrote 200 bytes beond the allocated > block.Sorry, can't reproduce the problem here, even with valgrind. Maybe something wrong with your compiler or your debugger?> >> If the heap problem can be fixed, I can ninja-include this in the next > >> version of Mumble and then poll users' opinions :) > > > > That would indeed give nice testing. Just be aware that it's very > > experimental and I don't know all the side effects of that. > > I guess we'll find out.Cool. Let me know what the result is. Jean-Marc
Happy new year all! I have had a few issues with this sort of stuff- you could adjust NB_ENC_STACK or SB_ENC_STACK (which ever you may be fiddling with) and see if the problem goes away- could be the allocation for the vorbis psy tables takes up more space than the current stack size allows (not sure how allocated? Could be your settings for supporting alloca/etc. are set different than jm, due to support for variable size arrays. Haven't had a chance to look at the new(er) stuff yet, but that would be my guess... Tom At 11:15 PM 12/31/2005, Thorvald Natvig wrote:>That's right. Ah, I don't have the code here right now, but it was "heap >overrun of 200 bytes", meaning it wrote 200 bytes beond the allocated block.