home *** CD-ROM | disk | FTP | other *** search
- Xref: sparky comp.unix.bsd:11751 fj.os.386bsd:319
- Path: sparky!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
-
-