Re: waveINxxx "bad pointer" error in Debug version

"Chris P." <msdn@xxxxxxxxxxxx> wrote in message
news:19xmn4dhp7t8i.c7dd9b295sst.dlg@xxxxxxxxxxxxx
On Tue, 10 Feb 2009 16:25:31 -0400, Mitch Gallant wrote:

Here is what happens when I put a breakpoint and debug the *release*
version:
checking both pwaveHdr1 and pWaveHdr2 ... both are valid with no errors
in
pointers and with a dwFlag for both set at 3 (as expected ... headers
have
been prepared and are ready).
I ran this several times and get the same result always.

Now putting a breakpoint at same location and debugging the *debug*
version
always causes
pWaveHdr1 to have invalid pointer and the dwFlag is set to 0
pWaveHdr2 is valid (as the two headers were in the release version),

This seems to indicate something with the debug rt library causing the
problem.
The two waveheaders are prepared in exactly the same way and the code is
pretty simple standard code (again based on Petzold) for initializing and
preparing the buffers once, receiving full buffers for MM_WIM_DATA and
releasing them again with waveInAddBuffer()

The pointer pwaveHdr1 is in your data section (or stack) so if the pointer
value has changed then you have heap/stack corruption. I have never seen
this issue, and I have used waveIn extensively over the years with both
debug and release builds.

Problem solved.
I went back to the beginning in the DEBUG version and noticed that shortly
after the buffer allocations:

pBuffer1 = malloc (INP_BUFFER_SIZE) ;
pBuffer2 = malloc (INP_BUFFER_SIZE) ;

pBuffer1 was being corrupted (bad pointer). (The problem wasn't actually
with pWaveHdr.)

The problem was caused by another unrelated function call which had an
incorrect parameter:

I tend to use the text-generic (and define UNICODE and _UNICODE) and "safe"
time function
to get a date/time string:

time(&t1);
err1 = _wctime_s(ctimsize, sizeof(ctimsize)/sizeof(TCHAR), &t1);
//correct version!

I noticed that right after _wctime_s was called, pBuffer1 became a bad
pointer.
_wctime_s needs a buffer of 26 characters. Originally I forgot the
/sizeof(TCHAR) to get the proper buffer size in TCHAR. I was originally
getting 52 characters since I had UNICODE defined which didn't match TCHAR
ctimsize[26]. This didn't cause an error and _wctime_s returned no error.
But it must have caused a buffer over-reading and corrupted pBuffer1.

Anyway that fixed the problem. Thanks for the help trying to fix this.
Since both the debug and RELEASE versions have UNICODE and _UNICODE defined,
I'm still not sure why pBuffer1 wasn't similarly corrupted. At any rate, the
bug was a user-code bug.

Cheers,
- Mitch


.

Relevant Pages

  • Re: waveINxxx "bad pointer" error in Debug version
    ... Now putting a breakpoint at same location and debugging the *debug* version ... preparing the buffers once, receiving full buffers for MM_WIM_DATA and ... The pointer pwaveHdr1 is in your data section so if the pointer ...
    (microsoft.public.win32.programmer.mmedia)
  • [net-next PATCH 4/5] igb: Add support for enabling VFs to PF driver.
    ... pointer to the hardware struct ... under the terms and conditions of the GNU General Public License, ... * @msg: The message buffer ... * returns SUCCESS if it successfully copied message into the buffer ...
    (Linux-Kernel)
  • Re: Simple C containers, std::vector analog
    ... the computing power of thiry ... Thirty years ago it was 1975 and computers ran in Kilohertz ... and some implementations do choke on realloc'ing a null pointer. ... template f void f(voidpT buffer){ ...
    (comp.lang.c)
  • Re: some unanswered questions on C
    ... A pointer variable that's never been given a value. ... you don't know what memory you're modifying. ... >what i want to ask is that when i declare my buffer for fgets as ... "char *buffer" creates a pointer, ...
    (comp.unix.programmer)
  • [patch] x86, ptrace: PEBS support
    ... BTS and PEBS recording. ... * - buffer overflow handling ... (interrupt occurs when write pointer passes interrupt pointer) ... * guarding context and buffer memory allocation. ...
    (Linux-Kernel)
Loading