gorpong@telxon (Gordon C. Galligher) (02/11/90)
Lately I have been having a nasty problem crop up, and it has become much more blatent lately. I am running programs and all of a sudden I get a Memory Fault, Core Dumped message. At first I thought it had to do with not having enough memory, but I have 4 Meg. and I'm not running hardly any processes. An example is a program I wrote (unrm, will be out in comp.sources.unix soon) which makes some malloc() calls. If I am root, and I attempt to allocate 524 bytes it fails. It doesn't return from the malloc() call, it fails IN the malloc and dumps core. If I am a general user I do not have this problem. Can anyone out there give me some sort of clue as to what is happening? I am running ISC 386/ix 2.0.1 w/4 MB ram, and 75Mb. hard drive. Please e-mail and I will post if there is sufficient interest. -- Gordon. Gordon C. Galligher <|> ..!uunet!telxon!gorpong <|> telxon!gorpong@uunet.uu.net Telxon Corporation <|> Akron, Ohio, 44313 <|> "I would advise yas ta keep dialin' Oxmyx" - Spock (216) 867-3700 (3512)<|> _A Piece of the Action_
cpcahil@virtech.uucp (Conor P. Cahill) (02/12/90)
In article <454@telxon.UUCP> gorpong@telxon (Gordon C. Galligher) writes: >a Memory Fault, Core Dumped message. At first I thought it had to do with >not having enough memory, but I have 4 Meg. and I'm not running hardly >any processes. A memory fault/core dump is not caused by the system having too little memory, in fact, virtual memory stuff should allow you to have lots of 4 meg programs on your 4 meg system (provided you have the swap space). Memory faults come from an abuse of the memory architecture of your program. This is most often caused by an invalid pointer or by running beyond the end of array (to the end of memory, or just far enough to trash a nearby pointer). > An example is a program I wrote (unrm, will be out in >comp.sources.unix soon) which makes some malloc() calls. If I am root, >and I attempt to allocate 524 bytes it fails. It doesn't return from the I hope Rich sees this and sends you back the program. You should never release a program that generates a core dump under any circumstances (if possible). Use the debugger to determine where your problem is. As a side note, I posted a malloc() debugging library that can be used to assist in the debugging of these kinds of problems to alt.sources about 2 weeks ago. I will be making a few more modifications based upon feedback and then posting it to comp.sources.unix or comp.sources.misc. If you would like a copy now, send me a message. -- +-----------------------------------------------------------------------+ | Conor P. Cahill uunet!virtech!cpcahil 703-430-9247 ! | Virtual Technologies Inc., P. O. Box 876, Sterling, VA 22170 | +-----------------------------------------------------------------------+
gorpong@telxon.UUCP (Gordon C. Galligher) (02/22/90)
A while back (I don't know how long) I posted an RFH (Request For HEEEELP) on this newsgroup about malloc() causing a memory fault and core dump on Interactive Systems Corporation's 386/ix 2.0.1 and I received a couple of responses which solved the problem. The symptom, to repeat myself, occurs on large (over 12K) programs requesting memory via the malloc() call. It was entirely inconsistent and it happened as root and whomever else. If you link the code with the -lmalloc option the problem goes away! This causes the linkage of the /lib/libmalloc.a file rather than the standard malloc() call in the libc.a file. My thanks for all who responded, and I greatly appreciate your help!! -- Gordon. -- Gordon C. Galligher <|> ..!uunet!telxon!gorpong <|> telxon!gorpong@uunet.uu.net Telxon Corporation <|> "I am attempting, ma'am, to make a mnemonic memory Akron, Ohio, 44313 <|> circuit out of stone knives and bearskins" - Spock (216) 867-3700 (3512)<|> _City on the Edge of Forever_
cpcahil@virtech.uucp (Conor P. Cahill) (02/24/90)
In article <469@telxon.UUCP> gorpong@telxon.UUCP (Gordon C. Galligher) writes: >A while back (I don't know how long) I posted an RFH (Request For HEEEELP) >on this newsgroup about malloc() causing a memory fault and core dump on >Interactive Systems Corporation's 386/ix 2.0.1 and I received a couple of >responses which solved the problem. The symptom, to repeat myself, occurs >on large (over 12K) programs requesting memory via the malloc() call. It was >entirely inconsistent and it happened as root and whomever else. If you >link the code with the -lmalloc option the problem goes away! This causes >the linkage of the /lib/libmalloc.a file rather than the standard malloc() >call in the libc.a file. I would be very leery about using the program. I don't think you actually solved the problem, just hid it. You should use the standard malloc functions and track down the problem that is probably in your code. I say that the problem is probably in your code because there are hundreds of programs on the system that use the libc.a malloc without any problems. The correct way to fix this problem is to track down the cause of the memory fault in your code. A 12K program is not a very large program and should be somewhat easy to debug. -- +-----------------------------------------------------------------------+ | Conor P. Cahill uunet!virtech!cpcahil 703-430-9247 ! | Virtual Technologies Inc., P. O. Box 876, Sterling, VA 22170 | +-----------------------------------------------------------------------+