[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: PR/53998 CVS commit: src/sys/kern
The following reply was made to PR kern/53998; it has been noted by GNATS.
From: =?UTF-8?Q?BERTRAND_Jo=c3=abl?= <joel.bertrand%systella.fr@localhost>
To: gnats-bugs%NetBSD.org@localhost, kern-bug-people%netbsd.org@localhost, gnats-admin%netbsd.org@localhost,
Subject: Re: PR/53998 CVS commit: src/sys/kern
Date: Fri, 22 Feb 2019 10:42:35 +0100
I have uploaded test program on fermat.systella.fr (anonymous ftp).
Please note that this server does not run NetBSD but OpenVMS 7.3 and
don't forget to use BIN keyword before trying to download tarball.
Two files :
- RPL2-CURRENT.TGZ (script language)
- TEST-SCHWARZ.RPL (program written in RPL/2)
To build RPL/2, you must have gcc (I use gcc version 8.2.0 from pkgsrc)
with gfortran and g++, bash, automake, autoconf, libtool, uuencode,
patch and gmake. Untar tarball. Last operation will create rpl subdirectory.
In rpl directory, run autogen.sh. You can now create another directory
(for example ../build) to run configure script :
../rpl/configure --disable-motif --disable-rplcas
configure script takes a long time. Without --prefix option, program
will be installed in /usr/local (you can install RPL where you want, but
you have to fix she-bang in test-schwarz.rpl).
When configure is done, run gmake and gmake install (not BSD make).
Make takes a long time also as it builds some libraries that are not
installed by default on several operating systems. Now, you can run
test-schwarz.rpl. You have to wait until error occurs (often, between
10000 and 40000 threads...). This program tries to run two threads
(instruction SPAWN), and only two in parallel (with of course, main
thread). Each thread evaluates "echo test" (in SYSEVAL instruction, not
with system() but with fork() and execve()). SPAWN instruction starts
its child thread in lancement_thread() function (src/gestion_threads.c).
Faulty semaphore is created line 80 and destroyed line 1053. Of course,
I have verified that sem_destroy() is called and returns without error.
First error always comes from sem_init().
By default, rpl will print a message like:
LAST ERROR: Unknown error: 4294967295
ERROR 2001 AT librpl_lancement_thread() FROM gestion_threads-conv.c LINE 86
[21624-124346313330688] librpl_lancement_thread() from
gestion_threads-conv.c at line 86: BACKTRACE only defined in glibc
when error occurs. In this case, error was set line 86 of
Please note that it could be a memory leak somewhere in RPL/2. But
valgrind (on Linux) doesn't show any memory leak and I have run the same
test script during several days without any trouble (more than 3E6
threads) on both Linux (amd64) and Solaris (sparc).
I have seen another bug that could be related to this one. Sometimes,
when I have debugged this program, RPL/2 aborts directly line 322 of
src/rpl.c (it's the same semaphore, but created for main thread). Only
one solution : reboot NetBSD. I suppose sem_destroy() doesn't really
destroy semaphore or kernel doesn't free associated memory even if all
processes that access to this semaphore are terminated.
Main Index |
Thread Index |