Re: PR/53998 CVS commit: src/sys/kern

[BERTRAND Joël <joel.bertrand%systella.fr@localhost>]

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,
        netbsd-bugs%netbsd.org@localhost
Cc: 
Subject: Re: PR/53998 CVS commit: src/sys/kern
Date: Fri, 22 Feb 2019 10:42:35 +0100

 	OK,
 
 	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
 --enable-final-encoding=UTF-8
 
 	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
 src/gestion_threads.c.
 
 	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.
 
 	Best regards,
 
 	JB