Thread: [Lxr-dev] [ lxr-Bugs-455480 ] Diff. btwn. --allversions and --version=
Brought to you by:
ajlittoz
From: <no...@so...> - 2001-08-26 11:57:01
|
Bugs item #455480, was opened at 2001-08-26 04:56 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=390117&aid=455480&group_id=27350 Category: genxref Group: current cvs Status: Open Resolution: None Priority: 5 Submitted By: Jan-Benedict Glaw (jbglaw) Assigned to: Nobody/Anonymous (nobody) Summary: Diff. btwn. --allversions and --version= Initial Comment: There are these famous "LXR/xxx.pm not found" errors around. They seem to depend on how the source tree (my one is based on CVS and PostgreSQL) is indexed. Indexing it with --allversions is quite fine: I can browse the code without any problems. But indexing specific versions via --version=xxx (with xxx being a valid CVS tag) produces those "not found" errors afterwards. So it seems that genxref either fails to generate correct indexes for some given cvs tag, or "source" tries to get wrong releases from cvs/database... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=390117&aid=455480&group_id=27350 |
From: <no...@so...> - 2001-09-27 17:47:47
|
Bugs item #455480, was opened at 2001-08-26 04:56 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=390117&aid=455480&group_id=27350 Category: genxref Group: current cvs >Status: Pending Resolution: None Priority: 5 Submitted By: Jan-Benedict Glaw (jbglaw) >Assigned to: Peder O. Klingenberg (pok) Summary: Diff. btwn. --allversions and --version= Initial Comment: There are these famous "LXR/xxx.pm not found" errors around. They seem to depend on how the source tree (my one is based on CVS and PostgreSQL) is indexed. Indexing it with --allversions is quite fine: I can browse the code without any problems. But indexing specific versions via --version=xxx (with xxx being a valid CVS tag) produces those "not found" errors afterwards. So it seems that genxref either fails to generate correct indexes for some given cvs tag, or "source" tries to get wrong releases from cvs/database... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=390117&aid=455480&group_id=27350 |
From: Malcolm B. <ma...@br...> - 2001-09-27 14:37:13
|
In a bug report, Jan-Benedict wrote > There are these famous "LXR/xxx.pm not found" errors > around. > > They seem to depend on how the source tree (my one is > based > on CVS and PostgreSQL) is indexed. > > Indexing it with --allversions is quite fine: I can > browse the code > without any problems. But indexing specific versions > via > --version=xxx (with xxx being a valid CVS tag) produces > those > "not found" errors afterwards. So it seems that genxref > either > fails to generate correct indexes for some given cvs > tag, or > "source" tries to get wrong releases from > cvs/database... Are you still experiencing this problem? I can't see any reason why the state of the database would result in "not found" errors - it's perfectly possible to run lxr against an empty database, so I'm confused by this bug. Here's a few questions that may help nail it down. Firstly, what are the modules that are reported as "not found"? If you index with --allversions, and then specify a version that doesn't exist, do you get the same "not found" messages as with --version? Cheers, Malcolm |
From: Jan-Benedict G. <jb...@lu...> - 2001-09-27 20:31:45
|
On Thu, 2001-09-27 23:35:56 +0900, Malcolm Box <ma...@br....u= k> wrote in message <3BB...@br...>: > In a bug report, Jan-Benedict wrote >=20 > > There are these famous "LXR/xxx.pm not found" errors > > around. > >=20 > > They seem to depend on how the source tree (my one is > > based > > on CVS and PostgreSQL) is indexed. > > > > Indexing it with --allversions is quite fine: I can > > browse the code > > without any problems. But indexing specific versions > > via > > --version=3Dxxx (with xxx being a valid CVS tag) produces > > those > > "not found" errors afterwards. So it seems that genxref > > either > > fails to generate correct indexes for some given cvs > > tag, or > > "source" tries to get wrong releases from > > cvs/database... >=20 > Are you still experiencing this problem? =18I can't see any reason why > the state of the database would result in "not found" errors - it's > perfectly possible to run lxr against an empty database, so I'm confused > by this bug. Well, I did a new installation (from current CVS) just right now and here are my findings: - lxr.css is not there. I've commented out anything using it:-) - I indexed my CVS archive (using postgresql) version-by-version: for i in v_0_01 v_0_11 v_0_12 ...; do ./genxref --url=3Dhttp:/... --version=3D$i done Then I tried to access them via LXR: - It seems to not properly close connections to the DB server. After viewing a page, I would expect apach to no longer have any opened DB handles. But postgres thinks different about that: mirror:~# ps ax|grep post 17542 ? S 0:00 /usr/lib/postgresql/bin/postmaster -D /var/lib= /postgres/data 23455 ? S 0:04 postgres: www-data lxr-cvs [local] idle in tra= nsaction =20 23457 ? S 0:03 postgres: www-data lxr-cvs [local] idle in tra= nsaction =20 23459 ? S 0:02 postgres: www-data lxr-cvs [local] idle in tra= nsaction =20 23499 ? S 0:00 postgres: www-data lxr-cvs [local] idle in tra= nsaction =20 23521 ? S 0:01 postgres: www-data lxr-cvs [local] idle in tra= nsaction =20 23524 ? S 0:01 postgres: www-data lxr-cvs [local] idle in tra= nsaction =20 23751 pts/5 S 0:00 grep post - I again needed to include this mysterious "lib" line to source to make it work at all: use lib do { $0 =3D~ m{(.*)/} ? "$1/lib" : "lib" }; - Not having done --allversions yet, I am not capable of viewing that much pages. As the old behaviour was, after 6 pages (# of apache workers) I get the first "...not found..." error messages. - I missed to look for zombies... - I shut apache down and indexed with --allversions - Restated apache and I "feel" (TM) that getting pages is better, but not perfect. After some pages (but not that fast as previously), I got my "not found" error. Additionally, I find "co" zombies as being apache's childreen: mirror:~# ps ax|grep defun 23654 ? Z 0:00 [co <defunct>] 23684 ? Z 0:00 [co <defunct>] 23732 ? Z 0:00 [co <defunct>] 23787 pts/5 S 0:00 grep defun =09 > Here's a few questions that may help nail it down. Firstly, what are > the modules that are reported as "not found"? I only saw LXR/Lang/Generic.pm in those messages... =09 > If you index with --allversions, and then specify a version that doesn't > exist, do you get the same "not found" messages as with --version? If a version doesn't exist, I always get: The file /include/asm/memory.h does not exist. ** Warning: Unable to open /home/data/CVSROOT/linux//include/asm/memory.h,v =2E..which is perfectly okay (for a non-indexed version of that file). I have some other hint. I've got a very "special" construct in my lxr.conf: 'a' =3D> { 'name' =3D> 'Architecture', 'range' =3D> [qw(i386 alpha arm cris ia64 m68k mips mips64 parisc ppc p= pc64 s390 s390x sh sparc sparc64 um x86_64 noarch)], 'default' =3D> 'noarch' }, and 'maps' =3D> { '/include/asm-noarch/' =3D> '/include/asm/', '/include/asm[^\/]*/' =3D> '/include/asm-$a/', '/arch/[^\/]+/' =3D> '/arch/$a/', }, I've tested around and found this "table" (it's called a hash, isn't it?) internally gets processed in reverse order. So, IRL "/asm/" would get substituted by "/asm-noarch/" which is to be substituted again by "/asm/" having "noarch" the default (this is for old linux kernel which only had an /include/asm/ directory but not a *link* pointing to supported architecture's asm files... I tried to comment out all maps and to default to '' for architecture, but that didn't help: no files where found any longer. MfG, JBG --=20 Jan-Benedict Glaw . jb...@lu... . +49-172-7608481 |
From: Malcolm B. <ma...@br...> - 2001-09-28 03:16:01
Attachments:
lxr.css
|
Jan-Benedict Glaw wrote: >Well, I did a new installation (from current CVS) just right now >and here are my findings: > >- lxr.css is not there. I've commented out anything using it:-) > Sorry, I forgot to check in one of the new files from the CSS patch. I've also noticed that I didn't make the changes to the template files to make the HTML validate against 4.01 Transitional - I must have made them to my local copies. I'll update both tonight, in the meantime I've attached the lxr.css file. Malcolm |
From: Jan-Benedict G. <jb...@lu...> - 2001-09-27 20:45:08
|
On Thu, 2001-09-27 23:35:56 +0900, Malcolm Box <ma...@br....u= k> wrote in message <3BB...@br...>: > In a bug report, Jan-Benedict wrote [...] > Are you still experiencing this problem? =18I can't see any reason why > the state of the database would result in "not found" errors - it's > perfectly possible to run lxr against an empty database, so I'm confused > by this bug. Oh, while you mention this... Re-referencing everything leads to: disconnect(DBI::db=3DHASH(0x83ad134)) invalidates 1 \ active statement. Either destroy statement handles \ or call finish on them before disconnecting. at \ lib/LXR/Index/Postgres.pm line 279. for me:-[ I even think that this could be the "not found"-problem's source at all... Remember those stalled DB handles left in opened state after retreiving a page? I think that Apache struggles over them! Is there any error path that either beams you into another directory || leads to not closing a previously opened DB handle (or FileHandle in case of those 'co' zombies...)? MfG, JBG --=20 Jan-Benedict Glaw . jb...@lu... . +49-172-7608481 |