943,771 Members | Top Members by Rank

Ad:
  • C Discussion Thread
  • Unsolved
  • Views: 1185
  • C RSS
You are currently viewing page 2 of this multi-page discussion thread; Jump to the first page
Aug 25th, 2009
-7

Re: malloc does not allocate beyond 65872

  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)
Sponsor
Team Colleague
Featured Poster
Reputation Points: 5608
Solved Threads: 2282
Retired and Enjoying Life
Ancient Dragon is offline Offline
21,950 posts
since Aug 2005
Aug 25th, 2009
0

Re: malloc does not allocate beyond 65872

  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.
Reputation Points: 10
Solved Threads: 0
Newbie Poster
aflneto is offline Offline
7 posts
since Aug 2009
Aug 25th, 2009
1

Re: malloc does not allocate beyond 65872

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.
Team Colleague
Reputation Points: 5862
Solved Threads: 950
Posting Sage
Salem is offline Offline
7,164 posts
since Dec 2005
Aug 26th, 2009
0

Re: malloc does not allocate beyond 65872

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, 4 views)
File Type: c SphereInterface.c (16.0 KB, 4 views)
Reputation Points: 10
Solved Threads: 0
Junior Poster in Training
AutoC is offline Offline
74 posts
since Sep 2008
Aug 26th, 2009
1

Re: malloc does not allocate beyond 65872

> 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.
Team Colleague
Reputation Points: 5862
Solved Threads: 950
Posting Sage
Salem is offline Offline
7,164 posts
since Dec 2005
Aug 26th, 2009
0

Re: malloc does not allocate beyond 65872

Click to Expand / Collapse  Quote originally posted by Salem ...
> 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.
Reputation Points: 10
Solved Threads: 0
Junior Poster in Training
AutoC is offline Offline
74 posts
since Sep 2008
Aug 26th, 2009
0

Re: malloc does not allocate beyond 65872

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?
Reputation Points: 10
Solved Threads: 0
Junior Poster in Training
AutoC is offline Offline
74 posts
since Sep 2008
Aug 26th, 2009
1

Re: malloc does not allocate beyond 65872

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.  
Team Colleague
Reputation Points: 5862
Solved Threads: 950
Posting Sage
Salem is offline Offline
7,164 posts
since Dec 2005

This thread is more than three months old

No one has posted to this discussion for at least three months. Please let old threads die and do not reply to them unless you feel you have something new and valuable to contribute that absolutely must be added to make the discussion complete. Otherwise, please start a new thread in this forum instead.
Message:
Previous Thread in C Forum Timeline: Input validation and Error handling in C?
Next Thread in C Forum Timeline: remove duplicates in a sorted array





About Us | Contact Us | Advertise | Acceptable Use Policy
Forum Index | Build Custom RSS Feed


Follow us on Twitter


© 2011 DaniWeb® LLC