Re: [Lxr-dev] Further testing

[Jan-Benedict G. <jb...@lu...>]

On Sun, 2001-08-19 17:24:50 +0200, Jan-Benedict Glaw <jb...@lu...>
wrote in message <200...@lu...>:
> On Sun, 2001-08-19 23:40:42 +0900, Malcolm Box <ma...@br...>
> wrote in message <3B7...@br...>:
> > Jan-Benedict Glaw wrote:
> Seems I'm getting nearer:
> 
> Whenever I fetch a *file* (not a directory index) one "co" is opened,
> as well as a DB connection to fetch function names/variables/...
> As I think, these DB connections are not properly closed. So
> apache (aka mod_perl) keeps them opened (which is what you see as
> idle in transaction postres processes).

Well, nearly right. "co" isn't called (maybe it is, but there's
no zombie) for a directory but only for a file.

However, retrieving a directory opens a DB connection. I just
opened (recursively) all directories available in Linux v0.12.
It's nearly fine so far:

postgres  9505  0.0  0.3  8152  476 ?        S    15:24   0:00 /usr/lib/postgresql/bin/postmaster -D /var/lib/postgres/data
postgres 11567  0.0  1.8  8788 2360 ?        S    17:26   0:00  \_ postgres: www-data lxr-cvs [local] idle in transaction      
postgres 11571  0.0  1.8  8788 2352 ?        S    17:27   0:00  \_ postgres: www-data lxr-cvs [local] idle in transaction      
postgres 11577  0.0  1.8  8788 2352 ?        S    17:27   0:00  \_ postgres: www-data lxr-cvs [local] idle in transaction      
postgres 11597  0.0  1.8  8788 2356 ?        S    17:27   0:00  \_ postgres: www-data lxr-cvs [local] idle in transaction      
postgres 11613  0.0  1.8  8788 2356 ?        S    17:27   0:00  \_ postgres: www-data lxr-cvs [local] idle in transaction      
postgres 11618  0.0  1.8  8788 2356 ?        S    17:27   0:00  \_ postgres: www-data lxr-cvs [local] idle in transaction      
root     11558  0.0  2.3  4560 2956 ?        S    17:26   0:00 /usr/sbin/apache
www-data 11559  0.4  4.7  8332 6040 ?        S    17:26   0:01  \_ /usr/sbin/apache
www-data 11560  0.3  4.7  8344 6052 ?        S    17:26   0:01  \_ /usr/sbin/apache
www-data 11561  0.4  4.7  8340 6044 ?        S    17:26   0:01  \_ /usr/sbin/apache
www-data 11562  0.5  4.7  8372 6076 ?        S    17:26   0:01  \_ /usr/sbin/apache
www-data 11563  0.3  4.7  8328 6028 ?        S    17:26   0:01  \_ /usr/sbin/apache
www-data 11566  0.4  4.8  8420 6112 ?        S    17:26   0:01  \_ /usr/sbin/apache

That is: one apache master, six apache workers, and six opened
DB connections.

I restart apache after I opened ./linux/kernel/ with my browser.
Retrieving "exit.c":	One opened DB connection, one co zombie (as
			a child of apache), but the HTML page
			arrived completely
Retrieving "fork.c":	2nd DB connection is opened, 2nd apache
			worker process now owns a zombied "co",
			but page os okay.
Retr. "mktime.c":	3rd DB connect, 3rc apache worker has got
			a "co" zombie, page arrived successfully.
Retr. "panik.c":	4th DB, 4th zombie, OKed page
R "printk.c":		5th DB, 5th zombie, OKed page
R "sched.c":		6th DB, 6th zombie, OKed page. Note that by
			now *all* of my apache worker processes have
			a zombie attached to them and that (I think
			so) all of them own one DB connection.
			However, I can't prove that these DB
			connections don't belong to *one* worker
			only.
R "signal.c":		Things are stable. 6 DB connections, 6
			zombies. OKed page. I don't know where
			the expected 7th co zombie has gone
			to8-)
R "sys.c":		Everything is stable at "6". OKed page.

Now I go to fetch include files (from sys.c):
"#include <errno.h>":	Stable 6pack, OKed page
"# <linux/sched.h">:	dito
"# <linux/tty.h">:	dito
"# <asm/segment.h">:	dito
"# <sys/times.h">:	dito
"# <sys/utsname.h">:	dito
"# <sys/resource.h">:	dito	# I feel fooled...

Okay, I now directly enter the ./linux/include directory:

const.h:		dito
ctypeh:			dito
errno.h:		dito	# Feeling fooled again...

Now I enter the mapped asm directory:

Mapping direction: asm/ -> asm-noarch/ -> asm/

Index of ./linux/include/asm/ is okay.

io.h:			dito
memory.h:		dito
others:			okay at "the stable six", too

So, I've now changed Vesion to 0.10, but everything is fine now.
I don't understand that. (The "lib" line is right in place...).

Am I now to get happy (can't find any error) or not (there was
error and I didn't change anything)?

Well, I just remember... While seeing these errors, I've previously
./genxref'ed all single tags defined in my CVS tree. Now, no longer
seeing those errors, I've tested the --allversions switch. I'll
come along in some minutes with new tests:-)

MfG, JBG







-- 
Jan-Benedict Glaw . jb...@lu... . +49-172-7608481