lxr-developer Mailing List for LXR Cross Referencer (Page 31)
Brought to you by:
ajlittoz
Menu
▾
▴
lxr-developer — Don't use, active developers only
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(11) |
Jun
(21) |
Jul
(14) |
Aug
(83) |
Sep
(23) |
Oct
(37) |
Nov
(52) |
Dec
(10) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(28) |
Feb
(40) |
Mar
(21) |
Apr
(8) |
May
(21) |
Jun
(13) |
Jul
(9) |
Aug
(5) |
Sep
(8) |
Oct
(7) |
Nov
(2) |
Dec
|
| 2003 |
Jan
(2) |
Feb
(1) |
Mar
(11) |
Apr
(4) |
May
(6) |
Jun
(15) |
Jul
(4) |
Aug
(4) |
Sep
(9) |
Oct
(1) |
Nov
(1) |
Dec
(1) |
| 2004 |
Jan
(4) |
Feb
|
Mar
(4) |
Apr
(12) |
May
(5) |
Jun
(9) |
Jul
(47) |
Aug
(1) |
Sep
(1) |
Oct
(7) |
Nov
|
Dec
(1) |
| 2005 |
Jan
(4) |
Feb
(2) |
Mar
(3) |
Apr
(10) |
May
(9) |
Jun
(15) |
Jul
(3) |
Aug
(1) |
Sep
(8) |
Oct
(9) |
Nov
(10) |
Dec
(4) |
| 2006 |
Jan
(1) |
Feb
|
Mar
(9) |
Apr
(5) |
May
(1) |
Jun
(6) |
Jul
(2) |
Aug
|
Sep
(5) |
Oct
(2) |
Nov
|
Dec
(3) |
| 2007 |
Jan
(2) |
Feb
(1) |
Mar
(32) |
Apr
(3) |
May
(3) |
Jun
(16) |
Jul
(1) |
Aug
|
Sep
|
Oct
(2) |
Nov
(4) |
Dec
(3) |
| 2008 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2009 |
Jan
|
Feb
|
Mar
(46) |
Apr
(70) |
May
(15) |
Jun
(13) |
Jul
(1) |
Aug
|
Sep
(7) |
Oct
|
Nov
|
Dec
|
| 2010 |
Jan
(5) |
Feb
(4) |
Mar
|
Apr
|
May
(2) |
Jun
(1) |
Jul
(1) |
Aug
|
Sep
|
Oct
(7) |
Nov
(6) |
Dec
|
| 2011 |
Jan
(1) |
Feb
|
Mar
(85) |
Apr
(18) |
May
(4) |
Jun
(3) |
Jul
(4) |
Aug
(1) |
Sep
|
Oct
(2) |
Nov
(2) |
Dec
(20) |
| 2012 |
Jan
(17) |
Feb
(16) |
Mar
(13) |
Apr
(18) |
May
|
Jun
(6) |
Jul
(6) |
Aug
(10) |
Sep
(15) |
Oct
(10) |
Nov
(25) |
Dec
(1) |
|
From: SourceForge.net <no...@so...> - 2003-06-07 22:20:02
|
Bugs item #749886, was opened at 2003-06-05 17:13 Message generated for change (Comment added) made by n7ikq You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=749886&group_id=27350 Category: Browsing Group: v0.9.1 Status: Open Resolution: None Priority: 5 Submitted By: Rusty Carruth (n7ikq) Assigned to: Nobody/Anonymous (nobody) Summary: IE views ok, Netscape gets html code seen Initial Comment: After installing lxr on a linux mandrake 9.1 machine, everything works just fine if I view the ident, source, etc 'pages' from M$ Internet Explorer. However, galeon, mozilla, and netscape all seem to prefer to show you the actual html rather than the result of interpreting that same html. Strange discovery we made is that, using galeon we can save the file and load that saved file and it renders correctly! If that's not strange enough, we downloaded the url using wget and it rendered fine on the first try. Is there some kind of timing issue with NS that IE doesn't have??? Weird... rc aka n7ikq. ---------------------------------------------------------------------- >Comment By: Rusty Carruth (n7ikq) Date: 2003-06-07 15:20 Message: Logged In: YES user_id=788971 Ok, so I did a wget -S and it said: rcarruth@msfree> wget -S http://localplace/lxr/ident --15:06:51-- http://localplace:80/lxr/ident => `ident' Connecting to localplace:80... connected! HTTP request sent, awaiting response... 200 OK 2 Date: Sat, 07 Jun 2003 22:12:53 GMT 3 Server: Apache-AdvancedExtranetServer/2.0.44 (Mandrake Linux/11mdk) mod_perl/1.99_08 Perl/v5.8.0 mod_ssl/2.0.44 OpenSSL/0.9.7a PHP/4.3.1 4 Connection: close 5 Content-Type: text/plain; charset=ISO-8859-1 6 X-Pad: avoid browser bug 7 0K -> ..... 15:06:52 (345.52 KB/s) - `ident' saved [5661] rcarruth@msfree> less ident <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> <meta name="GENERATOR" content="Mozilla/4.61 [en] (X11; I; SunOS 5.5.1 sun4u) [Netscape]"> <title>Sapphire identfier search</title> <base href="http://localplace/lxr/"> <link href="lxr.css" rel="STYLESHEET" type="text/css"> </head> <body> <table width='100%' border='0' cellpadding='0' cellspacing='0'> <tr> .....etc... Now, I load the above 'ident' file wget got, and it displays fine. However, if I instead go to the url that FETCHED that file, I get the source of the file not the display it should have gotten. (I looked through all the places where lxr could say 'text/plain' and changed them all to 'text/html' and STILL wget says 'text/plain'... rc aka n7ikq. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-06-06 14:17 Message: Logged In: NO The most likely explanation is that the webserver is returning the contents as text/plain rather than text/html. IE (incorrectly) interprets such text as html anyway, whereas Netscape/Mozilla don't. The lxr code does put out a content-type header, so it should work, but perhaps Apache is configured in a weird way. You can use wget -S to check what is being returned in the headers. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=749886&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2003-06-06 21:17:07
|
Bugs item #749886, was opened at 2003-06-05 17:13 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=749886&group_id=27350 Category: Browsing Group: v0.9.1 Status: Open Resolution: None Priority: 5 Submitted By: Rusty Carruth (n7ikq) Assigned to: Nobody/Anonymous (nobody) Summary: IE views ok, Netscape gets html code seen Initial Comment: After installing lxr on a linux mandrake 9.1 machine, everything works just fine if I view the ident, source, etc 'pages' from M$ Internet Explorer. However, galeon, mozilla, and netscape all seem to prefer to show you the actual html rather than the result of interpreting that same html. Strange discovery we made is that, using galeon we can save the file and load that saved file and it renders correctly! If that's not strange enough, we downloaded the url using wget and it rendered fine on the first try. Is there some kind of timing issue with NS that IE doesn't have??? Weird... rc aka n7ikq. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-06-06 14:17 Message: Logged In: NO The most likely explanation is that the webserver is returning the contents as text/plain rather than text/html. IE (incorrectly) interprets such text as html anyway, whereas Netscape/Mozilla don't. The lxr code does put out a content-type header, so it should work, but perhaps Apache is configured in a weird way. You can use wget -S to check what is being returned in the headers. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=749886&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2003-06-06 00:13:38
|
Bugs item #749886, was opened at 2003-06-05 17:13 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=749886&group_id=27350 Category: Browsing Group: v0.9.1 Status: Open Resolution: None Priority: 5 Submitted By: Rusty Carruth (n7ikq) Assigned to: Nobody/Anonymous (nobody) Summary: IE views ok, Netscape gets html code seen Initial Comment: After installing lxr on a linux mandrake 9.1 machine, everything works just fine if I view the ident, source, etc 'pages' from M$ Internet Explorer. However, galeon, mozilla, and netscape all seem to prefer to show you the actual html rather than the result of interpreting that same html. Strange discovery we made is that, using galeon we can save the file and load that saved file and it renders correctly! If that's not strange enough, we downloaded the url using wget and it rendered fine on the first try. Is there some kind of timing issue with NS that IE doesn't have??? Weird... rc aka n7ikq. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=749886&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2003-06-05 18:25:01
|
Bugs item #749648, was opened at 2003-06-06 01:46 Message generated for change (Comment added) made by mbox You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=749648&group_id=27350 Category: genxref Group: v0.9.1 Status: Open Resolution: None Priority: 5 Submitted By: Robins Tharakan (tharakan) Assigned to: Nobody/Anonymous (nobody) Summary: infinite loop while performing genxref (3 files *only*) Initial Comment: Hi, lxr is running perfectly now on my site, so problems with lxr.conf file seems minimal (although not ruled out) but i have had bad times, while performing genxref the linux kernel source (2.5.68) using lxr 0.9.1. the three files i found out (which were where genxref hung were) /drivers/video/amifb.c /fs/cifs/ntlmssp.h /drivers/video/vga16fb.c and repeatedly so...!! (once i ran genxref for 21 hours (athlon 800/200Mb RAM)! just to make sure i dont shut it down prematurely.. but it just hung!) i had to rename the three above mentioned files to xxx.c ==> xxx.c.lxr and perform the operation all over again! (frankly i dont know what database i am using (bad at databases), mine is a RH8.0 system (default installation). i am using plain files (linux-2.5.68.tar.bz2) not cvs. if required i could send over the test case again, or maybe even the lxr.conf if required... the error was repeatedly showing as "found a 0x0a immediately after a 0x0f..." or some message like that... Really sorry for being arbitrary here, forgot to keep the error message on file. (but i think just processing genxref throught the files should give the test case anyways.. , but i havent tried it individually...) hope this helps... please ask for anything else if required. affly robins ---------------------------------------------------------------------- >Comment By: Malcolm Box (mbox) Date: 2003-06-06 03:25 Message: Logged In: YES user_id=215386 This doesn't happen on my system with the latest CVS lxr, again against the 2.5.68 kernel source from kernel.org Can you try repeating this with a later lxr, and if it re-occurs post the error message? Thanks, Malcolm ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=749648&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2003-06-05 18:20:22
|
Bugs item #735063, was opened at 2003-05-09 16:01 Message generated for change (Comment added) made by mbox You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=735063&group_id=27350 Category: Database interface Group: v0.9.1 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: initdb-mysql script contains incorrect syntax Initial Comment: First command in the initdb-mysql script is formed incorrectly. current > drop if exists database lxr; should be > drop database if exists lxr; Cheers Thomas Morris tho...@in... ---------------------------------------------------------------------- >Comment By: Malcolm Box (mbox) Date: 2003-06-06 03:20 Message: Logged In: YES user_id=215386 Fixed in latest CVS ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=735063&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2003-06-05 18:18:53
|
Bugs item #735124, was opened at 2003-05-09 18:32 Message generated for change (Settings changed) made by mbox You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=735124&group_id=27350 Category: Documentation Group: current cvs >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Malcolm Box (mbox) Summary: rcs also needed Initial Comment: I am running redhat 8.0 and discovered when running genxref that the rcs package is needed, which is not installed in the base redhat installation but is included with the distro. This dependency should be documented in the INSTALL. Cheers, Thomas Morris tho...@in... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=735124&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2003-06-05 16:53:43
|
Bugs item #703803, was opened at 2003-03-15 04:45 Message generated for change (Settings changed) made by mbox You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=703803&group_id=27350 Category: Browsing Group: current cvs >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Richard Kisley (kisley) Assigned to: Nobody/Anonymous (nobody) Summary: search script glimpsedir path construction spotty Initial Comment: There are really 2 issues I noticed I had to fix to get it to work for me: 1) The 'search' script runs exec on a comma-delimited parameter list. This failed because of path problems, when it still failed I switched it to the familiar '.' Perl notation for string combining and the 'exec' runs fine. My version: exec($config->glimpsebin." -iyn "."-H ".$config->glimpsedir."/".$release." ".$searchtext); 2) The 'search' script and the 'find' script have different glimpsedir paths. Thus if you move all the .glimpsexxx files to .../glimpse/<version>/.glimpsexxx from .../glimpse/.glimpsexxx, so that the 'search' script works, the 'find' script breaks. My version of the block in 'find': unless (open(FILELLISTING,$config->glimpsedir."/".$release."/.glimpse_filenames")) { &warning("Could not open ".$config->glimpsedir."/".$release."/.glimpse_filenames."); return; } (anecdote): both of these changed lines work in my environment. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=703803&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2003-06-05 16:46:56
|
Bugs item #749648, was opened at 2003-06-05 16:46 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=749648&group_id=27350 Category: genxref Group: v0.9.1 Status: Open Resolution: None Priority: 5 Submitted By: Robins Tharakan (tharakan) Assigned to: Nobody/Anonymous (nobody) Summary: infinite loop while performing genxref (3 files *only*) Initial Comment: Hi, lxr is running perfectly now on my site, so problems with lxr.conf file seems minimal (although not ruled out) but i have had bad times, while performing genxref the linux kernel source (2.5.68) using lxr 0.9.1. the three files i found out (which were where genxref hung were) /drivers/video/amifb.c /fs/cifs/ntlmssp.h /drivers/video/vga16fb.c and repeatedly so...!! (once i ran genxref for 21 hours (athlon 800/200Mb RAM)! just to make sure i dont shut it down prematurely.. but it just hung!) i had to rename the three above mentioned files to xxx.c ==> xxx.c.lxr and perform the operation all over again! (frankly i dont know what database i am using (bad at databases), mine is a RH8.0 system (default installation). i am using plain files (linux-2.5.68.tar.bz2) not cvs. if required i could send over the test case again, or maybe even the lxr.conf if required... the error was repeatedly showing as "found a 0x0a immediately after a 0x0f..." or some message like that... Really sorry for being arbitrary here, forgot to keep the error message on file. (but i think just processing genxref throught the files should give the test case anyways.. , but i havent tried it individually...) hope this helps... please ask for anything else if required. affly robins ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=749648&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2003-06-02 20:27:17
|
Feature Requests item #623617, was opened at 2002-10-15 12:16 Message generated for change (Comment added) made by jsteenhagen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390120&aid=623617&group_id=27350 Category: Browsing Interface Group: None Status: Open Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Add a 'Download current file' link Initial Comment: While I browse a public LXR website, I compare versions of the same file etc - sometimes I want to save locally the viewed file version. CUrrently its a cut, paste and other post processing ---------------------------------------------------------------------- Comment By: Jake (jsteenhagen) Date: 2003-06-02 16:01 Message: Logged In: YES user_id=331239 There's no link to it, but try appending ?raw=1 to your URL. You can then Save As w/your browser, or use the URL for wget or whatever else you need to do. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390120&aid=623617&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2003-05-29 01:13:16
|
Bugs item #745091, was opened at 2003-05-28 14:47 Message generated for change (Comment added) made by munroe_r You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=745091&group_id=27350 Category: genxref Group: None Status: Open Resolution: None Priority: 5 Submitted By: Richard Munroe (munroe_r) Assigned to: Nobody/Anonymous (nobody) Summary: Infinite loop when indexing production source trees. Initial Comment: I generally index my development source trees. When the linux kernel is built, a link from linux to /usr/src/linux is established. Which in many cases causes genxref to go into an infinite loop processing subdirectories. I've patched my version of lxr so that LXR::Files::Plain won't chase directory links (it WILL chase regular file links) which is good enough for my site. Probably a better fix would be to check for links that go outside the currently indexed directory structure and not process stuff that goes outside that or above it in the same directory tree. Anyway, here's the patch: --- /usr/src/lxr-0.9.2/lib/LXR/Files/Plain.pm Tue Feb 26 10:57:55 2002 +++ Plain.pm Wed May 28 14:10:13 2003 @@ -103,6 +103,12 @@ $dir = $self->toreal($pathname, $release); opendir(DIR, $dir) || die ("Can't open $dir"); while (defined($node = readdir(DIR))) { + # + # Avoid chasing links of directories. Using LXR on a production + # source tree results in infinite loops due to the creation + # of a link to linux. + # + next if ((-d "$dir/$node") && (-l "$dir/$node")) ; next if $node =~ /^\.|~$|\.orig$/; next if $node eq 'CVS'; Dick Munroe (mu...@cs...) ---------------------------------------------------------------------- >Comment By: Richard Munroe (munroe_r) Date: 2003-05-28 21:13 Message: Logged In: YES user_id=85781 Here's a better patch, one that doesn't include binary files either: --- /usr/src/lxr-0.9.2/lib/LXR/Files/Plain.pm Tue Feb 26 10:57:55 2002 +++ Plain.pm Wed May 28 21:05:27 2003 @@ -107,10 +107,19 @@ next if $node eq 'CVS'; if (-d $dir.$node) { - push(@dirs, $node.'/'); + # + # Avoid chasing links of directories. Using LXR on a production + # source tree results in infinite loops due to the creation + # of a link to linux. + # + push(@dirs, $node.'/') unless (-l $dir.$node) ; } else { - push(@files, $node); + # + # Binary files aren't of interest to either LXR, so don't put any + # on the list of files returned. + # + push(@files, $node) unless (-B $dir.$node) ; } } closedir(DIR); ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=745091&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2003-05-28 18:47:40
|
Bugs item #745091, was opened at 2003-05-28 14:47 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=745091&group_id=27350 Category: genxref Group: None Status: Open Resolution: None Priority: 5 Submitted By: Richard Munroe (munroe_r) Assigned to: Nobody/Anonymous (nobody) Summary: Infinite loop when indexing production source trees. Initial Comment: I generally index my development source trees. When the linux kernel is built, a link from linux to /usr/src/linux is established. Which in many cases causes genxref to go into an infinite loop processing subdirectories. I've patched my version of lxr so that LXR::Files::Plain won't chase directory links (it WILL chase regular file links) which is good enough for my site. Probably a better fix would be to check for links that go outside the currently indexed directory structure and not process stuff that goes outside that or above it in the same directory tree. Anyway, here's the patch: --- /usr/src/lxr-0.9.2/lib/LXR/Files/Plain.pm Tue Feb 26 10:57:55 2002 +++ Plain.pm Wed May 28 14:10:13 2003 @@ -103,6 +103,12 @@ $dir = $self->toreal($pathname, $release); opendir(DIR, $dir) || die ("Can't open $dir"); while (defined($node = readdir(DIR))) { + # + # Avoid chasing links of directories. Using LXR on a production + # source tree results in infinite loops due to the creation + # of a link to linux. + # + next if ((-d "$dir/$node") && (-l "$dir/$node")) ; next if $node =~ /^\.|~$|\.orig$/; next if $node eq 'CVS'; Dick Munroe (mu...@cs...) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=745091&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2003-05-23 11:54:54
|
Feature Requests item #742274, was opened at 2003-05-23 04:54 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390120&aid=742274&group_id=27350 Category: Browsing Interface Group: None Status: Open Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: More info from dentifier search display. Initial Comment: The identifier search such as: http://sourcenav/lxr/ident?v=<version>?i=<ident> does not return enough information compared with the freetext search. It would be perfect if each indentifier in the list displayed the content of the line as well, just like the freetext search. Thanks ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390120&aid=742274&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2003-05-22 11:16:17
|
Feature Requests item #741648, was opened at 2003-05-22 04:16 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390120&aid=741648&group_id=27350 Category: Browsing Interface Group: None Status: Open Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: More info from dentifier search display. Initial Comment: The identifier search such as: http://sourcenav/lxr/ident?v=<version>?i=<ident> does not return enough information compared with the freetext search. It would be perfect if each indentifier in the list displayed the content of the line as well, just like the freetext search. Thanks ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390120&aid=741648&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2003-05-09 09:32:23
|
Bugs item #735124, was opened at 2003-05-09 02:32 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=735124&group_id=27350 Category: Documentation Group: current cvs Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Malcolm Box (mbox) Summary: rcs also needed Initial Comment: I am running redhat 8.0 and discovered when running genxref that the rcs package is needed, which is not installed in the base redhat installation but is included with the distro. This dependency should be documented in the INSTALL. Cheers, Thomas Morris tho...@in... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=735124&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2003-05-09 07:01:27
|
Bugs item #735063, was opened at 2003-05-09 00:01 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=735063&group_id=27350 Category: Database interface Group: v0.9.1 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: initdb-mysql script contains incorrect syntax Initial Comment: First command in the initdb-mysql script is formed incorrectly. current > drop if exists database lxr; should be > drop database if exists lxr; Cheers Thomas Morris tho...@in... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=735063&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2003-04-24 10:13:42
|
Bugs item #726798, was opened at 2003-04-24 19:13 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=726798&group_id=27350 Category: genxref Group: current cvs Status: Open Resolution: None Priority: 5 Submitted By: Malcolm Box (mbox) Assigned to: Malcolm Box (mbox) Summary: ctags options are wrong Initial Comment: Genxref currently hard codes the --lang-options to ectags. This results in confusing output that the rest of Generic.pm is not able to handle. The fix is to make the parameters to ectags language dependent - ie extend the generic.conf structures. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=726798&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2003-04-08 00:22:45
|
Bugs item #518365, was opened at 2002-02-16 01:04 Message generated for change (Comment added) made by kisley You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=518365&group_id=27350 Category: genxref Group: current cvs Status: Open Resolution: None Priority: 7 Submitted By: Shree Kumar (shreekumar) Assigned to: Malcolm Box (mbox) Summary: Indexing of files once indexed is buggy! Initial Comment: I am using LXR-0.9.1 Consider this scenario : There is a source tree "test" having only one file - test.c test.c ------- #define TEST 100 now, I run genxref & when I search for TEST in identifiers, I get that it is a macro defined in test.c at line 1 now I change test.c to ------- #define T 1 #define TEST 100 & run genxref Now what I get is - TEST is defined as a macro in test.c in line 1 and line 2 ! The culprit is this piece of code in function processfile() [ Tagger.pm ] ------ if ($index->toindex($fileid)) { $index->empty_cache(); print(STDERR "--- $pathname $fileid\n"); my $path = $files->tmpfile($pathname, $release); $lang->indexfile($pathname, $path, $fileid, $index, $config); unlink($path); } else { print(STDERR "$pathname was already indexed\n"); } ------ The problem is that if the file already existed and has changed since then [based on the timestamp], the identifiers added to the database due to this file in the previous run of genxref are not removed from the database, hence the number of definitions will keep on growing... The same problem is also present in processrefs(). ---------------------------------------------------------------------- Comment By: Richard Kisley (kisley) Date: 2003-04-07 16:39 Message: Logged In: YES user_id=102080 (1) How about an intermediate solution, where someone writes a VERIFY script which compares the paths in the database with the version they refer to and deletes entries for invalid paths? Same options as genxref? I indexed a subtree of a sourcetree, then realized I needed to index the whole source tree. So I moved the revision main dir (since it was really a subdir) up a level and added the other directories at their proper top level as other subdirs, then re-indexed. Now the original links in tree one are all dead links, with live dupes. No files changed. (2) So we all don't have to scurry for our SQL books, buried in a box in the back of a closet at home (not work) how about posting the exact drop syntax? That might also be a good thing to add to doc short-term, since genxref doesn't work (prune) as expected. ---------------------------------------------------------------------- Comment By: Gregor Hartmann (grex) Date: 2002-06-07 05:10 Message: Logged In: YES user_id=559509 Another similar problem would be files ore whole directories that are deleted from the source tree. They would stay in the database forever as well. Maybe it could be fixed by iterating through all files in the database and removing those (from the database) which have changed or were removed in the source tree. then proceed indexing as before. ---------------------------------------------------------------------- Comment By: Shree Kumar (shreekumar) Date: 2002-02-18 22:21 Message: Logged In: YES user_id=142912 Here's my fix for this bug: Add a field "timestamp" to the "status" table. And remove the "status" field. Before finding identifiers in a file, check whether it's modification time is greater that it was previously. If yes, then remove all the identifier definitions due to this file [and release] from the database. Store the new timestamp in the database. Before finding references in a file, remove all identifier references due to this file [and release] from the database. [ No need to check the timestamp in this case since the "definitions" are always found before the references]. In a large CVS tree, it is quite possible that a file may change between the time it is "indexed" and "referenced". An easy way out of this seems to be to "index" a file and immediately "reference" it. Related to this there is a problem in "Plain.pm" - the current "filerev" function returns a value based on the timestamp. Problem arises if a file changes between runs of genxref. What happens is that different values are returned by "filerev" even though it is the same (file,revision) pair is being indexed [or referenced]. I have changed filerev() for this purpose as sub filerev { my ($self, $filename, $release) = @_; # TODO: length of filename+revision # might turn out to be > 255 chars # [length used in the db] return join("-", $filename, $release); } With this modification filerev() will return the same value for (file,revision) pair everytime - thus solving the problem. I have a patch ready for this. ---------------------------------------------------------------------- Comment By: Malcolm Box (mbox) Date: 2002-02-18 05:20 Message: Logged In: YES user_id=215386 Yes, you're right, this is a bug. The underlying assumption that is being broken is that the files in a version are static - which is true if one is indexing released software, but not if it is a development tree. The simplest work-around is to drop and recreate the database each time, thus avoiding the problem. For small to medium repositories with the index updated nightly this should work fine, but it doesn't work for large repositories. The full solution would appear to be to check for an existing entry for the (filename, release) pair and if it is found delete it and all associated information. ---------------------------------------------------------------------- Comment By: Shree Kumar (shreekumar) Date: 2002-02-16 04:32 Message: Logged In: YES user_id=142912 There are two cases where the scenario that I've referred to applies: 1. Files are not in CVS [ ie usage of "Files.pm" ]. You run genxref, then change a file & genxref again 2. Files are in CVS, and you want to index the "head" tag. Files change regularly, and you want to keep the cross reference in sync - probably by running genxref once an hour or so [as a cron job]. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-02-16 03:47 Message: Logged In: NO I was in the impression that a file may never ever change again, except if (and only if) the file was changed and has either got a new CVS revision (or tag) or if there is a new directory for a new version of the whole project (if it is not managed by CVS). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=518365&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2003-04-07 12:02:09
|
Bugs item #716701, was opened at 2003-04-07 12:17 Message generated for change (Comment added) made by pavel_hlavnicka You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=716701&group_id=27350 Category: Browsing Group: None Status: Open Resolution: None Priority: 5 Submitted By: Pavel Hlavnicka (pavel_hlavnicka) Assigned to: Nobody/Anonymous (nobody) Summary: $SIG{__WARN__} and mod_perl Initial Comment: To be honest, this problem brought many dreamless nights to me :) We run LXR in the mod_perl context together with another applications. Problem is simple. 1) LXR sets the $SIG{__WARN__} handler (i Common.pm), and it is, of course, global for the whole mod_perl context 2) the handler prints to the standard output(!!!) bu default (the $wwwdeug variable) As a result of this, in some environments (where LXR is running), under certain conditions (pretty rare in my case), some 'random' output is displayed in the page. (typically if something goes wrong in eval {}; block, what may be exactly what autor supposed). Uff, is think, $www debug should be cleared in the distribution, and setting the warning handler at all is a bit disputable, as some other application may be in trouble due this. Thanks for LXR Pavel ---------------------------------------------------------------------- >Comment By: Pavel Hlavnicka (pavel_hlavnicka) Date: 2003-04-07 12:17 Message: Logged In: YES user_id=302801 I need to tell, we are using 0.9.2. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=716701&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2003-04-07 12:01:25
|
Bugs item #716701, was opened at 2003-04-07 12:17 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=716701&group_id=27350 Category: Browsing Group: None Status: Open Resolution: None Priority: 5 Submitted By: Pavel Hlavnicka (pavel_hlavnicka) Assigned to: Nobody/Anonymous (nobody) Summary: $SIG{__WARN__} and mod_perl Initial Comment: To be honest, this problem brought many dreamless nights to me :) We run LXR in the mod_perl context together with another applications. Problem is simple. 1) LXR sets the $SIG{__WARN__} handler (i Common.pm), and it is, of course, global for the whole mod_perl context 2) the handler prints to the standard output(!!!) bu default (the $wwwdeug variable) As a result of this, in some environments (where LXR is running), under certain conditions (pretty rare in my case), some 'random' output is displayed in the page. (typically if something goes wrong in eval {}; block, what may be exactly what autor supposed). Uff, is think, $www debug should be cleared in the distribution, and setting the warning handler at all is a bit disputable, as some other application may be in trouble due this. Thanks for LXR Pavel ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=716701&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2003-03-31 22:33:17
|
Bugs item #695697, was opened at 2003-03-02 04:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=695697&group_id=27350 Category: Browsing Group: unknown >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Silently corrupting source code on lxr.linux.no Initial Comment: Hi, LXR on lxr.linux.no is silently corrupting data. In particular, where the Linux kernel contains the string "0" (including the quotes) it is being displayed as "", which completely changes the meaning of the code. ("0" is often used as a constraint for inline assembly). The file I have noticed this in is include/asm-i386/uaccess.h. It seems to affect all versions of the file, and all places where the string "0" is used in that file. Here are some sample URLs (compare with your real kernel sources): http://lxr.linux.no/source/include/asm-i386/uaccess.h#L174 http://lxr.linux.no/source/include/asm-i386/uaccess.h#L209 http://lxr.linux.no/source/include/asm-i386/uaccess.h#L247 http://lxr.linux.no/source/include/asm-i386/uaccess.h#L273 http://lxr.linux.no/source/include/asm-i386/uaccess.h#L301 http://lxr.linux.no/source/include/asm-i386/uaccess.h#L341 http://lxr.linux.no/source/include/asm-i386/uaccess.h#L360 http://lxr.linux.no/source/include/asm-i386/uaccess.h#L379 http://lxr.linux.no/source/include/asm-i386/uaccess.h#L401 http://lxr.linux.no/source/include/asm-i386/uaccess.h#L431 http://lxr.linux.no/source/include/asm-i386/uaccess.h#L463 http://lxr.linux.no/source/include/asm-i386/uaccess.h#L495 http://lxr.linux.no/source/include/asm-i386/uaccess.h#L537 http://lxr.linux.no/source/include/asm-i386/uaccess.h?v=2.4.18#L112 ... and others on the same page http://lxr.linux.no/source/include/asm-i386/uaccess.h?v=2.5.56#L117 ... and others on the same page And it's not just that file: http://lxr.linux.no/source/include/asm-x86_64/uaccess.h#L190 http://lxr.linux.no/source/include/asm-x86_64/uaccess.h#L229 Interestingly, it appears that the freetext search is using the correct, unmodified data. E.g.: http://lxr.linux.no/search?string=%5C%28__m%5C%28addr%5C%29%5C%29 The first few result lines all contain "0", and it is displayed correctly in the search results screen, but the hyperlink takes you to the corrupted file. Thanks for the great tool - I use lxr.linux.no a lot, and really appreciate it. However, silently corrupting code is not good... Kind regards, Jon Foster ---------------------------------------------------------------------- >Comment By: Malcolm Box (mbox) Date: 2003-04-01 07:47 Message: Logged In: YES user_id=215386 The version of lxr running on lxr.linux.no is the old 0.3 code, which is no longer being actively maintained. I also don't have access to the machine to change things over. If you can see this problem with a recent (0.9.2) version of LXR please let me know. Malcolm ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=695697&group_id=27350 |
|
From: SourceForge.net <no...@so...> - 2003-03-22 00:26:01
|
Bugs item #700771, was opened at 2003-03-10 20:19 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=700771&group_id=27350 >Category: Documentation Group: current cvs >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Malcolm Box (mbox) Assigned to: Malcolm Box (mbox) Summary: Install dependencies not doced Initial Comment: The INSTALL doc doesn't document the need for the perl DBI and DBD drivers to be installed, leading to confusion. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=700771&group_id=27350 |
|
From: Malcolm B. <ma...@br...> - 2003-03-21 13:16:03
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Giacomo, Giacomo A. Catenazzi wrote: | If I understand correctly the vulnerability, it happen | only because of the expantion on $v and $a, but | the all possible values are already stored | in some configuration files, so is it simple to | chech that $v and $a are in the correct set of values, | and that to manually (e.g. a simple string substitution) | the variable expantion, instead of the normal perl | expantion. Ah, I see how that could cause it, because we go and read $root/$v/$filename. Should be an easy fix. | BTW, FYI, the vulnerability is a candidate CVE: | http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0156 Thanks - I'll keep an eye on it. | BTW I view that some big project use LXR, whould you publish a | list of such servers? If you are interested, I will try | to compile the list. YES!! I'd be very interested in such a list, both to update the (woeful) LXR homepage at http://lxr.sf.net, and to give us a good idea of who to contact when 1.0 hits the shelves (real soon now, I promise :-) If anyone feels like updating the LXR website, they'd be very welcome... Malcolm -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAj57CTEACgkQNFSEWhVtP3ZWqwCfahjppzw82Ru4ZhRHkjBscKxE MBIAn3/qA96UZEOMRkBLVKyQdRGBK1Pu =il9l -----END PGP SIGNATURE----- |
|
From: Giacomo A. C. <ca...@de...> - 2003-03-21 10:36:13
|
Malcolm Box wrote: > Hi Arne, > > Yes, I do want to publish updates. I'll do that tonight. > > For 0.9.2, I think we might need to look at how all the file accesses > are done, plus what we do with the other untrusted input. The problem is > deciding what the safe set is, because there have been plenty of reports > already that we're too strict in httpwash. > > I think the right thing is to only block ".." and force the filename to > be limited to the source root, and make sure we're not using the open() > call that interprets the filename in any way. > > But really this needs a security audit - any volunteers? If I understand correctly the vulnerability, it happen only because of the expantion on $v and $a, but the all possible values are already stored in some configuration files, so is it simple to chech that $v and $a are in the correct set of values, and that to manually (e.g. a simple string substitution) the variable expantion, instead of the normal perl expantion. BTW, FYI, the vulnerability is a candidate CVE: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0156 BTW I view that some big project use LXR, whould you publish a list of such servers? If you are interested, I will try to compile the list. ciao giacomo |
|
From: Malcolm B. <ma...@br...> - 2003-03-21 10:15:11
|
Hi Arne,
Yes, I do want to publish updates. I'll do that tonight.
For 0.9.2, I think we might need to look at how all the file accesses
are done, plus what we do with the other untrusted input. The problem is
deciding what the safe set is, because there have been plenty of reports
already that we're too strict in httpwash.
I think the right thing is to only block ".." and force the filename to
be limited to the source root, and make sure we're not using the open()
call that interprets the filename in any way.
But really this needs a security audit - any volunteers?
Cheers,
Malcolm
Arne Georg Gleditsch wrote:
>Hi all,
>
>I've been alerted of a vulnerability in LXR 0.3 allowing an attacker
>to read random files on the hosting system as the http user.
>
>I've implemented a stop-gap fix on the lxr.linux.no site by patching
>lib/LXR/Config.pm as follows:
>
>--- lib/LXR/Config.pm 1998/04/30 11:58:17 1.3
>+++ lib/LXR/Config.pm 2003/03/10 09:13:32
>@@ -155,7 +155,9 @@
>
> sub varexpand {
> my ($self, $exp) = @_;
>- $exp =~ s/\$\{?(\w+)\}?/$self->{variable}->{$1}/g;
>+ $exp =~ s{\$\{?(\w+)\}?}{
>+ $self->{variable}->{$1} =~ /^([a-zA-Z0-9\.\-]*)$/ ? $1 : ''
>+ }ge;
> return($exp);
> }
>
>
>It looks like 0.9.2 is vulnerable, as well. Malcolm, do you want to
>publish updates to the download images on the sourceforge site?
>
>
> Arne.
>
>
>-------------------------------------------------------
>This sf.net email is sponsored by:ThinkGeek
>Welcome to geek heaven.
>http://thinkgeek.com/sf
>_______________________________________________
>Lxr-developer mailing list
>Lxr...@li...
>https://lists.sourceforge.net/lists/listinfo/lxr-developer
>
>
>
|
|
From: SourceForge.net <no...@so...> - 2003-03-14 19:34:00
|
Bugs item #703803, was opened at 2003-03-14 10:45 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=703803&group_id=27350 Category: Browsing Group: current cvs Status: Open Resolution: None Priority: 5 Submitted By: Richard Kisley (kisley) Assigned to: Nobody/Anonymous (nobody) Summary: search script glimpsedir path construction spotty Initial Comment: There are really 2 issues I noticed I had to fix to get it to work for me: 1) The 'search' script runs exec on a comma-delimited parameter list. This failed because of path problems, when it still failed I switched it to the familiar '.' Perl notation for string combining and the 'exec' runs fine. My version: exec($config->glimpsebin." -iyn "."-H ".$config->glimpsedir."/".$release." ".$searchtext); 2) The 'search' script and the 'find' script have different glimpsedir paths. Thus if you move all the .glimpsexxx files to .../glimpse/<version>/.glimpsexxx from .../glimpse/.glimpsexxx, so that the 'search' script works, the 'find' script breaks. My version of the block in 'find': unless (open(FILELLISTING,$config->glimpsedir."/".$release."/.glimpse_filenames")) { &warning("Could not open ".$config->glimpsedir."/".$release."/.glimpse_filenames."); return; } (anecdote): both of these changed lines work in my environment. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=390117&aid=703803&group_id=27350 |
6 messages has been excluded from this view by a project administrator.
