HDTenEightyP/NetNews huggingface dataset:
From: terry@cs.weber.edu (A Wizard of Earth C)
Newsgroups: comp.unix.wizards
Subject: Re: malloc() and free ()
Date: 8 Oct 92 22:11:12 GMT
Article-I.D.: fcom.1992Oct8.221112.3879
Organization: Weber State University  (Ogden, UT)

In article <1992Oct8.160459.25205@kocrsv01.delcoelect.com> c23rrj@kocrsv01.delcoelect.com (Rajnish Joshi) writes:
>
>Hi,
>
>In article <1992Sep8.171947@is.morgan.com> Scott Cairns asks a question
>about malloc() and free(). In article <18k0ocINNjt5@early-bird.think.com>
>Barry Margolin replies to Scott's question with the following answer (and I 
>quote):
>
>  " Yes, in most Unix implementations of free(3), the memory is not returned to
>    the OS. Future malloc(3) calls by that process may reuse 
>    this freed memory."
>
>
>
>MY Question: Since no followup (flames) for the above statement was received,
>              is the above statement TRUE?
>
>     If the above statement is TRUE then why am I able to allocate the entire
>       memory to my application, free half of it back, and make the application
>       wait for some input and still run some other application 
>       that mallocs () ?

1)	It's true.
2)	Calls to sbrk() in the implementation of "malloc()" are to grow the
	image size.
3)	Freeing doesn't call sbrk() with a negative number to "put the
	memory back" -- most sbrk() implementations would puke if it did.
4)	You don't get the memory REALLY unless you write to it, marking
	the page dirty.
5)	Even if you REALLY have the memory doesn't mean it isn't from
	swap instead of physical memory.
6)	The concept of "entire memory" applies to physical memory plus
	swap, not just physical memory.

An exercise:  calloc() memory in chunks until calloc() returns NULL.  Then
go to sleep.  Run another program to do the same thing.  Note that users
are frequently set a limit on the mount of memory they can allocate (~4Meg
on most BSD derived systems) and you may need to exhaust this limit multipe
times before the actual physical memory plus swap is exhausted.  When this
happens, expect console messages and an irate admin bashing your brains in.


					Terry Lambert
					terry@icarus.weber.edu
					terry_lambert@novell.com
---
Any opinions in this posting are my own and not those of my present
or previous employers.
-- 
-------------------------------------------------------------------------------
                                        "I have an 8 user poetic license" - me
 Get the 386bsd FAQ from agate.berkeley.edu:/pub/386BSD/386bsd-0.1/unofficial
-------------------------------------------------------------------------------
From: smee@bristol.ac.uk (Paul Smee)
Newsgroups: comp.unix.wizards
Subject: Re: Disk leakage?
Date: 9 Oct 92 16:41:41 GMT
Reply-To: P.Smee@bristol.ac.uk (Paul Smee)
Organization: University of Bristol

In article <1b1r86INNock@early-bird.think.com> barmar@think.com (Barry Margolin) writes:
>I don't think a zombie process can have open files.  The only state that a
>zombie process has is it process table entry, which holds the information
>that the parent may extract using getrusage(2).

No one here, including better folk than I, really has much clue what
zombies can and can't do.  Useful info, thanks.

>I've never heard of any of the standard daemons or system processes doing
>stuff like this, either.

We're running some pretty weird (and occasionally UK specific, eg NIFTP)
stuff...

>You could try killing and restarting processes one by one, to see when the
>disk space becomes available.

I'm sort of holding that idea in reserve, as most of the things this
beast is running are pretty mission-critical over our entire service.
(It's our mail hub, our primary IP domain nameserver, one of our
'uk.ac.bristol' NRS local registries (more or less the UK colored-book
protocols' analog to DNS), and so on.  Also, most importantly, our news
machine. :-)  All but news have 'backup' points, so we could live
without bits of it for a bit, but the cut-over from primary to backup
for some of these services does nasty user-visible things.  Still, I
may get desperate enough.  Thanks for the thoughts...

-- 
Paul Smee, Computing Service, University of Bristol, Bristol BS8 1UD, UK
 P.Smee@bristol.ac.uk - ..!uunet!uknet!bsmail!p.smee - Tel +44 272 303132
Newsgroups: comp.unix.wizards
From: oleg@csufres.CSUFresno.EDU (Oleg Kibirev)
Subject: Re: fork() and forget..How?
Organization: California State University, Fresno
Date: Fri, 9 Oct 1992 22:40:23 GMT
X-Posted-From: csufres.cs.csufresno.edu
NNTP-Posting-Host: sol.ctr.columbia.edu

In article <1992Oct9.130646.7250@progress.com> gus@progress.COM (Gus Bjorklund) writes:
>subbarao@tex.Princeton.EDU (Kartik Subbarao) writes:
>
>>In article <1992Oct07.194020.14527@ctms.gwinnett.com> kirk@ctms.gwinnett.com (R. Kirk Waterhouse) writes:
>
>>Processes generate SIGCHLD when they die. What you want here is to install a 
>>signal handler that waits for the children as and when they die:
>
>># include <signal.h>
>
>>waiter()
>>{
>>	union wait st;
>>	while (wait3(&st, WNOHANG, NULL) > 0);
>>}
>
>>in your process that fork()s, stick this in:
>
>>signal(SIGCHLD, waiter);
>
>>So, you need not insert any wait's in your main code, and you can service 
>>requests from the pipe without waiting for the previous one to finish. When
>>the processes die, the interrupt routine waiter() will be called to clean
>>up shop, and you'll be returned back to your regularly scheduled
>>programming.
>
>You also should make sure that when the parent exits, it wait()'s
>for any children which have not yet finished.

No, it doesn't really need to do this. Orphane children will be picked by
init (PID 1) that will happily discard their exit status.

Oleg



Newsgroups: comp.unix.wizards
From: ol@infopro.spb.su (Oleg Girko)
Subject: Re: fork() and forget..How?
Organization: Novintech-Infopro ltd., St.Petersburg, Russia
X-Newsreader: Tin 1.2 PL4
Date: Sat, 10 Oct 1992 13:48:39 GMT

Hello from Russia!

kirk@ctms.gwinnett.com (R. Kirk Waterhouse) writes:

| I am looking for a way to fork() a process and forget about it.

If you use System V - like Unix, you can use:

	signal (SIGCLD, SIG_IGN);

This causes child processes do not produce zombies after exit()ing.

Oleg Girko.              _   ,
ol@infopro.spb.su      /  ) /
ol@jet.riga.lv        (_ / (__
Newsgroups: comp.unix.wizards,rec.games.mud.admin
From: chupchup@ferkel.ucsb.edu (Robert Earl)
Subject: Re: micro or terminal to Unix
Followup-To: rec.games.mud.admin
Organization: (EVIL!)
Date: Fri, 16 Oct 1992 10:19:54 GMT

terry@cs.weber.edu (A Wizard of Earth C) writes:

| In article <1992Oct15.203140.4304@bnr.ca> johnh@nnshh127.uucp (John Hawkins) writes:
| >I have tried using telnet packages ->ncsa etc. however it seems
| >that the pc sends every single key press in a packet of ~80 some bytes.
| >Note:packet size and info from using etherpeek software....

| Use a modern telnet client and a telnetd that will negotiate "line mode"...
| this way you will get a packet per line rather than a packet per character
| (unless the read is for a single character, you have "smart" pty's, and
| you hack telnetd to take mode control messages from the pty).

| "Single character I/O" is my biggest gripe with "MUSH" and "MUCK" and "M"...
| software, since the authors either don't know how to negotiate options or
| simply refuse to code it up.  Packets of one character piss me off.

Well, I guess it's my fault for TELNET options processing not being in
TinyMUCK.  But most popular telnet clients on Unix will fall back to
linemode when talking to a mud like this.  On other operating systems
they won't, and the users who don't have clients there are quite
stuck, things like editing keys and character echo are nonexistent.

I would seriously consider putting option negotiation stuff into the
interface, but it may be more trouble than it's worth, since 98% of
people on muds use a client of some sort; tinyfugue, VT, tinytalk.el,
tinywar, all these know enough to buffer up one line at a time before
sending it along.

In summary, there is hardly ever any character-at-a-time input going
on when someone connects to a mud.  But one thing that pissed ME off
about the MUCK interface was the way an output line was sent with one
write(), then the "\r\n" was sent in another write(), which ended up
in twice as many packets per line, cos usually the "\r\n" would find
itself in a packet all alone.

Followups to a less wizardly group, please.  :-)

-- 
robert earl          |
rearl@ucsd.edu       | "I got a bottle of tequila, baby, who needs friends?"
rearl@piggy.ucsb.edu |   --Johnette Napolitano, Concrete Blonde
Newsgroups: comp.unix.wizards
From: hartnett@glas.rtsg.mot.com (Ger Hartnett)
Subject: Questions about BSD Sockets (EADDRINUSE, ENOBUFS, ETIMEDOUT).
Organization: Motorola Cellular Infrastructure Div., Cork, Ireland.
Date: Fri, 16 Oct 1992 15:19:21 GMT


Hi there,

I have some questions about the application interface to BSD Sockets
(TCP/IP), satisfactory answers to which I have not been able to find
in "UNIX Network Programming" (Stevens).



Occasionaly I get (errno) EADDRINUSE from the connect() call. 

1. Is there a bind() inside connect?
2. Can this fail because some other process binds the same port
   just before my process?
3. What is the correct evasive action to take in this case, retry the
   connect()? 

Occasionaly I get (errno) ENOBUFS from the write() call. The man pages
I have mention ENOBUFS in reference to send(). 

1. Does this mean kernel buffer space is exhausted?
2. If so is the buffer space for the machine/process/socket?
3. What is the correct evasive action to take in this case? Treat it
   like a EWOULDBLOCK and try again later?


Occasionaly I get (errno) ETIMEDOUT from read(), on a socket with
KEEPALIVE on. Stevens says this should go to so_error but I am picking
it up in errno also.

1. Is is correct to get ETIMEDOUT in errno?

2. Is the other end of the connection definitly dead?  

3. What is the correct evasive action to take in this case? Can I
   treat this like an ECONNRESET?


Is there any book with more detail than Stevens on BSD Socket
programming?

If you have any answers to these questions please contact me. Posting
or emails are fine.

Thanks in advance,
gerH.

--
		 +----------------------------------------------------+
		 | Ger Hartnett,				      |
		 |      PaperNet:  Motorola Ireland Ltd.              |
		 |		   Cellular Infrastructure Division   |
    _____  __  __|		   Mahon Industrial Estate            |
   / ___/ / /_/ /|		   Cork, Republic of Ireland.         |
  / / _  / __  / |						      |
 / /_/ // / / /  |	InterNet:  hartnett@glas.rtsg.mot.com         |
/_____//_/ /_/   |      UUCP: 	   ...motcid!glas!hartnett            |
		 | 	Voice: 	   +353 21 357 101                    |
		 |     	FAX:   	   +353 21 357 635                    |
		 +----------------------------------------------------+
From: Perry_Hutchison.Portland@xerox.com
Newsgroups: comp.unix.wizards
Subject: Re: init output to console - why not?
Date: 7 Oct 92 22:59:40 GMT

>	I was just wondering the other day if there really actually *is*
> a good reason why init doesn't attach its output and error to /dev/console
> during autoboots ...

I think init wants to avoid getting the console (or anything) as its
controlling terminal, because it doesn't want it or its children (like
inetd) to receive signals when someone hits ^C while using the console
as a login terminal.

Given the following comments in /etc/rc, it would appear that this has
somehow been fixed in SunOS 4.1.2.

#! /bin/sh -
#
#       @(#)rc 1.45 90/08/08 SMI; from UCB 4.3
#
# The rc sh gets the console.  All commands are by
# default protected from tty signals (i.e. are not interruptable).
# Interrupts can be enabled by proceeding any command line with "intr".
# Console redirection is no longer needed.
Newsgroups: comp.unix.wizards
From: a2mp@loki.cc.pdx.edu (Michael Perrone)
Newsgroups: comp.unix.wizards
Subject: Re: fork() and not forget
Date: 15 Oct 92 17:22:25 GMT

[...]
> # include <signal.h>
> 
> waiter()
> {
> 	union wait st;
> 	while (wait3(&st, WNOHANG, NULL) > 0);
> }
> 
> in your process that fork()s, stick this in:
> 
> signal(SIGCHLD, waiter);
> 
> So, you need not insert any wait's in your main code, and you can service
[...]

Well, this is nitpicking... But chances are the original poster doesn't have
the wait3 call available to him. He'll probably have to do something like
this in his signal handler:

 .....
 int *status_ptr; /* dead child's status */
 ....
      while (waitpid(-1, status_ptr, WNOHANG) > 0)
.....

 You can use plain old wait() (without the while) in your signal handler, 
 but the advantage of using a non blocking call is clear - if another child
 dies while your in the signal handler, you'll catch it; otherwise you'll
 miss the signal because you were in the handler.

-- Michael Perrone --  System Software Programmer -- Portland State University
a4mp@loki.cc.pdx.edu
From: c23rrj@kocrsv01.delcoelect.com (Rajnish Joshi)
Newsgroups: comp.unix.wizards
Subject: malloc() and free ()
Date: 8 Oct 92 16:04:59 GMT
Organization: Delco Electronics Corp.
Originator: c23rrj@kocrsw04


Hi,

In article <1992Sep8.171947@is.morgan.com> Scott Cairns asks a question
about malloc() and free(). In article <18k0ocINNjt5@early-bird.think.com>
Barry Margolin replies to Scott's question with the following answer (and I 
quote):

  " Yes, in most Unix implementations of free(3), the memory is not returned to
    the OS. Future malloc(3) calls by that process may reuse 
    this freed memory."



MY Question: Since no followup (flames) for the above statement was received,
              is the above statement TRUE?

     If the above statement is TRUE then why am I able to allocate the entire
       memory to my application, free half of it back, and make the application
       wait for some input and still run some other application 
       that mallocs () ?

Please send direct email as well, if possible.


Thanks a lot.
RAJ
-- 
**************************************************************************
  Rajnish Joshi              Phone: (317) 451-0643   GM Line: 8-322-0643
  Software Technology         UUCP: deaes!c23rrj
  Delco Electronics Corp.    Internet: c23rrj@kocrsv01.delcoelect.com
From: brnstnd@nyu.edu (D. J. Bernstein)
Newsgroups: comp.unix.wizards
Subject: Re: fork() and forget..How?
Date: 11 Oct 92 05:22:31 GMT
Organization: IR

What a shame that fork() doesn't return a file descriptor...

---Dan
Newsgroups: comp.unix.wizards
From: alan@nabeth.enet.dec.com (Alan Rollow - Alan's Home for Wayward Tumbleweeds.)
Subject: Re: DAMN: deleted all my files; saved partition tho'
Keywords: rm bonehead
Reply-To: alan@nabeth.enet.dec.com (Alan Rollow - Alan's Home for Wayward Tumbleweeds.)
Organization: Digital Equipment Corporation
Date: Wed, 7 Oct 1992 22:25:14 GMT


In article <BvrK78.Hvq@csug.cs.reading.ac.uk>, mdr@bjorn (Doc Chaos) writes:
>
>Yeah, bonehead at the wheel, typed 'rm *' into wrong window.
>Unfortunately the files were never backed up - they weren't
>really important, but I'd like them back, if possible.  It 
>would take me at least two days to get them all again, and 
>what the hell, it could be a useful exercise.
>
>What I did was to immediately 'dd' the whole partition containing
>the "deleted" files onto a tape; total size ~118 Meg; deleted
>files about 100 taking up 30M.  The system is a SPARC running
>SunOS 4.1.1.  I guess I've got to muck around with inodes or summat
>but don't really know where to start.
>
Odds are Sun clears all the inode when they free it.  So, even if
you can find the inodes that were associated with the files there
won't be block address left.  There are some solutions.

Theme - Brute force.  Examine every block and save the ones that
look like your data.  Then put the pieces of the puzzle back 
together.

Variation #1 - Optimize.  The file system is arranged in block that
are probably either 8 KB or 4 KB long.  Rather than examine disk
blocks, examine file system blocks.

Variation #2 - Optimize some more.  Since Sun is probably still using
something that looks a lot like a Berkeley fast file system, each
cylinder group should have a bit map or something to indicate which
blocks are free.  Only examine those.  The implementation of this
is left as the exercise to the reader.  Clue:

The free map appears to be the data structure cg_free in the
description of a cylinder group.  Once you can find the cylinder
group blocks for each cylinder group, this should be fairly easy
to examine.  The macro cgtod() might be of particular interest.
Also keep in mind that many things are counted in file system
fragments as opposed to disk blocks.  You might have to look
around a bit to make sure you have the cylinder group block.

Variation #3 - And more.  Once you get the point that you can examine
things a cylinder group at a time, you may be able to take advantage
of the fact that you can make a good guess where the files were.  Files
tend to get allocated in the same cylinder group as the directory
they are in.  If you still have the directory, you can find what
cylinder group it is in and start there.
 
>AtDhVaAnNkCsE
>
>mark
>
>--
>m.robinson@reading.ac.uk
>
>"I really like the jacket but the sleeves are much too long" - Lemmy
>
--
Alan Rollow				alan@nabeth.cxo.dec.com

Newsgroups: comp.unix.wizards
From: dkeisen@leland.Stanford.EDU (Dave Eisen)
Subject: Re: can I plock() another process?
Organization: Sequoia Peripherals, Inc.
Date: Fri, 16 Oct 92 05:47:00 GMT

In article <1992Oct16.035346.10115@fcom.cc.utah.edu> terry@cs.weber.edu (A Wizard of Earth C) writes:
>In article <1992Oct15.193953.17108@Princeton.EDU> jsm@shade.Princeton.EDU (John Scott McCauley Jr.) writes:
>>Hello,
>>	I am having trouble with CPU hogs swapping out interactive processes
>>(csh, xterm, vtwm).  I suppose I could add a plock(TLOCK) in every process
>>I don't want swapped  out, but that would require recompiling a lot of
>>code plus locking too much memory would be bad.
>
>Or you could set the "sticky" bit on the executables.

The sticky bit has nothing to do with keeping a running process
in RAM. If it does anything (and I know of systems where it is
ignored, SCO Xenix for instance), it keeps the text image of the
executable on swap even after the program exits. This would not
help the poster whose *problem* is that the executable image is
on swap.



-- 
Dave Eisen    dkeisen@leland.Stanford.EDU   Sequoia Peripherals: (415) 967-5644
      Incompetent amateurs have given prostitution a bad name.
        --- Camille Paglia in "Madonna II: Venus of the Radio Waves"
Newsgroups: comp.unix.wizards
From: khm@cs.brown.edu (Katie Mohrfeld)
Subject: RPC and memory management
Organization: Brown University Department of Computer Science
Date: Tue, 13 Oct 1992 22:07:54 GMT



I'd like to use RPC (remote procedure calls) with one constraint.  
On the client side, I need for the RPC library routines to use my own 
memory management (malloc/free) subsystem.  Any suggestions?  
Is there a more appropriate newgroup for this question?

Thanks,
Katie

-------------------------------------------------------------------------------
Katie H. Mohrfeld   			Brown University Computer Science
Box 1910				khm@cs.brown.edu
Brown University			khm@browncs.bitnet
Newsgroups: comp.unix.wizards
From: john@chance.gts.org (John R MacMillan)
Subject: Re: malloc() and free ()
Organization: $HOME
Date: Wed, 14 Oct 1992 02:53:00 GMT

|3)	Freeing doesn't call sbrk() with a negative number to "put the
|	memory back" -- most sbrk() implementations would puke if it did.

Most sbrk() implementations I've seen will take a negative number; I
think SVID requires it (I don't have a copy handy).  Certainly the
SVR2 and SVR3 manuals I do have handy document it as working.

What sbrk() implementations will puke?
From: OLIVOTTO%ITNCISCA.bitnet@icineca.cineca.it (OUT, OUT - YOU'LL NOT FEEL THE FALL-OUT...)
Newsgroups: comp.unix.wizards
Subject: (From: IN%"Unix-Wizards@BRL.MIL") Solaris v1.0 Question
Date: 9 Oct 92 21:52:44 GMT

Greetings.

I'm trying to build various applications on a Tatung workstation
running Solaris 1.0 (SunOS 4.1.2), but I'm no expert and I'm having a
couple of problems:

(1) Just about everything I build generates the following error
    message in make:

    ld: Undefined symbol
       __Q_get_rp_rd
       _dlopen
       _dlclose
       _dlsym
       _nl_langinfo
    *** Error code 2

    Sometimes, surprisingly, the executable will run anyway, but ususally not.

(2) I've been told that there are alternate libraries to get this version of
    the OS to use DNS running on another machine, but I haven't been able to
    get any pointers to the right libs (I've tried on ftp.uu.net).

Thanks for any help. Please cc: to me if your responses go to the list, and
sorry if these are FAQs or SAQs (stupid-%## questions?).

--
Jim (moore@srv3130.ncsc.navy.mil)

And Saint Attila raised the Holy Hand Grenade up on high saying, "Oh Lord,
Bless this thy Holy Hand Grenade, and with it smash our enemies to tiny bits."
Newsgroups: comp.unix.wizards
From: bam@jutland.ColumbiaSC.NCR.COM (Bo Muldbak)
Subject: Re: fork() and forget..How? (Letting init do the dirty work)
Keywords: fork() wait() getpid() getppid()
Reply-To: Bo.Muldbak@ColumbiaSC.NCR.COM
Organization: NCR Corporation, MCPD Columbia SC.
Date: Mon, 12 Oct 92 10:06:04 GMT

In article <569@alden.UUCP>, sgr@alden.UUCP (Stan Ryckman) writes:
|> In article <1992Oct07.194020.14527@ctms.gwinnett.com>
|> kirk@ctms.gwinnett.com (R. Kirk Waterhouse) writes:
|> >
|> Instead, I recommend the following, which I have used with much success:
|>      PARENT: fork() then wait() for death of CHILD, then go back to
|> business
|>      CHILD:  fork() then exit() immediately
|>      GRANDCHILD:  run the program you really want to run.
|> Now the grandchild has no parent, and init will clean it up when
|> it (the grandchild) finishes.  Signal catching is not required, and "ps"
|> will show you what you expect for other purposes (except PPID will be 1
|> for the grandchild).  It costs an extra fork(), but leaves things
|> "cleaner."

Too much dirty work for init, and not necessary at all.

By inserting 

	signal(SIGCHLD, SIG_IGN);

you tell Unix itself, that you are you do not want to know about your
children
and they will be cleaned up automagically. They won't be saved  at all.

This has already been done by Kirk (original poster) and works just fine.

	Regards
		BAM 
-- 
//// Bo Asbjorn Muldbak              // Email:  Bo.Muldbak@ColumbiaSC.NCR.COM
/
/// Support & Deployment            // Phone :  +1 (803) 791-6871           
//
// NCR Corporation, MCPD-Columbia  // Telefax:  +1 (803) 739-7371          
///
/ Opinions stated are my own. They do not represent my employer or others.
////
From: f_cnnghamjk@ccsvax.sfasu.edu
Newsgroups: comp.unix.wizards
Subject: rtf->ascii script needed
Date: 10 Oct 92 15:04:41 CST
Organization: Stephen F. Austin State University


Can someone point me to a unix script that will translate rich text format into
plain ascii while retaining (at least some of) the formatting?
Please respond by e-mail.
 
Thanks.
 
Randomly, Kelly Cunningham
<deviate@lipschitz.sfasu.edu><f_cnnghamjk@ccsvax.sfasu.edu><jkellyc@tenet.edu>
    NeXTMail (encouraged)          VMS Mail (tolerated)     Pine (beats mail)
"There is no reason for any individual to have a computer in their home."
                    Ken Olson, President and visionary, Digital Equipment,1977