From: WadeR AT img DOT seagatesoftware DOT com (Wade Richards) Subject: RE: malloc() question.. 17 Nov 1997 17:32:59 -0800 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: "'Keetnet AT wilmington DOT net'" Cc: "'gnu-win32 AT cygnus DOT com'" Hi, Greg. It looks like you've hit one of the hardest sort of bugs to debug: a memory corruption bug. More specifically, a memory over-run. To help you find this sort of thing yourself, here are the clues: 1) GPF inside "malloc". 2) adding 16 to all your malloc calls helped a little (but the problem still exists). In simple terms, what is most likely happening is that you are writing to some memory that you didn't allocate, just past the end of the memory that you did allocate. In the computer's memory (the "heap"), the run-time library keeps pointers and "stuff" in the memory that you aren't using, so that it can keep track of what is in use and what's available. Some of those pointers are right at the end of the memory you've allocated. If you allocate 10 bytes from malloc, and then you copy "this is a long string to cause a problem" into that 10 byte space, you will corrupt the data that malloc needs to know what is free. The copy will probably work, the rest of your code will seem to work fine, but the next time you call malloc(), free(), realloc(), or any other memory function, that's when the GPF will occur. So, the thing to do is read over your code, looking for places where you might be writing more data into a buffer than you've allocated space for. One other thing you can do is put lots of calls to "heapcheck()" (or whatever the function that checks the heap for validity is on your system) in your code, and stop as soon as one fails. This way you know that the problem occurred between the last successful heapcheck and the first failed one. --- Wade PS: The advice "add 16 to all malloc calls" is probably the WORSE advice you could have taken. It will not solve your problem, it will just make it harder to hide. Remove those extra 16 before you try everything else. Remember: you should know exactly how much memory you will need for each allocation. If you are adding some "fudge factor", then you are simply guessing. >On 14 Nov 97 at 7:11, Keet / Foxbird wrote: >> the line that caused the problem. The baffling thing about this line is >> that it's the line that calls 'malloc'? It takes the length of a string, >> This line is called many, many times before this, and works fine each time, >> but it seems to trip up after a certain number of calls. I've asked a few >> people what to do, and some told me it was some kinda of memory pointer >> problem, and that I should add 16 to all the malloc calls I make. Did that, >> and it progresses quite a bit farther but it then it drops out on another >> malloc call. So now I'm lost as to what to do. Can anyone offer any help? >> >> - Greg Neujahr >> keetnet AT wilmington DOT net > > - For help on using this list (especially unsubscribing), send a message to "gnu-win32-request AT cygnus DOT com" with one line of text: "help".