ag@elgar.UUCP (Keith Gabryelski) (09/19/88)
[This should have gone out to the net any way. My uucico seems to be
barfing on this piece of mail (curious). I haven't the time to figure
what exactly is going on, so I punt.]
Date: 15 Sep 88 10:32:05 EDT (Thu)
From: ucsd!rutgers!bpa.bell-atl.com!lehi3b15!flash (Stephen Corbesero)
I just received Conf across the net, and compiled it. However, I get
a "Memory Fault -- core dumped" almost immediately. My machine is an
AT&T 3B15, running System V.2.1. I used sdb to try and track it down,
and it appears to be a call to malloc, which is called from mymalloc,
which is called from getrc in the initialization code.
Thanks for the bug report.
I looked into the situation will mymalloc(), the only thing that
looked remotely strange to me was:
In the file `confopts.c' there is a function `tcapstr()'
The line:
(void) strcpy(*var, tcapbuf);
Would be more reasonable if it was:
(void) cpystr(*var, tcapbuf, tmp-tcapbuf);
Without actually seeing the code, I really couldn't tell you for sure
this is the problem. If this does not work, consider sending me a a
stack trace with as much info as you can supply.
In any case, I'd like to hear if the above fixed your problem or not.
Pax, Keith
--
It took no computation, to dance to the rock 'n roll station.
[ Keith ] UUCP: {ucsd, cbosgd!crash, sdcsvax!crash, nosc!crash}!elgar!ag
[Gabryelski] INET: ag@elgar.cts.com ARPA: elgar!ag@ucsd.edumer6g@uvaarpa.virginia.edu (Marc E. Rouleau) (09/19/88)
Stephen Corbesero writes:
= I just received Conf across the net, and compiled it. However, I get
= a "Memory Fault -- core dumped" almost immediately. My machine is an
= AT&T 3B15, running System V.2.1. I used sdb to try and track it down,
= and it appears to be a call to malloc, which is called from mymalloc,
= which is called from getrc in the initialization code.
My AT&T 3B15 running V.2.1.1 did the same thing. Changing PAGESIZ in
config.h from 512 to 32 seemed to do the trick.
-- Marc Rouleau, University of Virginia Academic Computingwgh@Grumpy.UUCP (William G. Hutchison) (09/29/88)
In article <2@elgar.UUCP>, ag@elgar.UUCP (Keith Gabryelski) writes: > Date: 15 Sep 88 10:32:05 EDT (Thu) > From: ucsd!rutgers!bpa.bell-atl.com!lehi3b15!flash (Stephen Corbesero) > I just received Conf across the net, and compiled it. However, I get > a "Memory Fault -- core dumped" almost immediately. I compiled conf on a Unisys 7000/52 (CCI Tahoe) running SysV rel 2. I found that malloc was being called to allocate zero bytes: I did not have time to find out why. I changed the source so that malloc was only called to allocate a positive number of bytes (1 or more). With that fix, conf works fine. Perhaps the author can find the "root" cause (pun intended). Yr friendly neighborhood hacker: -- Bill Hutchison, DP Consultant rutgers!cbmvax!burdvax!Grumpy!wgh Unisys UNIX Portation Center "What one fool can do, another can!" P.O. Box 500, M.S. B121 Ancient Simian Proverb, quoted by Blue Bell, PA 19424 Sylvanus P. Thompson, in _Calculus Made Easy_
ag@elgar.UUCP (Keith Gabryelski) (09/30/88)
In article <359@Grumpy.UUCP> wgh@Grumpy.UUCP (William G. Hutchison) writes: >I compiled conf on a Unisys 7000/52 (CCI Tahoe) running SysV rel 2. >I found that malloc was being called to allocate zero bytes: I did not >have time to find out why. [...] With that fix, conf works fine. I didn't think mallocing zero bytes was a problem. It seemed reasonable to me to ask malloc() for a pointer that could be realloced and has no length (for initialization purposes). Actually, it doesn't seem to reasonable to me any more. Possibly a better move would be to initialize the pointer to NULL and have myrealloc() [a front end to realloc()] handle null pointers. Since myrealloc() already handles null pointers and I could only find one reference to mymalloc(0) [in confrots.c] this would be a piece 'o cake to fix. Pax, Keith -- It took no computation, to dance to the rock 'n roll station. [ Keith ] UUCP: {ucsd, cbosgd!crash, sdcsvax!crash, nosc!crash}!elgar!ag [Gabryelski] INET: ag@elgar.cts.com ARPA: elgar!ag@ucsd.edu