malloc does not allocate beyond 65872

Please support our C advertiser: Programming Forums - DaniWeb Sister Site
Reply

Join Date: Aug 2005
Posts: 15,442
Reputation: Ancient Dragon has a reputation beyond repute Ancient Dragon has a reputation beyond repute Ancient Dragon has a reputation beyond repute Ancient Dragon has a reputation beyond repute Ancient Dragon has a reputation beyond repute Ancient Dragon has a reputation beyond repute Ancient Dragon has a reputation beyond repute Ancient Dragon has a reputation beyond repute Ancient Dragon has a reputation beyond repute Ancient Dragon has a reputation beyond repute Ancient Dragon has a reputation beyond repute 
Solved Threads: 1474
Team Colleague
Featured Poster
Ancient Dragon's Avatar
Ancient Dragon Ancient Dragon is offline Offline
Still Learning

Re: malloc does not allocate beyond 65872

 
-7
  #11
Aug 25th, 2009
  1. int main()
  2. {
  3. short *ay = (short int*)malloc(sizeof(short int)*66000);
  4. printf("%p\n", ay);
  5. return 0;
  6. } //end of main function

The above worked without a problem using VC++ 2008 Express. Chalk another one up for Microsoft vc GNU (so far that makes two during the past seven days)
Don't PM me with questions -- you might get a nasty PM in response. If you have a question then post it in one of the forums.
Reply With Quote Quick reply to this message  
Join Date: Aug 2009
Posts: 7
Reputation: aflneto is an unknown quantity at this point 
Solved Threads: 0
aflneto aflneto is offline Offline
Newbie Poster

Re: malloc does not allocate beyond 65872

 
0
  #12
Aug 25th, 2009
Originally Posted by Ancient Dragon View Post
  1. int main()
  2. {
  3. short *ay = (short int*)malloc(sizeof(short int)*66000);
  4. printf("%p\n", ay);
  5. return 0;
  6. } //end of main function

The above worked without a problem using VC++ 2008 Express. Chalk another one up for Microsoft vc GNU (so far that makes two during the past seven days)
Actually the above also compiled on gcc without a problem. gnu won't go down without a fight. =P .

so there must be something else wrong with the code.
Reply With Quote Quick reply to this message  
Join Date: Dec 2005
Posts: 5,850
Reputation: Salem has a reputation beyond repute Salem has a reputation beyond repute Salem has a reputation beyond repute Salem has a reputation beyond repute Salem has a reputation beyond repute Salem has a reputation beyond repute Salem has a reputation beyond repute Salem has a reputation beyond repute Salem has a reputation beyond repute Salem has a reputation beyond repute Salem has a reputation beyond repute 
Solved Threads: 749
Team Colleague
Salem's Avatar
Salem Salem is offline Offline
Void main'ers are DOOMed

Re: malloc does not allocate beyond 65872

 
1
  #13
Aug 25th, 2009
Regarding casting malloc.
Here's why it's a really BAD idea.
http://faq.cprogramming.com/cgi-bin/...&id=1043284351

Second, are these the ONLY malloc calls in your code, or are there others?
If you screw up with malloc even once, then any subsequent use of malloc/free can fail for any reason, at any time.
Staring at where it crashes will NOT tell you anything useful.

The only realistic chance that we (as remote viewers) have of telling you where such a problem is is by having the whole source code. If you've got masses of code, this is probably a non-starter. If you can trim it down to a couple of functions which still crash, then we could probably help.

Finally, let's talk about how you're corrupting memory (so my bet is you're doing this somewhere else where it would matter, only you don't realise it).

strcpy(myRIFF->header->riffChunkID, "RIFF");
myRIFF->header->riffChunkDataSize = numsamples*2 + 36;

The size immediately follows the ID.
Which is unfortunate, because the strcpy is going to copy FIVE bytes into space where there is only room for FOUR.
Fortunately, initialising the size takes place afterwards, so you get lucky.
But reverse the code, and your strcpy() would trash part of the size!

Maybe somewhere else, you're allocating a lot less that you thought (after all, \0 has overwritten some part of a size). Or maybe you're allocating a hell of a lot more than you bargained for, Either way, it isn't good.

BTW, which OS are you running gcc on?
If it's windows, then I would remark on your use of "w" when writing binary data.
Reply With Quote Quick reply to this message  
Join Date: Sep 2008
Posts: 62
Reputation: AutoC is an unknown quantity at this point 
Solved Threads: 0
AutoC AutoC is offline Offline
Junior Poster in Training

Re: malloc does not allocate beyond 65872

 
0
  #14
Aug 26th, 2009
wow..ok..the malloc casting was out of habit.I'll stop doing that

Second, are these the ONLY malloc calls in your code, or are there others?
> The WriteRiff function is in a separate program that is included and its the only function called from that program. There are a lot of other mallocs but everything seems to work fine upto the WriteRiff call. I've verified it.
I'll fix the memory allocation

I'm running on fedora 10
I've attached the program that contains WriteRiff.Please take a look.
Attached Files
File Type: h SphereInterface.h (1.5 KB, 2 views)
File Type: c SphereInterface.c (16.0 KB, 2 views)
Reply With Quote Quick reply to this message  
Join Date: Dec 2005
Posts: 5,850
Reputation: Salem has a reputation beyond repute Salem has a reputation beyond repute Salem has a reputation beyond repute Salem has a reputation beyond repute Salem has a reputation beyond repute Salem has a reputation beyond repute Salem has a reputation beyond repute Salem has a reputation beyond repute Salem has a reputation beyond repute Salem has a reputation beyond repute Salem has a reputation beyond repute 
Solved Threads: 749
Team Colleague
Salem's Avatar
Salem Salem is offline Offline
Void main'ers are DOOMed

Re: malloc does not allocate beyond 65872

 
1
  #15
Aug 26th, 2009
> I'm running on fedora 10
Excellent.

Then you can try either of these and see what's going on.

valgrind ./myprog
valgrind is a tool used for spotting all sorts of memory management problems.

  1. gcc -o myprog prog.c -lefence
  2. gdb ./myprog
electric fence (which you link with -lefence) is a malloc debugger. Should you overstep any malloc'ed memory, you will immediately get a segfault, and be dropped in the debugger at the exact line of code causing the problem.
Reply With Quote Quick reply to this message  
Join Date: Sep 2008
Posts: 62
Reputation: AutoC is an unknown quantity at this point 
Solved Threads: 0
AutoC AutoC is offline Offline
Junior Poster in Training

Re: malloc does not allocate beyond 65872

 
0
  #16
Aug 26th, 2009
Originally Posted by Salem View Post
> I'm running on fedora 10
Excellent.

Then you can try either of these and see what's going on.

valgrind ./myprog
valgrind is a tool used for spotting all sorts of memory management problems.

  1. gcc -o myprog prog.c -lefence
  2. gdb ./myprog
electric fence (which you link with -lefence) is a malloc debugger. Should you overstep any malloc'ed memory, you will immediately get a segfault, and be dropped in the debugger at the exact line of code causing the problem.
Thanks.I'll try them both.
Reply With Quote Quick reply to this message  
Join Date: Sep 2008
Posts: 62
Reputation: AutoC is an unknown quantity at this point 
Solved Threads: 0
AutoC AutoC is offline Offline
Junior Poster in Training

Re: malloc does not allocate beyond 65872

 
0
  #17
Aug 26th, 2009
I've somehow managed to fix that error through a sequence of attempts but cant figure out what fixed it. But the error was actually in another malloc. thanks to valgrind.

I'm stuck in another place and the command Im using is

fwrite( riff->header, 44, 1, file)

and valgrind says..
==32304== Syscall param write(buf) points to uninitialised byte(s)
==32304== at 0x55FAE3: __write_nocancel (in /lib/libc-2.9.so)
==32304== by 0x4F6925: _IO_file_xsputn@@GLIBC_2.1 (in /lib/libc-2.9.so)
==32304== by 0x4EC399: fwrite (in /lib/libc-2.9.so)
==32304== by 0x80546A1: WriteRIFFWaveFile (SphereInterface.c:375)
==32304== by 0x8054638: WriteRIFF (SphereInterface.c:359)
==32304== by 0x8049657: rmSilence (egySil.c:190)
==32304== by 0x804972D: main (egySil.c:213)

what does that mean?
Reply With Quote Quick reply to this message  
Join Date: Dec 2005
Posts: 5,850
Reputation: Salem has a reputation beyond repute Salem has a reputation beyond repute Salem has a reputation beyond repute Salem has a reputation beyond repute Salem has a reputation beyond repute Salem has a reputation beyond repute Salem has a reputation beyond repute Salem has a reputation beyond repute Salem has a reputation beyond repute Salem has a reputation beyond repute Salem has a reputation beyond repute 
Solved Threads: 749
Team Colleague
Salem's Avatar
Salem Salem is offline Offline
Void main'ers are DOOMed

Re: malloc does not allocate beyond 65872

 
1
  #18
Aug 26th, 2009
I've no idea.
I stripped the code down to something simple, and it seems clean here.
  1. /*-------------------------------------------------------------------------
  2.  * SphereInterface.c - Library of functions to read different wavefile formats
  3.  * Version: $Name: $
  4.  * Module:
  5.  *
  6.  * Purpose:
  7.  * See:
  8.  *
  9.  * Author: Hema Murthy (hema@bhairavi.iitm.ernet.in)
  10.  *
  11.  * Created: Thu 01-Mar-2007 12:19:44
  12.  * Last modified: Wed 13-Jun-2007 08:45:53 by hema
  13.  * $Id: SphereInterface.c,v 1.4 2007/06/14 08:25:49 hema Exp hema $
  14.  *
  15.  * Bugs:
  16.  *
  17.  * Change Log: <Date> <Author>
  18.  * <Changes>
  19.  -------------------------------------------------------------------------*/
  20.  
  21. #include <stdio.h>
  22. #include <string.h>
  23. #include "stdlib.h"
  24. #include "SphereInterface.h"
  25.  
  26. /*****************************************************************************
  27.   function : WriteRIFF - write to a file in RIFF format assumes
  28.   data is sampled at 16KHz and quantised to 16bits/sample
  29.   Inputs : wavefilename
  30.   Outputs : short waveform, numSamples
  31.   **************************************************************************/
  32.  
  33. //=================== WriteWaveFile ===================//
  34. int
  35. WriteRIFF (char *waveFileName, short *waveform, long numsamples,
  36. long samplingRate, int bytesPerSample)
  37. {
  38. FILE *file;
  39. RIFFWaveFile *myRIFF = NULL;
  40. long i = 0;
  41. long size = 0;
  42. int result = SUCCESS;
  43. file = fopen (waveFileName, "w");
  44. myRIFF = (RIFFWaveFile *) malloc (sizeof (RIFFWaveFile));
  45. myRIFF->header = (RIFFHeader *) malloc (sizeof (RIFFHeader));
  46.  
  47. strcpy (myRIFF->header->riffChunkID, "RIFF");
  48. myRIFF->header->riffChunkDataSize = numsamples * 2 + 36;
  49. strcpy (myRIFF->header->riffType, "WAVE");
  50.  
  51.  
  52. strcpy (myRIFF->header->fmtChunkID, "fmt ");
  53. myRIFF->header->fmtChunkDataSize = 16;
  54. myRIFF->header->compressionCode = 1;
  55. myRIFF->header->numberOfChannel = 1;
  56. myRIFF->header->sampleRate = samplingRate;
  57. myRIFF->header->averageBytesPerSecond = bytesPerSample * samplingRate;
  58. myRIFF->header->blockAlign = 2;
  59. myRIFF->header->sigBitsPerSample = bytesPerSample * 8;
  60.  
  61. strcpy (myRIFF->header->dataChunkID, "data");
  62. myRIFF->header->dataChunkDataSize = numsamples * 2;
  63. size = myRIFF->header->dataChunkDataSize / 2;
  64.  
  65. printf ("size:%d\n", size);
  66. myRIFF->data = (short int *) malloc (sizeof (short int) * size);
  67. for (i = 0; i < size; i++)
  68. {
  69. myRIFF->data[i] = waveform[i];
  70. }
  71.  
  72. result = WriteRIFFWaveFile (myRIFF, size * 2, file);
  73.  
  74. fclose (file); /*!! was AFTER return */
  75. return result;
  76. }
  77.  
  78. //=================== WriteRIFFWaveFile ===================//
  79. int
  80. WriteRIFFWaveFile (RIFFWaveFile * riff, int size, FILE * file)
  81. {
  82. int result = SUCCESS;
  83.  
  84. if (fwrite (riff->header, 44, 1, file) != 1)
  85. {
  86. result = FAILURE;
  87. }
  88.  
  89. if (fwrite (riff->data, size, 1, file) != 1)
  90. {
  91. result = FAILURE;
  92. }
  93.  
  94. return result;
  95. }
  96.  
  97. int
  98. main ()
  99. {
  100. short data[] = { 1, 2, 3, 4, 5 };
  101. WriteRIFF ("wav.wav", data, 5, 123, 2 );
  102. return 0;
  103. }
  104.  
  105. $ gcc SphereInterface.c
  106. In file included from SphereInterface.c:24:
  107. SphereInterface.h:31: warning: ‘packed’ attribute ignored
  108. $ valgrind ./a.out
  109. ==5800== Memcheck, a memory error detector.
  110. ==5800== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
  111. ==5800== Using LibVEX rev 1804, a library for dynamic binary translation.
  112. ==5800== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
  113. ==5800== Using valgrind-3.3.0-Debian, a dynamic binary instrumentation framework.
  114. ==5800== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
  115. ==5800== For more details, rerun with: -v
  116. ==5800==
  117. size:5
  118. ==5800==
  119. ==5800== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 11 from 1)
  120. ==5800== malloc/free: in use at exit: 62 bytes in 3 blocks.
  121. ==5800== malloc/free: 4 allocs, 1 frees, 414 bytes allocated.
  122. ==5800== For counts of detected errors, rerun with: -v
  123. ==5800== searching for pointers to 3 not-freed blocks.
  124. ==5800== checked 60,188 bytes.
  125. ==5800==
  126. ==5800== LEAK SUMMARY:
  127. ==5800== definitely lost: 62 bytes in 3 blocks.
  128. ==5800== possibly lost: 0 bytes in 0 blocks.
  129. ==5800== still reachable: 0 bytes in 0 blocks.
  130. ==5800== suppressed: 0 bytes in 0 blocks.
  131. ==5800== Rerun with --leak-check=full to see details of leaked memory.
  132. $ ls -l wav.wav
  133. -rw-r--r-- 1 user group 54 2009-08-26 19:42 wav.wav
  134.  
Reply With Quote Quick reply to this message  
Reply

This thread is more than three months old.
Perhaps start a new thread instead?
Message:


Thread Tools Search this Thread



About Us | Contact Us | Advertise | DaniWeb | Acceptable Use Policy | RSS Feed

©2003 - 2009 DaniWeb® LLC