Thread: [Lxr-dev] Re: /bin/true as a zombie
Brought to you by:
ajlittoz
From: Jan-Benedict G. <jb...@lu...> - 2001-07-30 16:32:18
|
On Mon, Jul 30, 2001 at 01:34:03PM +0200, Peder O. Klingenberg wrote: > > Is there any solutiion to avoid the zombie or to fetch the SIGCHLD and > > to wait() for it? Personally, I don't have any clue about Perl so > > I cannot fix it myself:-( > > Hopefully, this is fixed in the current CVS tree. > > By the way, you are aware of the move to sourceforge? There's some > new mailing lists and a new CVS repository. See > http://sourceforge.net/projects/lxr/. Well, I've checked the current CVS version. It fails. Configuration uses Postgres in conjunction with CVS (as I mentioned before). The current CVS version cannot ./genxref my sources. It only prints two lines: www-data@mirror:/home/data/lxr-cvs$ ./genxref --url="http://mirror.microdata-pos.de/lxr-cvs" --version="jbglaw_0_13" *** / jbglaw_0_13 ### / jbglaw_0_13 "jbglaw_0_13" is a tag. Tryin' to get files (read: HTML made-up sources) from it fails, too: The directory /home/data/CVSROOT/linux// does not exist. ** Warning: Unable to open /home/data/CVSROOT/linux// Of course, everything *is* in place:-) strace'ing it shows that LXR stat()s all files in the given directory, but doesn't actually do something. Do you know what I could do wrong? MfG, JBG |
From: <pe...@kl...> - 2001-07-31 07:41:01
|
Jan-Benedict Glaw <jb...@lu...> writes: > Well, I've checked the current CVS version. It fails. Strange. > Configuration uses Postgres in conjunction with CVS (as I mentioned > before). This is what I use as well. No problems here (well, not this kind of problems anyway). > The current CVS version cannot ./genxref my sources. It only prints > two lines: > www-data@mirror:/home/data/lxr-cvs$ ./genxref --url="http://mirror.microdata-pos.de/lxr-cvs" --version="jbglaw_0_13" > *** / jbglaw_0_13 > ### / jbglaw_0_13 > > "jbglaw_0_13" is a tag. I always index all versions. Could you try that as well, and see if it makes a difference? > Tryin' to get files (read: HTML made-up sources) from it fails, too: > > The directory /home/data/CVSROOT/linux// does not exist. > ** Warning: Unable to open /home/data/CVSROOT/linux// > > Of course, everything *is* in place:-) And readable for the webserver? > Do you know what I could do wrong? No, not really. It's obvious that genxref never recurses down directories like it's supposed to. Which means that CVS.pm->getdir somehow fails. I haven't touched that part of CVS.pm, so I don't think _I've_ broken it. That doesn't mean it's not broken :) Could you try to replace line 220 in CVS.pm with this: opendir($DIRH, $real) || die "opendir: $!"; And see if that changes anything when you run genxref? If genxref exits with an errormessage "opendir: ..." could you post it? Thanks. ...Peder... -- Cogito ergo panta rei. |
From: Jan-Benedict G. <jb...@lu...> - 2001-07-31 07:54:55
|
On Tue, Jul 31, 2001 at 09:34:12AM +0200, Peder O. Klingenberg wrote: > Jan-Benedict Glaw <jb...@lu...> writes: > > The current CVS version cannot ./genxref my sources. It only prints > > two lines: > > www-data@mirror:/home/data/lxr-cvs$ ./genxref --url="http://mirror.microdata-pos.de/lxr-cvs" --version="jbglaw_0_13" > > *** / jbglaw_0_13 > > ### / jbglaw_0_13 > > > > "jbglaw_0_13" is a tag. > > I always index all versions. Could you try that as well, and see if > it makes a difference? The CVS repository contains very early Linux kernels. Tags are "v_0_01", "v_0_10", "v_0_11", "v_0_12", "jbglaw_0_13". Doing "allversions" results in indexing head: www-data@mirror:/home/data/lxr-cvs$ ./genxref --url="http://mirror.microdata-pos.de/lxr-cvs" --allversions [...] ### /Makefile head disconnect(DBI::db=HASH(0x83a7a30)) invalidates 1 active statement. Either destroy statement handles or call finish on them before disconnecting. at lib//LXR/Index/Postgres.pm line 272. www-data@mirror:/home/data/lxr-cvs$ This was the 2nd run over the tree. It doesn't see the other tags:-( > > Tryin' to get files (read: HTML made-up sources) from it fails, too: > > > > The directory /home/data/CVSROOT/linux// does not exist. > > ** Warning: Unable to open /home/data/CVSROOT/linux// > > > > Of course, everything *is* in place:-) > > And readable for the webserver? Yes. Another copy of LXR (that one from the CVS tree on cvs.ping.uio.no) running on the same source tree(but from another directory with its own config etc.) behaves just fine with it:-) > > Do you know what I could do wrong? > > No, not really. It's obvious that genxref never recurses down > directories like it's supposed to. Which means that CVS.pm->getdir > somehow fails. I haven't touched that part of CVS.pm, so I don't > think _I've_ broken it. That doesn't mean it's not broken :) > > Could you try to replace line 220 in CVS.pm with this: > > opendir($DIRH, $real) || die "opendir: $!"; > > And see if that changes anything when you run genxref? If genxref > exits with an errormessage "opendir: ..." could you post it? It doesn't exit ungracefully. Just like above (with cancelling one active statement by closing the DB handle too early). > Cogito ergo panta rei. Why do you mux latin and greek(sp?) ? :-) MfG, JBG |
From: <pe...@kl...> - 2001-07-31 08:57:37
|
Jan-Benedict Glaw <jb...@lu...> writes: > Doing "allversions" results in indexing head: Ugh. There was a change in genxref recently that tidied up a great deal, but unfortunately left 'allversions' utterly broken, despite the log comment that it made allversions work. That "fix" assumed that versions are uniform throughout the tree. That is usually not the case in a CVS tree, of course. I don't know what, if anything, was wrong with allversions in the old code for plaintext files. The previous version (1.18) of genxref did this in a more convoluted and less obvious, but also less broken way (for CVS trees). Could you try --allversions with that version of genxref? It's available from <http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/~checkout~/lxr/lxr/genxref?rev=1.18&content-type=text/plain>, and I think thats the same version as in the old ping CVS tree. > disconnect(DBI::db=HASH(0x83a7a30)) invalidates 1 active statement. Either destroy statement handles or call finish on them before disconnecting. at lib//LXR/Index/Postgres.pm line 272. This is an unrelated, but nevertheless irritating bug. > Yes. Another copy of LXR (that one from the CVS tree on cvs.ping.uio.no) > running on the same source tree(but from another directory with its > own config etc.) behaves just fine with it:-) weird. > It doesn't exit ungracefully. Just like above (with cancelling one > active statement by closing the DB handle too early). Ok. Revert that change, then. If the old version of genxref works with allversions, could you try it with just your specific version? If that does not work, we'll have to do some more debugging of CVS.pm. And I don't think genxref explains why you're having trouble browsing, so that must be a separate issue. > > Cogito ergo panta rei. > > Why do you mux latin and greek(sp?) ? :-) Why not? :) With a bit of goodwill, it reads "I think, therefore everything is in flux". In norwegian, "everything is in flux" is also an expression of confusion, which is my usual state of mind when I'm thinking. Besides, it's a bit confusing mixing latin and greek, Descartes an Heraklit. I must admit it's not mine, it's originally reputed to be the answer of a poor, confused student on a philosophy exam. But I think it's funny none the less. :) ...Peder... -- Cogito ergo panta rei. |
From: Jan-Benedict G. <jb...@lu...> - 2001-07-31 09:46:56
|
On Tue, Jul 31, 2001 at 10:57:30AM +0200, Peder O. Klingenberg wrote: > Jan-Benedict Glaw <jb...@lu...> writes: > and less obvious, but also less broken way (for CVS trees). Could you > try --allversions with that version of genxref? It's available from > <http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/~checkout~/lxr/lxr/genxref?rev=1.18&content-type=text/plain>, > and I think thats the same version as in the old ping CVS tree. - I've reverted the change to ./lib/LXR/CVS.pm - Checked out the above version og genxref - Result: - This version also *only* tries to index head - It seems to handle some things wrong: [...] ### /lib/wait.c --- /lib/wait.c head 1.2 /lib/wait.c was already referenced ### /lib/write.c --- /lib/write.c head 1.2 /lib/write.c was already referenced ### /mm/ ### /mm/RCS/ ### /mm/Makefile co: /home/data/CVSROOT/linux//mm/Makefile,v: branch number 0 too low co: /home/data/CVSROOT/linux//mm/Makefile,v: branch number 0 too low co: /home/data/CVSROOT/linux//mm/Makefile,v: branch number 0 too low co: /home/data/CVSROOT/linux//mm/Makefile,v: branch number 0 too low co: /home/data/CVSROOT/linux//mm/Makefile,v: branch number 0 too low co: /home/data/CVSROOT/linux//mm/Makefile,v: branch number 0 too low ### /mm/memory.c --- /mm/memory.c head 1.4 /mm/memory.c was already referenced ### /mm/page.s [...] > > disconnect(DBI::db=HASH(0x83a7a30)) invalidates 1 active statement. Either destroy statement handles or call finish on them before disconnecting. at lib//LXR/Index/Postgres.pm line 272. > > This is an unrelated, but nevertheless irritating bug. Which is also triggered with the older CVS version of gnexref you mentioned above. I've also tried the old copy of ping's genxref version. It triggers the "branch number 0 too low" bug also > > Yes. Another copy of LXR (that one from the CVS tree on cvs.ping.uio.no) > > running on the same source tree(but from another directory with its > > own config etc.) behaves just fine with it:-) > > weird. If it could help you, I'd package my complete LXR installation ( functional and non-functional as well) and send it to you... > > It doesn't exit ungracefully. Just like above (with cancelling one > > active statement by closing the DB handle too early). My CVS tree is also not that large (~1.5MB) uncompressed... > And I don't think genxref explains why you're having trouble > browsing, so that must be a separate issue. I'm unsure. Those oloder versions show up this "branch 0 too low" thing I could not associate to any usage of CVS I ever had when accessing it by hand... MFG, JBG |
From: <pe...@kl...> - 2001-07-31 10:51:15
|
Jan-Benedict Glaw <jb...@lu...> writes: > [...] > ### /lib/wait.c > --- /lib/wait.c head 1.2 > /lib/wait.c was already referenced > ### /lib/write.c > --- /lib/write.c head 1.2 > /lib/write.c was already referenced Did you empty the database before running genxref? Otherwise you may have stuff lying around in the tables that makes genxref think you already indexed these files. > ### /mm/Makefile > co: /home/data/CVSROOT/linux//mm/Makefile,v: branch number 0 too low > co: /home/data/CVSROOT/linux//mm/Makefile,v: branch number 0 too low > co: /home/data/CVSROOT/linux//mm/Makefile,v: branch number 0 too low > co: /home/data/CVSROOT/linux//mm/Makefile,v: branch number 0 too low > co: /home/data/CVSROOT/linux//mm/Makefile,v: branch number 0 too low > co: /home/data/CVSROOT/linux//mm/Makefile,v: branch number 0 too low Hm. It gets as far as trying to check out the file, but seems to somehow get confused over which version to check out. Trying six times would indicate that it's trying to check out six different versions. Or something. > Which is also triggered with the older CVS version of gnexref you mentioned > above. Yep. It's a bug in the database interface libraries. > I've also tried the old copy of ping's genxref version. It triggers the > "branch number 0 too low" bug also Yes, it should, as that message is coming from CVS.pm. > If it could help you, I'd package my complete LXR installation ( > functional and non-functional as well) and send it to you... Yes, thank you, that would be good. Especially if you include the CVS tree you're trying to index (it's a good thing it's linux kernels, so I don't have to sign anything :) ). I don't need the ping version, only the sourceforge version. I can't promise you that I'll fix this quickly (having to work for a living as well :) ), but it's certainly easier for me to debug something I can edit and hack around with myself than having to debug by mail. ...Peder... -- Cogito ergo panta rei. |
From: Jan-Benedict G. <jb...@lu...> - 2001-07-31 11:14:33
|
On Tue, Jul 31, 2001 at 12:51:07PM +0200, Peder O. Klingenberg wrote: > Jan-Benedict Glaw <jb...@lu...> writes: > > > [...] > > ### /lib/wait.c > > --- /lib/wait.c head 1.2 > > /lib/wait.c was already referenced > > ### /lib/write.c > > --- /lib/write.c head 1.2 > > /lib/write.c was already referenced > > Did you empty the database before running genxref? Otherwise you may Not exactly... > have stuff lying around in the tables that makes genxref think you > already indexed these files. > > > ### /mm/Makefile > > co: /home/data/CVSROOT/linux//mm/Makefile,v: branch number 0 too low > > co: /home/data/CVSROOT/linux//mm/Makefile,v: branch number 0 too low > > co: /home/data/CVSROOT/linux//mm/Makefile,v: branch number 0 too low > > co: /home/data/CVSROOT/linux//mm/Makefile,v: branch number 0 too low > > co: /home/data/CVSROOT/linux//mm/Makefile,v: branch number 0 too low > > co: /home/data/CVSROOT/linux//mm/Makefile,v: branch number 0 too low > > Hm. It gets as far as trying to check out the file, but seems to > somehow get confused over which version to check out. Trying six > times would indicate that it's trying to check out six different > versions. Or something. Hmmm. Yes, there are 6 {tag,branche}s for that file: www-data@mirror:/home/data/CVSROOT/linux/mm$ head -n 11 Makefile,v head 1.4; access; symbols jbglaw_0_13:1.4 jbglaw_0_13_b:1.4.0.2 v_0_12:1.4 v_0_11:1.3 v_0_10:1.2 v_0_01:1.1; locks; strict; comment @# @; "jbglaw_0_13_b" is a branch, everything else is a tag. > > Which is also triggered with the older CVS version of gnexref you mentioned > > above. > > Yep. It's a bug in the database interface libraries. Do you know in which part of it? LXR's handler routines? Perl'S DBI interface? Or in PostgreSQL's libpq? > > If it could help you, I'd package my complete LXR installation ( > > functional and non-functional as well) and send it to you... > > Yes, thank you, that would be good. Especially if you include the CVS > tree you're trying to index (it's a good thing it's linux kernels, so > I don't have to sign anything :) ). I don't need the ping version, > only the sourceforge version. Okay, I'll send it in PM shortly... Thank you so far! MfG, JBG |
From: <pe...@kl...> - 2001-07-31 11:32:08
|
Jan-Benedict Glaw <jb...@lu...> writes: > > Yep. It's a bug in the database interface libraries. > > Do you know in which part of it? LXR's handler routines? Perl'S DBI > interface? Or in PostgreSQL's libpq? My current theory is that it's in the interaction between Perls DBI and LXRs Postgres and MySQL modules. It's discussed in the bugracker at SF, See <https://sourceforge.net/tracker/index.php?func=detail&aid=428513&group_id=27350&atid=390117> ...Peder... -- Cogito ergo panta rei. |
From: Jan-Benedict G. <jb...@lu...> - 2001-07-31 12:09:32
|
On Tue, Jul 31, 2001 at 01:32:02PM +0200, Peder O. Klingenberg wrote: > Jan-Benedict Glaw <jb...@lu...> writes: > > > > Yep. It's a bug in the database interface libraries. > > > > Do you know in which part of it? LXR's handler routines? Perl'S DBI > > interface? Or in PostgreSQL's libpq? > > My current theory is that it's in the interaction between Perls DBI > and LXRs Postgres and MySQL modules. It's discussed in the bugracker > at SF, See > <https://sourceforge.net/tracker/index.php?func=detail&aid=428513&group_id=27350&atid=390117> I've done further tests. - Drop database lxr-cvs - Create DB lxr-cvs - psql lxr-cvs --> \i initdb-postgres - ./genxref --url="http://mirror.microdata-pos.de/lxr-cvs" --allversions --> Indexes only head, without database error --> all other tags are ignored - ./genxref --url="http://mirror.microdata-pos.de/lxr-cvs" --allversions --> Prints warnings that those files were already referenced and exits with database error --> Only head is indexed, all other tags are ignored The used genxref is current sourceforge CVS. MfG, JBG |
From: Jason D. S. <js...@de...> - 2001-08-01 05:35:03
|
I'm using the CVS version of LXR on a Red Hat 7.1/i686 machine. I'm using the Postgres database to cross-reference the code for NetHack. genxref runs fine on the first 10 or so code versions, however in the middle of indexing one version listed it dies with the following message: disconnect(DBI::db=HASH(0x81c1124)) invalidates 1 active statement. Either destroy statement handles or call finish on them before disconnecting. at lib//LXR/Index/Postgres.pm line 272. If I repeat the genxref call, it ends up giving the same error. If I restart the postgres daemon, it still gives the same error. (Now, the version it dies on is the _first_ one listed, but certainly not the first one indexed. Does genxref index them in reverse order? Alphabetical?) At the end of this, if I use LXR to view the source through HTTP, I get all sorts of errors like: ** Warning: DBD::Pg::st execute failed: ERROR: Attribute 'symid' not found ** Warning: DBD::Pg::st fetchrow_array failed: no statement executing However, these seem to be inconsistent, perhaps not appearing all the time (?). Also, nothing is referenced. http://devon.dhs.org/lxr/nethack/source http://devon.dhs.org/lxr/nethack/source/src/botl.c I've used the old (0.3) version of LXR successfully on this same code: http://nethack.dhs.org/. This doesn't seem like a very helpful report, but I don't know what else to say... jason short |
From: Jason D. S. <js...@de...> - 2001-08-01 15:40:39
|
Jason Dorje Short wrote: > > I'm using the CVS version of LXR on a Red Hat 7.1/i686 machine. I'm > using the Postgres database to cross-reference the code for NetHack. After re-indexing (using yesterday's version of genxref), I still get the error message: > disconnect(DBI::db=HASH(0x81c1124)) invalidates 1 active statement. > Either destroy statement handles or call finish on them before > disconnecting. at lib//LXR/Index/Postgres.pm line 272. However, now the indexing does seem to be completed, so that source browsing works as normal. There are no more errors of this type during source browsing: > ** Warning: DBD::Pg::st execute failed: ERROR: Attribute 'symid' not found > ** Warning: DBD::Pg::st fetchrow_array failed: no statement executing It seems likely that the first error message comes from trying to disconnect the database connection before postgres is finished processing. jason |
From: <pe...@kl...> - 2001-08-01 08:31:17
|
Jan-Benedict Glaw <jb...@lu...> writes: > > > ### /mm/Makefile > > > co: /home/data/CVSROOT/linux//mm/Makefile,v: branch number 0 too low > > > co: /home/data/CVSROOT/linux//mm/Makefile,v: branch number 0 too low > > > co: /home/data/CVSROOT/linux//mm/Makefile,v: branch number 0 too low > > > co: /home/data/CVSROOT/linux//mm/Makefile,v: branch number 0 too low > > > co: /home/data/CVSROOT/linux//mm/Makefile,v: branch number 0 too low > > > co: /home/data/CVSROOT/linux//mm/Makefile,v: branch number 0 too low > > > > Hm. It gets as far as trying to check out the file, but seems to > > somehow get confused over which version to check out. Trying six > > times would indicate that it's trying to check out six different > > versions. Or something. > > Hmmm. Yes, there are 6 {tag,branche}s for that file: > > www-data@mirror:/home/data/CVSROOT/linux/mm$ head -n 11 Makefile,v > head 1.4; > access; > symbols > jbglaw_0_13:1.4 > jbglaw_0_13_b:1.4.0.2 > v_0_12:1.4 > v_0_11:1.3 > v_0_10:1.2 > v_0_01:1.1; > locks; strict; > comment @# @; I squashed this one, I think. Stupid regexp-bug in CVS.pm trying to determine the actual revision. Trying to match a number like 1.4, it instead matched the first 0 in the symbol. Updated CVS.pm checked in. ...Peder... -- Cogito ergo panta rei. |
From: Jan-Benedict G. <jb...@lu...> - 2001-08-01 08:49:22
|
On Wed, Aug 01, 2001 at 10:31:08AM +0200, Peder O. Klingenberg wrote: > Jan-Benedict Glaw <jb...@lu...> writes: > > www-data@mirror:/home/data/CVSROOT/linux/mm$ head -n 11 Makefile,v > > head 1.4; > > access; > > symbols > > jbglaw_0_13:1.4 > > jbglaw_0_13_b:1.4.0.2 > > v_0_12:1.4 > > v_0_11:1.3 > > v_0_10:1.2 > > v_0_01:1.1; > > locks; strict; > > comment @# @; > > I squashed this one, I think. Stupid regexp-bug in CVS.pm trying to > determine the actual revision. Trying to match a number like 1.4, it > instead matched the first 0 in the symbol. This bug is pinned down. It now seems to recognize revisions of a file correctly. However, it's still only indexing "head" when called with --allversions. MfG, JBG |
From: <pe...@kl...> - 2001-08-01 09:04:47
|
Jan-Benedict Glaw <jb...@lu...> writes: > This bug is pinned down. Good. > It now seems to recognize revisions of a file correctly. However, > it's still only indexing "head" when called with --allversions. This is with the newest genxref, right? The problem there is the same as before, namely that when you give it --allversions, it just looks up all the versions of the root of your source tree, and assumes that is all the versions there are. Which is wildly wrong. For CVS use, you really need to test each file. I'll fix that sometime today, I guess. ...Peder... -- Cogito ergo panta rei. |
From: <pe...@kl...> - 2001-08-01 11:31:52
|
pe...@kl... (Peder O. Klingenberg) writes: > Jan-Benedict Glaw <jb...@lu...> writes: > > > It now seems to recognize revisions of a file correctly. However, > > it's still only indexing "head" when called with --allversions. > > I'll fix that sometime today, I guess. See if it works better now. I've reverted to the old behaviour in genxref. The patch that tried to precompute the versions to index (patch #432351 "genxref usability patch" by Jason Short) states that "The --allversions option should now work (it didn't before, seemingly because of a bug)." Without more information on exactly how it didn't work, a demonstration of the bug, etc, it's not really possible for me to determine if my changes have retriggered that last bug, so that's not tested, sorry. What I do know is that the fix was conceptually wrong. So Jason, if you're reading this, could you please provide some more details about the bug you were seeing with --allversions? ...Peder... -- Cogito ergo panta rei. |
From: Jan-Benedict G. <jb...@lu...> - 2001-08-01 12:09:39
|
On Wed, Aug 01, 2001 at 01:31:46PM +0200, Peder O. Klingenberg wrote: > pe...@kl... (Peder O. Klingenberg) writes: > > > Jan-Benedict Glaw <jb...@lu...> writes: > > > > > It now seems to recognize revisions of a file correctly. However, > > > it's still only indexing "head" when called with --allversions. > > > > I'll fix that sometime today, I guess. > > The patch that tried to precompute the versions to index (patch > #432351 "genxref usability patch" by Jason Short) states that "The > --allversions option should now work (it didn't before, seemingly > because of a bug)." I've tested again. It now gets all versions (read: cvs tags). However, "co" is complaining sometimes: ---------------------------- cut ------------------------------- ### /mm/memory.c --- /mm/memory.c head 1.4 /mm/memory.c was already referenced --- /mm/memory.c jbglaw_0_13 1.4 /mm/memory.c was already referenced --- /mm/memory.c jbglaw_0_13_b 1.4.0.2 --- /mm/memory.c 381 co: /home/data/CVSROOT/linux//mm/memory.c,v: no side branches present for 1.4 --- /mm/memory.c v_0_01 1.1 --- /mm/memory.c 382 +++ 1 --- /mm/memory.c v_0_10 1.2 --- /mm/memory.c 383 +++ 265 --- /mm/memory.c v_0_11 1.3 --- /mm/memory.c 384 +++ 278 --- /mm/memory.c v_0_12 1.4 /mm/memory.c was already referenced ---------------------------- cut ------------------------------- Any clue about that? At least, it gets more and more perfect:-) MfG, JBG |
From: <pe...@kl...> - 2001-08-01 12:24:54
|
Jan-Benedict Glaw <jb...@lu...> writes: > I've tested again. It now gets all versions (read: cvs tags). Good. > However, "co" is complaining sometimes: Yes, I saw that here as well. Currently I'm chasing the DB connection bug, which is really beginning to irritate me. When I have a grip on that, I'll look at the co thing. > At least, it gets more and more perfect:-) It sucks marginally less for each checkin, but it still beats most industrial vaucuum cleaners ;) ...Peder... -- Cogito ergo panta rei. |
From: Kevin W. <kev...@ov...> - 2001-08-03 00:10:24
|
On Wed, Aug 01, 2001 at 02:24:44PM +0200, Peder O. Klingenberg wrote: > > Yes, I saw that here as well. Currently I'm chasing the DB connection > bug, which is really beginning to irritate me. When I have a grip on > that, I'll look at the co thing. Any chance you've made progress on the DB connection bug? |
From: <pe...@kl...> - 2001-08-03 08:10:25
|
Kevin Way <kev...@ov...> writes: > Any chance you've made progress on the DB connection bug? Not really, but I have made some progress on the co thing instead, which was at least for me several different bugs. 1) Somehow the %cvs hash wasn't cleared when new files were being parsed. The result was that we'd try to check out non-existant versions. One-line fix, I think I already committed that one. I do _so_ hate global variables. 2) Some of my CVS files contained symbols pointing to non-existant versions. Since LXR always translates symbols to versions before checking out, that also resulted in trying to check out non-existant versions, and also resulted in the branching errors. The fix I have is that I run a consistency check on the symbols, deleting the ones that have no corresponding version. Unfortunately that seems to make genxref even slower. Noticeably slow. Alternatively that may have been a problem with our server, which had problems with one of its CPUs, its swap and at least some of its raid disks yesterday. I'd like some feedback on wether this seems like an acceptable fix, or wether we'd rather just live with co failing from time to time. 3) I had some errors where co complained about premature end of file or someting. These were on binary files (jpegs), and it's entirely possible that the files are corrupt. I have ignored these for now. ...Peder... -- Cogito ergo panta rei. |
From: Malcolm B. <ma...@br...> - 2001-08-04 14:46:13
|
Kevin Way wrote: > Any chance you've made progress on the DB connection bug? I have a possible fix that I'm testing out at the moment with Mysql.pm (I don't have Postgres installed yet). This is to make the $dbh handle local to each Mysql object ie $self->{dbh} rather than a package variable. I've also made all the sql statements object variables rather than package ones. This then lets the connection be closed via a DESTROY subroutine whenever the index object goes out of scope. I think this is a nice solution since I can't find any guarantee on the ordering of END blocks between packages which Peder has pointed out could cause the problem. I plan to test this change for a bit here and then release it if it continues to work. I imagine a similar approach would work for Postgres as well. Cheers, Malcolm |
From: <pe...@kl...> - 2001-08-04 15:24:51
|
Malcolm Box <ma...@br...> writes: > I have a possible fix that I'm testing out at the moment with Mysql.pm > (I don't have Postgres installed yet). This is to make the $dbh handle > local to each Mysql object ie $self->{dbh} rather than a package > variable. I've also made all the sql statements object variables rather > than package ones. > > This then lets the connection be closed via a DESTROY subroutine > whenever the index object goes out of scope. Wow, what syncronicity. I've done the same thing with Postgres. While this solves the problem seen with genxref, I now get complaints about not being able to call commit during global gc or destruction or something (I don't recall the exact message) during execution of the source script. I haven't quite figured that out yet. ...Peder... -- Cogito ergo panta rei. |
From: Malcolm B. <ma...@br...> - 2001-08-04 19:08:16
|
"Peder O. Klingenberg" wrote: > > Malcolm Box <ma...@br...> writes: > > > I have a possible fix that I'm testing out at the moment with Mysql.pm > > (I don't have Postgres installed yet). This is to make the $dbh handle > > local to each Mysql object ie $self->{dbh} rather than a package > > variable. I've also made all the sql statements object variables rather > > than package ones. > > > > This then lets the connection be closed via a DESTROY subroutine > > whenever the index object goes out of scope. > > Wow, what syncronicity. > > I've done the same thing with Postgres. While this solves the problem > seen with genxref, I now get complaints about not being able to call > commit during global gc or destruction or something (I don't recall > the exact message) during execution of the source script. I haven't > quite figured that out yet. I'm not seeing any errors, but then again I'm not calling commit :-) If I try calling commit, I get a message saying that it's ineffective when autocommit is in operation. All this is with MySQL. Since this approach gets rid of the warnings and seems to work well, I'm going to go ahead and submit it. Now there's just the matter of the memory leak that seems to be there - genxref balloons to more than 30Mb when indexing my test tree, and I don't see any reason for that sort of memory consumption. Cheers, Malcolm |
From: Kevin W. <kev...@ov...> - 2001-08-01 17:31:27
|
On Wed, Aug 01, 2001 at 02:09:31PM +0200, Jan-Benedict Glaw wrote: > I've tested again. It now gets all versions (read: cvs tags). However, > "co" is complaining sometimes: > > < .... > > --- /mm/memory.c 381 > co: /home/data/CVSROOT/linux//mm/memory.c,v: no side branches present for 1.4 > < .... > > > Any clue about that? I actually get that, and one other error while it performs the checkout. *** /src/lkm/vinum/vinumkw.h --- /src/lkm/vinum/vinumkw.h RELENG_2_2 1.3.0.2 --- /src/lkm/vinum/vinumkw.h 194 co: /home/mosch/fbsd//src/lkm/vinum/Attic/vinumkw.h,v: revision 1.3.0 absent --- /src/lkm/vinum/vinumkw.h RELENG_3_0_0_RELEASE 1.1.1.1 --- /src/lkm/vinum/vinumkw.h 195 --- /src/lkm/vinum/vinumkw.h VINUM 1.1.1 I'll see if I can find out what's happening there after I get some lunch, unless there's somebody who already knows... Kevin Way |
From: Jason D. S. <js...@de...> - 2001-08-01 15:13:42
|
"Peder O. Klingenberg" wrote: > See if it works better now. I've reverted to the old behaviour in > genxref. > > The patch that tried to precompute the versions to index (patch > #432351 "genxref usability patch" by Jason Short) states that "The > --allversions option should now work (it didn't before, seemingly > because of a bug)." > > Without more information on exactly how it didn't work, a > demonstration of the bug, etc, it's not really possible for me to > determine if my changes have retriggered that last bug, so that's not > tested, sorry. What I do know is that the fix was conceptually > wrong. > > So Jason, if you're reading this, could you please provide some more > details about the bug you were seeing with --allversions? Unfortunately, I don't remember exactly what I thought the "bug" was at the time. I do know that --allversions didn't work for me at the time, and that I fixed it. No doubt I'm missing something, but I don't understand why my change was conceptually wrong. I took each version to be indexed, and traversed the tree for that version. The current/former behavior is to traverse the tree, and for each file index it for all possible versions. One possible problem here is that the tree may not be the same for all versions - in particular, for the (non-CVS) tree I'm indexing, earlier versions have an entirely different directory structure. BTW, the new genxref doesn't work for me again. It runs through all versions just as if everything had already been indexed, even immediately after I drop and re-create the database. jason |
From: <pe...@kl...> - 2001-08-02 07:46:03
|
Jason Dorje Short <js...@de...> writes: > No doubt I'm missing something, but I don't understand why my change was > conceptually wrong. I took each version to be indexed, and traversed > the tree for that version. But you can't find the versions to be indexed by asking for the versions of the root of the tree. In a CVS tree, each file can have a differing number of versions, have completely different tags, etc. > The current/former behavior is to traverse the tree, and for each > file index it for all possible versions. Yes, that was the point. Unless you specify a version, you get all the versions a file has to offer. That was at least the concept I had of --allversions, and your patch didn't fit that concept. Hence conceptually wrong. It may of course well be that my concepts are different from yours, in which case it's a matter of opinion which version (pun intended) to hold as the correct one. > BTW, the new genxref doesn't work for me again. It runs through all > versions just as if everything had already been indexed, even > immediately after I drop and re-create the database. Maybe this is because Plain.pm and CVS.pm disagree on how to compute allreleases? I've never looked at Plain.pm, so I don't know. It seems to me that this is an area that needs more customization, because we obviously disagree, and I suspect that we both have equally valid views. And as it so happens, we have a configuration variable by the name of 'range'. Would you be happy if --allversions just used the range in lxr.conf? I've already patched Config.pm to accept closures for this variable in order to get the cgi scripts to display versions based on the versions of each file, so I think I could make this work for me. It would still need to use the original control flow in order to allow the flexibility I need, but specifying a constant range list (or file) in lxr.conf should give the same semantics as precomputing the versions to index, should it not? ...Peder... -- This must be Thursday. I never could get the hang of Thursdays. |