Thread: [Lxr-dev] Further testing
Brought to you by:
ajlittoz
From: Jan-Benedict G. <jb...@lu...> - 2001-08-19 13:45:41
|
Hi! I just continued testing current CVS version of lxr. I didn't find any unusual things any more. Even --allversions seems to run fine! So there's only that one issue with (not) searching for perl files in ./lib/ I wrote about yesterday^Wthis night. So it's close getting perfect:-) MfG, JBG -- Jan-Benedict Glaw . jb...@lu... . +49-172-7608481 |
From: Jan-Benedict G. <jb...@lu...> - 2001-08-19 13:59:03
|
On Sun, 2001-08-19 15:45:31 +0200, Jan-Benedict Glaw <jb...@lu...> wrote in message <200...@lu...>: > So it's close getting perfect:-) Oh, I was too fast:-( For those very old Linux kernels (v 0.01, 0.10, 0.11, 0.12) I've adden another "architecture", noarch. /asm-noarch/ gets mapped back to pure /asm/ because these old kernels had nothing else than i386 support. Loading pages sometimes gives me errors like ------------------------ first time loaded -------------------- Penguin Cross-Referencing Linux [ source navigation ] Linux/ include/ asm/ io.h [ diff markup ] [ identifier search ] [ freetext search ] [ file search ] Version: [ v_0_12 ] [ v_0_11 ] [ v_0_10 ] [ v_0_01 ] [ i386 ] [ alpha ] [ arm ] [ cris ] [ ia64 ] [ Architecture: m68k ] [ mips ] [ mips64 ] [ parisc ] [ ppc ] [ s390 ] [ s390x ] [ sh ] [ sparc ] [ sparc64 ] [ noarch ] qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq ** Fatal: Can't locate LXR/Lang/Generic.pm in @INC (@INC contains: / usr/local/lib/perl/5.6.1 /usr/local/share/perl/5.6.1 /usr/lib/perl5 / usr/share/perl5 /usr/lib/perl/5.6.1 /usr/share/perl/5.6.1 /usr/local/ lib/site_perl /usr/lib/perl5/5.6 /usr/lib/perl5/5.005 . /etc/apache/ /etc/apache/lib/perl) at (eval 20) line 3. ** Fatal: Can't locate object method "new" via package "LXR::Lang:: Generic" (perhaps you forgot to load "LXR::Lang::Generic"?) at (eval 21) line 1. ** Fatal: Unable to create LXR::Lang::Generic Lang object, at /home/ data/lxr-cvs/lib/LXR/Common.pm line 84. -------------------------------------------------------------------- Loading it once again gives: ----------------------- First Reload -------------------------------- Penguin Cross-Referencing Linux [ source navigation ] Linux/ include/ asm/ io.h [ diff markup ] [ identifier search ] [ freetext search ] [ file search ] Version: [ v_0_12 ] [ v_0_11 ] [ v_0_10 ] [ v_0_01 ] [ i386 ] [ alpha ] [ arm ] [ cris ] [ ia64 ] [ Architecture: m68k ] [ mips ] [ mips64 ] [ parisc ] [ ppc ] [ s390 ] [ s390x ] [ sh ] [ sparc ] [ sparc64 ] [ noarch ] qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq 1.1 www-data 001 ** Warning: DBD::Pg::st execute failed: PQsendQuer ** Warning: DBD::Pg::st fetchrow_array failed: no statement executing ** Warning: DBD::Pg::st execute failed: PQsendQuery() -- There is no c ** Warning: DBD::Pg::st fetchrow_array failed: no statement executing ** Warning: DBD::Pg::st execute failed: PQsendQuery() -- There is no c ** Warning: DBD::Pg::st fetchrow_array failed: no statement executing #define outb(value,port) \ 002 __asm__ ("outb %%al,%%dx"::"a" (value),"d"** Warni ** Warning: DBD::Pg::st fetchrow_array failed: no statement executing ** Warning: DBD::Pg::st execute failed: PQsendQuery() -- There is no c ** Warning: DBD::Pg::st fetchrow_array failed: no statement executing (port)) 003 004 005 #define inb(port) ({ \ 006 unsigned char _v; \ 007 __asm__ volatile ("inb %%dx,%%al":"=a" (_v):"d"** ** Warning: DBD::Pg::st fetchrow_array failed: no statement executing (port)); \ 008 _v; \ 009 }) 010 011 #define outb_p(value,port) \ 012 __asm__ ("outb %%al,%%dx\n" \ 013 "\tjmp 1f\n" \ 014 "1:\tjmp 1f\n" \ 015 "1:"::"a" (value),"d"** Warning: D ** Warning: DBD::Pg::st fetchrow_array failed: no statement executing (port)) 016 [...] --------------------------------------------------------------------- The third load then looks better: ------------------------ Second Reload ------------------------------- Penguin Cross-Referencing Linux [ source navigation ] Linux/ include/ asm/ io.h [ diff markup ] [ identifier search ] [ freetext search ] [ file search ] Version: [ v_0_12 ] [ v_0_11 ] [ v_0_10 ] [ v_0_01 ] [ i386 ] [ alpha ] [ arm ] [ cris ] [ ia64 ] [ Architecture: m68k ] [ mips ] [ mips64 ] [ parisc ] [ ppc ] [ s390 ] [ s390x ] [ sh ] [ sparc ] [ sparc64 ] [ noarch ] qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq 1.1 www-data 001 #define outb(value,port) \ 002 __asm__ ("outb %%al,%%dx"::"a" (value),"d" (port)) 003 004 005 #define inb(port) ({ \ 006 unsigned char _v; \ 007 __asm__ volatile ("inb %%dx,%%al":"=a" (_v):"d" (p 008 _v; \ 009 }) 010 011 #define outb_p(value,port) \ 012 __asm__ ("outb %%al,%%dx\n" \ 013 "\tjmp 1f\n" \ 014 "1:\tjmp 1f\n" \ 015 "1:"::"a" (value),"d" (port)) 016 017 #define inb_p(port) ({ \ 018 unsigned char _v; \ 019 __asm__ volatile ("inb %%dx,%%al\n" \ 020 "\tjmp 1f\n" \ 021 "1:\tjmp 1f\n" \ 022 "1:":"=a" (_v):"d" (port)); \ 023 _v; \ 024 }) qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq [ source navigation ] [ diff markup ] [ identifier search ] [ freetext qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq This page was automatically generated by the LXR HTML 3.2 engine. Checked! Arne Georg Gleditsch and Per Kristian Gjermshus qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq --------------------------------------------------------------------- Does anybody have some hint how to get the complete page just at the first shoot? MfG, JBG -- Jan-Benedict Glaw . jb...@lu... . +49-172-7608481 |
From: Jan-Benedict G. <jb...@lu...> - 2001-08-19 14:27:49
|
On Sun, 2001-08-19 15:58:57 +0200, Jan-Benedict Glaw <jb...@lu...> wrote in message <200...@lu...>: > On Sun, 2001-08-19 15:45:31 +0200, Jan-Benedict Glaw <jb...@lu...> > wrote in message <200...@lu...>: > > > So it's close getting perfect:-) > > Oh, I was too fast:-( > > For those very old Linux kernels (v 0.01, 0.10, 0.11, 0.12) I've > adden another "architecture", noarch. /asm-noarch/ gets mapped > back to pure /asm/ because these old kernels had nothing else > than i386 support. Loading pages sometimes gives me errors like [...] > qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq > 1.1 www-data 001 ** Warning: DBD::Pg::st execute failed: PQsendQuer > > ** Warning: DBD::Pg::st fetchrow_array failed: no statement executing > ** Warning: DBD::Pg::st execute failed: PQsendQuery() -- There is no c > ** Warning: DBD::Pg::st fetchrow_array failed: no statement executing > ** Warning: DBD::Pg::st execute failed: PQsendQuery() -- There is no c > ** Warning: DBD::Pg::st fetchrow_array failed: no statement executing Well, I think I've found some things... ps axwwwf: 8786 ? S 0:00 /usr/sbin/apache 8787 ? S 0:01 \_ /usr/sbin/apache 8788 ? S 0:02 \_ /usr/sbin/apache 11126 ? Z 0:00 | \_ [co <defunct>] 8789 ? S 0:04 \_ /usr/sbin/apache 11132 ? Z 0:00 | \_ [co <defunct>] 8790 ? S 0:02 \_ /usr/sbin/apache 11138 ? Z 0:00 | \_ [co <defunct>] 8791 ? S 0:02 \_ /usr/sbin/apache 11144 ? Z 0:00 | \_ [co <defunct>] 8800 ? S 0:05 \_ /usr/sbin/apache 11082 ? Z 0:00 \_ [co <defunct>] 9505 pts/0 S 0:00 /usr/lib/postgresql/bin/postmaster -D /var/lib/postgres/data 10872 pts/0 S 0:00 \_ postgres: www-data lxr-cvs [local] idle in transaction 10874 pts/0 S 0:00 \_ postgres: www-data lxr-cvs [local] idle in transaction MfG, JBG -- Jan-Benedict Glaw . jb...@lu... . +49-172-7608481 |
From: Malcolm B. <ma...@br...> - 2001-08-19 14:43:28
|
Jan-Benedict Glaw wrote: > Well, I think I've found some things... > > ps axwwwf: > > 8786 ? S 0:00 /usr/sbin/apache > 8787 ? S 0:01 \_ /usr/sbin/apache > 8788 ? S 0:02 \_ /usr/sbin/apache > 11126 ? Z 0:00 | \_ [co <defunct>] > 8789 ? S 0:04 \_ /usr/sbin/apache > 11132 ? Z 0:00 | \_ [co <defunct>] > 8790 ? S 0:02 \_ /usr/sbin/apache > 11138 ? Z 0:00 | \_ [co <defunct>] > 8791 ? S 0:02 \_ /usr/sbin/apache > 11144 ? Z 0:00 | \_ [co <defunct>] > 8800 ? S 0:05 \_ /usr/sbin/apache > 11082 ? Z 0:00 \_ [co <defunct>] > 9505 pts/0 S 0:00 /usr/lib/postgresql/bin/postmaster -D /var/lib/postgres/data > 10872 pts/0 S 0:00 \_ postgres: www-data lxr-cvs [local] idle in transaction > 10874 pts/0 S 0:00 \_ postgres: www-data lxr-cvs [local] idle in transaction So you're seeing idle postgres processes during a execution of "source"? I don't know enough about psql to know if this is normal, nor what sort of error this is. Do you have any clues? Malcolm |
From: Jan-Benedict G. <jb...@lu...> - 2001-08-19 15:11:55
|
On Sun, 2001-08-19 23:40:42 +0900, Malcolm Box <ma...@br...> wrote in message <3B7...@br...>: > Jan-Benedict Glaw wrote: > > 9505 pts/0 S 0:00 /usr/lib/postgresql/bin/postmaster -D /var/lib/postgres/data > > 10872 pts/0 S 0:00 \_ postgres: www-data lxr-cvs [local] idle in transaction > > 10874 pts/0 S 0:00 \_ postgres: www-data lxr-cvs [local] idle in transaction > > So you're seeing idle postgres processes during a execution of > "source"? I don't know enough about psql to know if this is normal, nor > what sort of error this is. Do you have any clues? If I remember correctly you can see this between sending a request and fetching the last resulting row. So you haven't fetched all the data. MfG, JBG -- Jan-Benedict Glaw . jb...@lu... . +49-172-7608481 |
From: Jan-Benedict G. <jb...@lu...> - 2001-08-19 15:15:45
|
On Sun, 2001-08-19 17:11: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: > > > 10874 pts/0 S 0:00 \_ postgres: www-data lxr-cvs [local] idle in transaction > > > > So you're seeing idle postgres processes during a execution of > > "source"? I don't know enough about psql to know if this is normal, nor > > what sort of error this is. Do you have any clues? > > If I remember correctly you can see this between sending a request > and fetching the last resulting row. So you haven't fetched all > the data. Testing some more lets me conclude that you see this if you only have an opened connection which served some data at any given time before. So this is a stale (once used, but not closed) DB handle on Perl's DBI side. MfG, JBG -- Jan-Benedict Glaw . jb...@lu... . +49-172-7608481 |
From: Jan-Benedict G. <jb...@lu...> - 2001-08-19 15:24:56
|
On Sun, 2001-08-19 23:40:42 +0900, Malcolm Box <ma...@br...> wrote in message <3B7...@br...>: > Jan-Benedict Glaw wrote: > > Well, I think I've found some things... > > > > ps axwwwf: > > > > 11144 ? Z 0:00 | \_ [co <defunct>] > > 8800 ? S 0:05 \_ /usr/sbin/apache > > 11082 ? Z 0:00 \_ [co <defunct>] > > 9505 pts/0 S 0:00 /usr/lib/postgresql/bin/postmaster -D /var/lib/postgres/data > > 10872 pts/0 S 0:00 \_ postgres: www-data lxr-cvs [local] idle in transaction > > 10874 pts/0 S 0:00 \_ postgres: www-data lxr-cvs [local] idle in transaction > > So you're seeing idle postgres processes during a execution of > "source"? I don't know enough about psql to know if this is normal, nor > what sort of error this is. Do you have any clues? 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). Further more, not finding libraries/modules (heck, what is it exactly called?) starts after retrieving more or equal pages (read: C files) from apache than there are apache child worker processes running. In apache, there's done some kind of round robin: Think of one master process (getting a request) and 6 workers (sending the requested material). The workers are handled in some kind of ring buffer. So after a /etc/init.d/apache restart you'll get some clean pages (as many as there are workers). Then, you'll hit an older apache worker which already has got some opened DB connectio. Crash. (Oh, yes, and there are all those zombie co's as well...) Something then closes these DB connections (I've not got any clue about this. It even might be that the apache master process detects some trouble and kills one of it's worker threads and restarts a new one). Those new threads are ready to feed *one* clean page again... MfG, JBG -- Jan-Benedict Glaw . jb...@lu... . +49-172-7608481 |
From: Jan-Benedict G. <jb...@lu...> - 2001-08-19 15:56:27
|
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 |
From: Jan-Benedict G. <jb...@lu...> - 2001-08-19 16:21:07
|
On Sun, 2001-08-19 17:56:23 +0200, Jan-Benedict Glaw <jb...@lu...> wrote in message <200...@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: Now it really seems so! Okay, after feeling fooled some times I can now easily produce this "lib/module/something not found" error! > 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:-) Well, it's always good to remember that you've changed something, even if you *thing* that "some minor change" wouldn't "affect anything". I wasn't able to hit this bug after ./genxref'ing the CVS archive with --allversions. I'm easily to hit it with only indexing the CVS repository in terms of single tags. I've now indexed all tags of interest and bingo: here it is: I'm in ./linux/ and just restarted apache (to get rid of all those zombies and DB connections): Req. ./kernel/: OK, 1 DB, 0 co zombies Req. exit.c: OK, 2 DB, 1 co Req. fork.c: OK, 3 DB, 2 co Req. mktime.c: OK, 4 DB, 3 co Req. panik.c: OK, 5 DB, 4 co Req. printk.c: OK, 6 DB, 5 co Req. sched.c: BROKEN, 6 DB, 5 co /* Not all workers used? */ Reload: OK, 6 DB, 5 co Req. signal.c: OK, 6 DB, 5 co Req. sys.c OK, 6 DB, 5 co Req. ./linux/include: OK, 6 DB, 5 co Req. a_out.h: OK, 6 DB, 5 co Req. const.h: BROKEN, 6 DB, 5 co Reload: OK, 6 DB, 5 co Req. ./asm/ OK Req. io.h OK Req. memory.h OK Req. segment.h BROKEN Reload: OK So there seems to be some difference between --allversions and for i in `cat ./cvs_tags`; do ./genxref --url="..." --version="$i" done MfG, JBG -- Jan-Benedict Glaw . jb...@lu... . +49-172-7608481 |
From: Malcolm B. <ma...@br...> - 2001-08-19 14:41:04
|
Jan-Benedict Glaw wrote: > For those very old Linux kernels (v 0.01, 0.10, 0.11, 0.12) I've > adden another "architecture", noarch. /asm-noarch/ gets mapped > back to pure /asm/ because these old kernels had nothing else > than i386 support. Loading pages sometimes gives me errors like > ** Fatal: Can't locate LXR/Lang/Generic.pm in @INC (@INC contains: / > usr/local/lib/perl/5.6.1 /usr/local/share/perl/5.6.1 /usr/lib/perl5 / > usr/share/perl5 /usr/lib/perl/5.6.1 /usr/share/perl/5.6.1 /usr/local/ > lib/site_perl /usr/lib/perl5/5.6 /usr/lib/perl5/5.005 . /etc/apache/ > /etc/apache/lib/perl) at (eval 20) line 3. > > ** Fatal: Can't locate object method "new" via package "LXR::Lang:: > Generic" (perhaps you forgot to load "LXR::Lang::Generic"?) at (eval > 21) line 1. > > ** Fatal: Unable to create LXR::Lang::Generic Lang object, at /home/ > data/lxr-cvs/lib/LXR/Common.pm line 84. This looks very much like the error that's caused by not being able to find/load a library. Was this error message created before/after you re-added the "lib" line? I've seen this message both with and without that line, and I have to say it confuses me, since I can't work out why the library is not found. <snip> > ** Warning: DBD::Pg::st fetchrow_array failed: no statement executing > > ** Warning: DBD::Pg::st execute failed: PQsendQuery() -- There is no c > > ** Warning: DBD::Pg::st fetchrow_array failed: no statement executing > > ** Warning: DBD::Pg::st execute failed: PQsendQuery() -- There is no c > > ** Warning: DBD::Pg::st fetchrow_array failed: no statement executing No idea about this one - though obviously it is now finding the library, which is bizarre. > The third load then looks better: > Does anybody have some hint how to get the complete page just at > the first shoot? Nope - these are the sort of problems that not finding the libraries seem to cause, but as you say, only on the first time through. As the scripts are running under mod_perl, perhaps the changes to @INC are being stored from invocation to invocation, but for some reason are not happening early enough to enable the loading on the first path. I'm afraid mod_perl/Perl gurus are going to be needed for this one - any takers? Malcolm |
From: Jan-Benedict G. <jb...@lu...> - 2001-08-19 15:10:25
|
On Sun, 2001-08-19 23:38:19 +0900, Malcolm Box <ma...@br...> wrote in message <3B7...@br...>: > Jan-Benedict Glaw wrote: > > ** Fatal: Can't locate LXR/Lang/Generic.pm in @INC (@INC contains: / > > usr/local/lib/perl/5.6.1 /usr/local/share/perl/5.6.1 /usr/lib/perl5 / > > usr/share/perl5 /usr/lib/perl/5.6.1 /usr/share/perl/5.6.1 /usr/local/ > > lib/site_perl /usr/lib/perl5/5.6 /usr/lib/perl5/5.005 . /etc/apache/ > > /etc/apache/lib/perl) at (eval 20) line 3. > > > > ** Fatal: Can't locate object method "new" via package "LXR::Lang:: > > Generic" (perhaps you forgot to load "LXR::Lang::Generic"?) at (eval > > 21) line 1. > > > > ** Fatal: Unable to create LXR::Lang::Generic Lang object, at /home/ > > data/lxr-cvs/lib/LXR/Common.pm line 84. > > This looks very much like the error that's caused by not being able to > find/load a library. Was this error message created before/after you > re-added the "lib" line? I see these in both cases. > I've seen this message both with and without that line, and I have to > say it confuses me, since I can't work out why the library is not found. Well... "Can't locate xxx.om in @INC..." All pathes in this "@INC" thing seem to be somewhat correct. There's only one path which may vary: ".". Is there any way to get the current working directory? > > > > ** Warning: DBD::Pg::st execute failed: PQsendQuery() -- There is no c > > > > ** Warning: DBD::Pg::st fetchrow_array failed: no statement executing > > > > ** Warning: DBD::Pg::st execute failed: PQsendQuery() -- There is no c > > > > ** Warning: DBD::Pg::st fetchrow_array failed: no statement executing > > No idea about this one - though obviously it is now finding the library, > which is bizarre. Two possibilities: - It might be an error which occures because Perl failed to load some of its modules/libs/whatever ("@INC" ...) - One request was send (through an persistent connection), but not all results where fetched. Then, one had send another requese... I feel it's the firs possibility of those two:-) > > The third load then looks better: > > Does anybody have some hint how to get the complete page just at > > the first shoot? > Nope - these are the sort of problems that not finding the libraries > seem to cause, but as you say, only on the first time through. As the > scripts are running under mod_perl, perhaps the changes to @INC are > being stored from invocation to invocation, but for some reason are not > happening early enough to enable the loading on the first path. Don't think so. I feel it's because it wasn't able to co some file... (Or to check it out only partially: I've got zombie co's...) > I'm afraid mod_perl/Perl gurus are going to be needed for this one - any > takers? Well... What is the easiest way to achive this: When exec'ing come helper command (rcsdiff, co, ...), first write a log into /var/log/lxr.log containing the full invocation command as well as the current working directory. MfG, JBG -- Jan-Benedict Glaw . jb...@lu... . +49-172-7608481 |