*BSD News Article 10305


Return to BSD News archive

Received: by minnie.vk1xwt.ampr.org with NNTP
	id AA7677 ; Mon, 25 Jan 93 12:19:51 EST
Path: sserve!manuel.anu.edu.au!munnari.oz.au!yarra-glen.aaii.oz.au!msi.umn.edu!umn.edu!spool.mu.edu!uunet!ccut!news.u-tokyo.ac.jp!yayoi!tansei1!mhiroshi
From: mhiroshi@tansei.cc.u-tokyo.ac.jp (H. Murakami)
Newsgroups: comp.unix.bsd,fj.os.386bsd
Subject: [386bsd] Please, Oh please help my hang up trouble.
Message-ID: <3980@tansei1.tansei.cc.u-tokyo.ac.jp>
Date: 24 Jan 93 00:14:40 GMT
Sender: news@tansei.cc.u-tokyo.ac.jp
Followup-To: comp.unix.bsd
Organization: Hokkaido Univ. However I am subject to tansei for JUNET.
Lines: 269

To: comp.unix.bsd,fj.os.386bsd
Subject: Please help my hang up trouble.

This is my two month long troubled problem.

I have 
	486DX33MHz, AMI BIOS,
	16MB of main memory,
	1.6GB Fujitsu SCSI-2 DISK with AHA1542B board.

I allocates the swap area for 386bsd0.1 with Terry's patches
and also other many patches including the new new scsi drivers.

I have been able to recompile all the
sources associated with the 386bsd systems and other many many tools:
{tex, gcc2.3.3, ...}.

I have allocated the just one giga bytes of swap area on the
disk partition /dev/sd0b 

The standard configuration of the kernel 
permits 32MB of data and stack areas per process.
(I think the julian new new scci driver does nothing wrong with this
problem.)

The enclosed test program "testvm.c" is just a toy program which will
try to allocate 1MB size of memory region and then writes the 
data on is repeated until the malloc fails.

I found, if I run the program as only one process, I rarely have
problem. However, if I run that program, in many either by many
login process, or by putting many process as the background jobs.
The enclosed shell scripts "test3.sh" and "test6.sh" is the sample.

The symptom is, the system's COMPLETE death by hang up.
Surely, the system goes heavier when too many paging or swapping
starts after all the real memory was used. But hanging is a
different thing. It's a wonderful life:
(for example, nothing will happen for more than an hour,
no response of the terminal,.. no disk updates, etc.)


To experience the example of the hang up,
	% cc testvm.c -o a.out
and then
	% sh test3.sh
or
	% sh test6.sh

Sometimes, your run may finish without the hang up.
But in many trial, it will.

Since I have a giga bytes of swap area, even 6 processes is run,
32MB times 6 = less than 200MB is needed at most, is within the
size of the swap area.


The test3.sh tries to run three idential processes, and test6.sh
tries to run six. The more processes, the possiblity of the problem
grows.

I initially thought it is the problem in the malloc function
coming with 386BDS0.1, so I also tried with the GNU's malloc routines.
Surely the average time to the hang up became longer with GNU's
malloc, but the chance of hang up did not vanished.

I now suspects that there is someplace in the kernel routines
probably related with the extension of the stack frame,
does not made properly.

Before, I go to increase the size of the virtual space size of the
kernel by changing the parameters in vm_param.h or any place,
the source of this trouble must be removed.

Please, help me !

	Hiroshi Murakami
	hiroshi@teine.chem2.hokudai.ac.jp
	mhiroshi@tansei.cc.u-tokyo.ac.jp

I have a dream,.. someday the 386bsd become a system of no bug...


# This is a shell archive.  Save it in a file, remove anything before
# this line, and then unpack it by entering "sh file".  Note, it may
# create directories; files and directories will be owned by you and
# have default permissions.
#
# This archive contains:
#
#	README
#	test3.sh
#	test6.sh
#	testvm.c
#
echo x - README
sed 's/^X//' >README << 'END-of-README'
X
XThis is my two month long troubled problem.
X
XI have 
X	486DX33MHz, AMI BIOS,
X	16MB of main memory,
X	1.6GB Fujitsu SCSI-2 DISK with AHA1542B board.
X
XI allocates the swap area for 386bsd0.1 with Terry's patches
Xand also other many patches including the new new scsi drivers.
X
XI have been able to recompile all the
Xsources associated with the 386bsd systems and other many many tools:
X{tex, gcc2.3.3, ...}.
X
XI have allocated the just one giga bytes of swap area on the
Xdisk partition /dev/sd0b 
X
XThe standard configuration of the kernel 
Xpermits 32MB of data and stack areas per process.
X(I think the julian new new scci driver does nothing wrong with this
Xproblem.)
X
XThe enclosed test program "testvm.c" is just a toy program which will
Xtry to allocate 1MB size of memory region and then writes the 
Xdata on is repeated until the malloc fails.
X
XI found, if I run the program as only one process, I rarely have
Xproblem. However, if I run that program, in many either by many
Xlogin process, or by putting many process as the background jobs.
XThe enclosed shell scripts "test3.sh" and "test6.sh" is the sample.
X
XThe symptom is, the system's COMPLETE death by hang up.
XSurely, the system goes heavier when too many paging or swapping
Xstarts after all the real memory was used. But hanging is a
Xdifferent thing. It's a wonderful life:
X(for example, nothing will happen for more than an hour,
Xno response of the terminal,.. no disk updates, etc.)
X
X
XTo experience the example of the hang up,
X	% cc testvm.c -o a.out
Xand then
X	% sh test3.sh
Xor
X	% sh test6.sh
X
XSometimes, your run may finish without the hang up.
XBut in many trial, it will.
X
XSince I have a giga bytes of swap area, even 6 processes is run,
X32MB times 6 = less than 200MB is needed at most, is within the
Xsize of the swap area.
X
X
XThe test3.sh tries to run three idential processes, and test6.sh
Xtries to run six. The more processes, the possiblity of the problem
Xgrows.
X
XI initially thought it is the problem in the malloc function
Xcoming with 386BDS0.1, so I also tried with the GNU's malloc routines.
XSurely the average time to the hang up became longer with GNU's
Xmalloc, but the chance of hang up did not vanished.
X
XI now suspects that there is someplace in the kernel routines
Xprobably related with the extension of the stack frame,
Xdoes not made properly.
X
XBefore, I go to increase the size of the virtual space size of the
Xkernel by changing the parameters in vm_param.h or any place,
Xthe source of this trouble must be removed.
X
XPlease, help me !
X
X	Hiroshi Murakami
X	hiroshi@teine.chem2.hokudai.ac.jp
X	mhiroshi@tansei.cc.u-tokyo.ac.jp
X
XI have a dream,.. someday the 386bsd become a system of no bug...
X
END-of-README
echo x - test3.sh
sed 's/^X//' >test3.sh << 'END-of-test3.sh'
Xa.out &
Xa.out &
Xa.out &
END-of-test3.sh
echo x - test6.sh
sed 's/^X//' >test6.sh << 'END-of-test6.sh'
Xa.out &
Xa.out &
Xa.out &
Xa.out &
Xa.out &
Xa.out &
END-of-test6.sh
echo x - testvm.c
sed 's/^X//' >testvm.c << 'END-of-testvm.c'
X/* THE BEGINNING OF THIS TEST PROGRAM. */
X
X/*#define QUICK /* */
X/*******************************************
X*                                          *
X*       Malloc dead-lock test program.     *
X*                                          *
X*******************************************/
X
X#define TYPE    int
X#define MEGA    (1024*1024)
X
X#define SIZE (1000*MEGA) /* Size of total allocation limits in bytes. */
X                         /* Note, the actual allocation size is determined
X                            when the malloc's failure of allocation.  */
X
X#ifndef CHUNK_SIZE
X# define CHUNK_SIZE     (MEGA-4) /* size of allocation unit in bytes. */
X#endif
X
X#define NB (SIZE/CHUNK_SIZE)
X
X/*#define WAIT sleep(10) /* DO SLEEP */
X/*#define WAIT sync() /* DO SYNC */
X#define WAIT /* DO NOTHING. */
X
X#include <stdio.h>
X#include <stdlib.h>
X#include <unistd.h>
X
Xpid_t getpid(void), pid;
Xchar *sbrk(int);
X
Xmain(void)
X{
X        int i, j;
X        TYPE *(a[NB]);
X
X        pid = getpid();
X        fprintf(stderr, "%4u: chunk_size=%d, nb=%d\n", 
X                pid, CHUNK_SIZE, NB);
X
X        sleep(5);
X        for(i=0;i<NB;i++) {
X                WAIT;
X                a[i] = (TYPE*) malloc(CHUNK_SIZE);
X                if(a[i]==(TYPE*)0) 
X                        break;
X                fprintf(stdout, "%4u: block %d allocated. break %x\n", 
X                        pid, i, (int)sbrk(0));
X                WAIT;
X#ifndef QUICK
X                for(j=0;j<CHUNK_SIZE/sizeof(TYPE);j++)
X                        (a[i])[j] = (TYPE)j;
X#else /* QUICK */
X                for(j=0;j<CHUNK_SIZE/sizeof(TYPE);j+=1024)
X                        (a[i])[j] = (TYPE)j;
X#endif
X        }
X
X        fprintf(stdout, "%4u: No more allocation.\n", pid);
X        for(j=0;j<i;j++) {
X                fprintf(stdout, "%4u: block %d freed.\n", pid, j);
X                free(a[j]);
X                WAIT;
X        }
X
X        fprintf(stderr,"%4u: Finished with block %d\n", pid, i-1);
X        exit(0);
X}
X/* THE END OF THIS TEST PROGRAM. */
END-of-testvm.c
exit