From: hfernandes AT geocities DOT com (Fernandes, Hilton) Subject: Re: malloc() question.. 15 Nov 1997 09:12:25 -0800 Message-ID: <199711151639.IAA27749.cygnus.gnu-win32@geocities.com> References: <3 DOT 0 DOT 32 DOT 19971114071055 DOT 007a4100 AT wilmington DOT net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT To: Keet / Foxbird , gnu-win32 AT cygnus DOT com Cc: "Fernandes, Hilton" On 14 Nov 97 at 7:11, Keet / Foxbird wrote: > > I've recently made some additions and changes to a program of mine, which > filters out certain sets of characters (IE: ^01^ ) and turns them into ANSI > escape sequences for color. Needless to say it's for a telnet server type > application. The only problem is, that it seems to crash at a certain spot > every time (this spot can vary depending on the settings). I've gone > through and looked at debug code, and scanned over all the source and found > 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, > adds a few to it, mallocs the memory, and then assigns a string into it. > 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 Hi! You haven't told us what's the specific problem. So let's guess: either you have a pure malloc() bug, or malloc() is working, but returns a null pointer. BTW, you'd better check for them. Since the null pointer is a more probable (and easier :-) alternative, let's think about it. AFAIK, there are two motives for that: either there's not enough free memory, or there is but it's badly fragmented. In the former case, you probably got what people call memory leakage: you simply forgot to release the memory you've allocated. The latter is more interesting: memory fragmentation means that there are lots of free memory blocks, but they're not big enough to satisfy your demand. An alternative reason to memory leakage it is that you simply don't have enough memory to run your app. Nowadays, with huge memory sizes and virtual memory, that shouldn't be the problem. To solve a memory leakage bug, you need to match each memory allocation with its corresponding release. The memory fragmentation problem may have several alternative solutions. An easy one is to allocate memory in blocks whose size is the upper multiple of an adequate number. I mean, if the number you chose is 16, then when instead of allocating 18 bytes, you allocate 32 bytes, since 32 is the upper multiple of 16. However, if you must allocate 48 bytes, then you allocate 48, since 48 is an integral multiple of 16. The idea of a upper multiple of 16 can be summarized by the C formula: upper_mult = 16 * ((orig_chunk / 16) + ((orig_chunk % 16) == 0)); The problem is that 16 is not the best universal number to base this scheme. It depends on the application you have and on the storage allocator. If you really detect that memory fragmentation is your problem, you have to try some numbers. 16 was a good number in DOS times, when the DOS allocator had a bug related to this number. (Now that we have full 32 bits operating systems, that shouldn't be a problem. :-) But be generous with that number. Remember that the higher number, the greatest the memory chunks available when memory is badly fragmented. I hope that helps. Regards, ++Hilton ---- Hilton Fernandes hfernandes AT geocities DOT com http://www.geocities.com/SiliconValley/Lakes/5657 URLs and help on C++ programming and Object-Oriented Design - 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".