lxr-developer — Don't use, active developers only

[Lxr-dev] [ lxr-Bugs-471857 ] Failure checking of ectags broken

[<no...@so...>]

Bugs item #471857, was opened at 2001-10-16 13:51
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=390117&aid=471857&group_id=27350

Category: Lang support
Group: current cvs
Status: Open
Resolution: None
Priority: 5
Submitted By: Per Kristian Gjermshus (pergj)
Assigned to: Per Kristian Gjermshus (pergj)
Summary: Failure checking of ectags broken

Initial Comment:
In Generic.pm exuberant-ctags is opened as a pipe with
open().
The the return value of open is checked, but this only
checks if
the fork creating the process was successful. If there
is no
ectags installed or if the invocation went wong no
sensible
error message is displayed. The return value of the
process
should be checked more carefully.

----------------------------------------------------------------------

>Comment By: Malcolm Box (mbox)
Date: 2001-10-17 17:22

Message:
Logged In: YES 
user_id=215386

The implicit fork version of open is "|-" which we don't
use, we use the straight pipe open.  Testing this with

open X, "/usr/bin/not_there" or die "Failed";

reliably prints "Failed" rather than having the fork
succeed.

According to perldoc -f open, there is no more information
in the return value of open() that we could check - it's
undefined if it failed, non-zero (and the pid of the child)
if it succeeded.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=390117&aid=471857&group_id=27350

Re: [Lxr-dev] DB only opened, never closed?

[Malcolm B. <ma...@br...>]

Jan-Benedict Glaw wrote:
> 
> Well, give me that DebugPrintF:-)


You're right, debugging under mod_perl is not so easy.  I think there
are some Apache::* modules that help, but I haven't investigated.

While there's no debugprintf that logs to file (yet!), there is
warning() which dumps stuff out to the web browser and to the server
logs.  I've used this before to track down problems.  grep for "warning"
to see how it's used - it's pretty simple.  

If you set $wwwdebug (top of Common.pm) then it logs to both server logs
and to the browser, otherwise it just dumps to the server logs.

Hope that helps your debugging!  I'm out of diskspace on my laptop so I
can't install psql to investigate this at all - time to get another
machine :-)

Malcolm

Re: [Lxr-dev] $baseurl wierdness

[Malcolm B. <ma...@br...>]

Jens-Uwe Mager wrote:
> 
> I have had some problems getting the style sheet version of lxr going,
> and the problem appears to be the following in html-head.html:
> 
> <base href="$baseurl" >
> 
> In my case I always get what looks like $thisurl substituted. If I put
> in a fixed URL to my LXR installation it works fine.

$baseurl comes from the lxr.conf file - does your lxr.conf set up the
right value?

Does the rest of your configuration work OK?  I've had odd problems when
the $baseurl in the config file didn't match the URL that Apache was
feeding in (FQDN v IP address usually), and that caused all sorts of
strange symptoms.  If $baseurl is not set up properly, most stuff should
be failing.

Cheers,

Malcolm

[Lxr-dev] $baseurl wierdness

[Jens-Uwe M. <ju...@he...>]

I have had some problems getting the style sheet version of lxr going,
and the problem appears to be the following in html-head.html:

<base href="$baseurl" >

In my case I always get what looks like $thisurl substituted. If I put
in a fixed URL to my LXR installation it works fine.
-- 
Jens-Uwe Mager

HELIOS Software GmbH
Steinriede 3
30827 Garbsen
Germany

Phone:		+49 5131 709320
FAX:		+49 5131 709325
Internet:	ju...@he...

[Lxr-dev] Typo in Mysql.pm

[Jens-Uwe M. <ju...@he...>]

The if statement is missing a close parenthesis:

Index: Mysql.pm
===================================================================
RCS file: /cvsroot/lxr/lxr/lib/LXR/Index/Mysql.pm,v
retrieving revision 1.9
diff -u -d -r1.9 Mysql.pm
--- Mysql.pm	2001/10/16 20:25:32	1.9
+++ Mysql.pm	2001/10/17 14:13:04
@@ -32,7 +32,7 @@
 	my ($self, $dbname) = @_;
 
 	$self = bless({}, $self);
-	if(defined($config->{dbpass}) {
+	if(defined($config->{dbpass})) {
 		$self->{dbh} = DBI->connect($dbname, $config->{dbuser}, 
 									$config->{dbpass})
 			|| fatal "Can't open connection to database\n";
-- 
Jens-Uwe Mager

HELIOS Software GmbH
Steinriede 3
30827 Garbsen
Germany

Phone:		+49 5131 709320
FAX:		+49 5131 709325
Internet:	ju...@he...

Re: [Lxr-dev] DB only opened, never closed?

[Jens-Uwe M. <ju...@he...>]

On Wed, Oct 17, 2001 at 09:58:56PM +0900, Malcolm Box wrote:
> Per Kristian Gjermshus wrote:
> > 
> > On Mon, 2001-10-15 at 11:35, Jan-Benedict Glaw wrote:
> > > Every once in a while, I'm looking over the LXR code. Now, this time
> > > I've realized that $index opens a DB (httpinit), but this gets
> > > never closed as far as I see. I'd think that a DB connection
> > > gets opened by a page request, and afterwards closed when this
> > > request is finished. But there seems to be no close, is there?
> > 
> > Right you are. There is a DESTROY method in Mysql.pm but it never gets
> > called. I have made a httpclean sub that is called to clean things up it
> > should be paired with httpinit. I will commit these changes shortly.
> 
> Under mod_perl, do we want to do this?  Because mod_perl keeps one
> script going through several invocations, I think that we want to open
> the db connection at initialisation and only close it when the apache
> server thread dies.  Thus the cost of the connection will be amortised
> over several connections.
> 
> It occurs to me that due to earlier changes this is not what currently
> happens - there is one db connection per instance of $index, rather than
> one for the module, but perhaps it is this that is wrong rather than
> needing cleanup to close everything.

If we use Apache::DBI additionally to DBI than it will be taken care off
automatically under modperl. It will take care of managing persistent
connections for us, we can safely open and close as we need for the
command line/CGI environment.

-- 
Jens-Uwe Mager

HELIOS Software GmbH
Steinriede 3
30827 Garbsen
Germany

Phone:		+49 5131 709320
FAX:		+49 5131 709325
Internet:	ju...@he...

Re: [Lxr-dev] DB only opened, never closed?

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

On Wed, 2001-10-17 15:45:58 +0200, Jan-Benedict Glaw <jb...@lu...>
wrote in message <200...@lu...>:
> I'm willing to spend time, but I'll need assistance:-( I feel there's
> no easy way of debugging under apache/mod_perl (like gdb for C),
> so it would be *very* fine if anybody could give me (or place
> temporary into LXR's lib) something like a DebugPrintF, outputting
> (always to say /tmp/LXR.log) current PID, line number and given
> text message. I'm blameable a total NULLo in Perl (I've tried

...and a precise timestamp would be also fine:-)

MfG, JBG

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

Re: [Lxr-dev] DB only opened, never closed?

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

On Wed, 2001-10-17 15:34:48 +0200, Per Kristian Gjermshus <pe...@if...>
wrote in message <87s...@ly...>:
> * Malcolm Box
> | Under mod_perl, do we want to do this?  Because mod_perl keeps one
> | script going through several invocations, I think that we want to open
> | the db connection at initialisation and only close it when the apache
> | server thread dies.  Thus the cost of the connection will be amortised
> | over several connections.
> | 
> | It occurs to me that due to earlier changes this is not what currently
> | happens - there is one db connection per instance of $index, rather than
> | one for the module, but perhaps it is this that is wrong rather than
> | needing cleanup to close everything.
> 
> Another problem, which I do not know how to solve, is that of the
> libpath issue. I don't understand why the modules are not found, but I
> think it is a rather important problem to fix.

Well, give me that DebugPrintF:-)

MfG, JBG
PS: ...and an example on how to use it...

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

Re: [Lxr-dev] DB only opened, never closed?

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

On Wed, 2001-10-17 21:58:56 +0900, Malcolm Box <ma...@br...>
wrote in message <3BC...@br...>:
> Per Kristian Gjermshus wrote:
> > On Mon, 2001-10-15 at 11:35, Jan-Benedict Glaw wrote:
> > > Every once in a while, I'm looking over the LXR code. Now, this time
> > > I've realized that $index opens a DB (httpinit), but this gets
> > > never closed as far as I see. I'd think that a DB connection
> > > gets opened by a page request, and afterwards closed when this
> > > request is finished. But there seems to be no close, is there?
> > 
> > Right you are. There is a DESTROY method in Mysql.pm but it never gets
> > called. I have made a httpclean sub that is called to clean things up it
> > should be paired with httpinit. I will commit these changes shortly.
> 
> Under mod_perl, do we want to do this?  Because mod_perl keeps one

As long as everything goes well, we don't. But you know I see these
mysterious things here:-) I've upgraded recently to one of those
famous Dual Athlons and kept stress-testing CVS, PostgreSQL and LXR
to quite some amount.

	- PostgreSQL is fine and fast
	- Apache seems to be fine also
	- CVS... Well, CVS itself is fine, but "co" (from RCS)
	  can easily be found in zombi state (which means that
	  ((LXR|mod_perl)|apache) didn't clean up the SIGCHLD.
	- Lang/Generic.pm not found problems with and without
	  this `use lib do { $0 =~ m{(.*)/} ? "$1/lib" : "lib" };'
	  line.

At least I don't know your setups. Mine seems quite normal to me,
except this mapping-to-nothing antry in the maps array (hash?):
	'maps' => {
		'/include/asm-noarch/'	=>	'/include/asm/',
		'/include/asm[^\/]*/'	=>	'/include/asm-$a/',
		'/arch/[^\/]+/'		=>	'/arch/$a/',
	},

Btw., I'm experiencing some formatting failures, but I don't
care much about them currently. These show up like this:

1.1    jbglaw      001   code
                   002   more code
                   003   even more code
004 code is no longer shifted right by some whitespaces:-/
005 code keeps on sitting the left side:-[

This does also happen in "diff" view. When the left file is at it's 
end and the "right" one gets printed on the very left side...

Well, some last words wrt opened DB connections. It's fine to keep
them opened. But LXR should not be within a transaction. Here an
excerpt from "ps axf":

 238 ?        S      0:00 /usr/lib/postgresql/bin/postmaster -D /var/lib/postgres/data
27114 ?        S      0:00  \_ postgres: www-data lxr [local] idle in transaction          
27117 ?        S      0:00  \_ postgres: www-data lxr [local] idle in transaction          
27119 ?        S      0:00  \_ postgres: www-data lxr [local] idle in transaction          
27132 ?        S      0:00  \_ postgres: www-data lxr [local] idle in transaction          
27200 ?        S      0:00  \_ postgres: www-data lxr [local] idle in transaction          
27323 ?        S      0:00  \_ postgres: www-data lxr [local] idle in transaction          
27350 ?        S      0:00  \_ postgres: www-data lxr [local] idle in transaction          
27567 ?        S      0:00  \_ postgres: www-data lxr [local] idle                         
  552 ?        S      0:00  \_ /usr/sbin/sshd
  553 pts/0    S      0:00  |   \_ -bash
  579 pts/0    S      0:00  |       \_ -su
27560 pts/0    S      0:00  |           \_ /usr/lib/postgresql/bin/psql -U www-data -d lxr
  305 ?        S      0:03 /usr/sbin/apache
  324 ?        S      0:04  \_ /usr/sbin/apache
  325 ?        S      0:00  \_ /usr/sbin/apache
  326 ?        S      0:02  \_ /usr/sbin/apache
  327 ?        S      0:00  \_ /usr/sbin/apache
27427 ?        Z      0:00  |   \_ [co <defunct>]
  328 ?        S      0:00  \_ /usr/sbin/apache
27285 ?        Z      0:00  |   \_ [co <defunct>]
27113 ?        S      0:00  \_ /usr/sbin/apache
27284 ?        S      0:00  \_ /usr/sbin/apache
27503 ?        Z      0:00      \_ [co <defunct>]

So there you see that ther seems to be something going on with
the database... I'll try to get some time to search for
BEGIN und COMMIT parts of SQL, but I fear they're hidden
behind Perl's DBI/DBD...

I'm willing to spend time, but I'll need assistance:-( I feel there's
no easy way of debugging under apache/mod_perl (like gdb for C),
so it would be *very* fine if anybody could give me (or place
temporary into LXR's lib) something like a DebugPrintF, outputting
(always to say /tmp/LXR.log) current PID, line number and given
text message. I'm blameable a total NULLo in Perl (I've tried
several times to learn a bit, but I don't understand it. I'm
hacking C for (since?) years no with no problems, but I fail
understanding Perl...). I'd really make use of such a function
(as kind of a break point:-)

Would it be possible to include such a function to CVS?

MfG, JBG

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

Re: [Lxr-dev] DB only opened, never closed?

[Per K. G. <pe...@if...>]

* Malcolm Box
| Under mod_perl, do we want to do this?  Because mod_perl keeps one
| script going through several invocations, I think that we want to open
| the db connection at initialisation and only close it when the apache
| server thread dies.  Thus the cost of the connection will be amortised
| over several connections.
| 
| It occurs to me that due to earlier changes this is not what currently
| happens - there is one db connection per instance of $index, rather than
| one for the module, but perhaps it is this that is wrong rather than
| needing cleanup to close everything.

I must admit that I am not 100% familiar with all the mod_perl
details. What you are saying makes sense to me. If we previously
created a connection to the database for each invocation we must clean
up as I have implemented now. The correct solution seems to be what
you are proposing. I don't know how, but there must be some way to
do initialization at server thread startup.

Another problem, which I do not know how to solve, is that of the
libpath issue. I don't understand why the modules are not found, but I
think it is a rather important problem to fix.

                                             Per Kristian

Malcolm: can you fix so that messages from pk...@ne... goes through
to the mailing list?

Re: [Lxr-dev] DB only opened, never closed?

[Malcolm B. <ma...@br...>]

Per Kristian Gjermshus wrote:
> 
> On Mon, 2001-10-15 at 11:35, Jan-Benedict Glaw wrote:
> > Every once in a while, I'm looking over the LXR code. Now, this time
> > I've realized that $index opens a DB (httpinit), but this gets
> > never closed as far as I see. I'd think that a DB connection
> > gets opened by a page request, and afterwards closed when this
> > request is finished. But there seems to be no close, is there?
> 
> Right you are. There is a DESTROY method in Mysql.pm but it never gets
> called. I have made a httpclean sub that is called to clean things up it
> should be paired with httpinit. I will commit these changes shortly.

Under mod_perl, do we want to do this?  Because mod_perl keeps one
script going through several invocations, I think that we want to open
the db connection at initialisation and only close it when the apache
server thread dies.  Thus the cost of the connection will be amortised
over several connections.

It occurs to me that due to earlier changes this is not what currently
happens - there is one db connection per instance of $index, rather than
one for the module, but perhaps it is this that is wrong rather than
needing cleanup to close everything.

Malcolm

[Lxr-dev] [ lxr-Bugs-471858 ] Some characters in files create trouble

[<no...@so...>]

Bugs item #471858, was opened at 2001-10-16 13:53
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=390117&aid=471858&group_id=27350

Category: Browsing
Group: current cvs
Status: Open
Resolution: None
Priority: 5
Submitted By: Per Kristian Gjermshus (pergj)
Assigned to: Per Kristian Gjermshus (pergj)
Summary: Some characters in files create trouble

Initial Comment:
I have a directory in my source-tree containing the
string
'c-++'. It is not possible to browse these directories.



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=390117&aid=471858&group_id=27350

[Lxr-dev] [ lxr-Bugs-471857 ] Failure checking of ectags broken

[<no...@so...>]

Bugs item #471857, was opened at 2001-10-16 13:51
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=390117&aid=471857&group_id=27350

Category: Lang support
Group: current cvs
Status: Open
Resolution: None
Priority: 5
Submitted By: Per Kristian Gjermshus (pergj)
Assigned to: Per Kristian Gjermshus (pergj)
Summary: Failure checking of ectags broken

Initial Comment:
In Generic.pm exuberant-ctags is opened as a pipe with
open().
The the return value of open is checked, but this only
checks if
the fork creating the process was successful. If there
is no
ectags installed or if the invocation went wong no
sensible
error message is displayed. The return value of the
process
should be checked more carefully.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=390117&aid=471857&group_id=27350

Re: [Lxr-dev] DB only opened, never closed?

[Per K. G. <pe...@ne...>]

On Mon, 2001-10-15 at 11:35, Jan-Benedict Glaw wrote:
> Every once in a while, I'm looking over the LXR code. Now, this time
> I've realized that $index opens a DB (httpinit), but this gets
> never closed as far as I see. I'd think that a DB connection
> gets opened by a page request, and afterwards closed when this
> request is finished. But there seems to be no close, is there?

Right you are. There is a DESTROY method in Mysql.pm but it never gets
called. I have made a httpclean sub that is called to clean things up it
should be paired with httpinit. I will commit these changes shortly. 

                                                 Per Kristian

[Lxr-dev] DB only opened, never closed?

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

Hi!

Every once in a while, I'm looking over the LXR code. Now, this time
I've realized that $index opens a DB (httpinit), but this gets
never closed as far as I see. I'd think that a DB connection
gets opened by a page request, and afterwards closed when this
request is finished. But there seems to be no close, is there?

MfG, JBG

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

[Lxr-dev] [ lxr-Bugs-428514 ] cgi scripts only run under mod_perl

[<no...@so...>]

Bugs item #428514, was opened at 2001-05-29 18:19
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=390117&aid=428514&group_id=27350

Category: Browsing
Group: None
Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: Malcolm Box (mbox)
Assigned to: Nobody/Anonymous (nobody)
Summary: cgi scripts only run under mod_perl

Initial Comment:
There doesn't seem to be a good reason to require these
scripts to run under mod_perl only (although it has
obvious performance improvements).  Not requiring
mod_perl would enable other webservers/platforms to be
used more easily

----------------------------------------------------------------------

Comment By: Jan-Benedict Glaw (jbglaw)
Date: 2001-10-09 02:11

Message:
Logged In: YES 
user_id=308126

Well, there's one more thing which would better done in
separated processed (than in this wuss of mod_perl scripts).
For example, I think quite some of my "lib not found"
problems wouldn't occure in running separately. These errors
tend to resolve when I request the page as often as needed
to get the initial apache worker process...

----------------------------------------------------------------------

Comment By: Malcolm Box (mbox)
Date: 2001-10-08 22:42

Message:
Logged In: YES 
user_id=215386

The workaround suggested below will work for those that
care, and it's not worth renaming everything in the main tree.

----------------------------------------------------------------------

Comment By: Malcolm Box (mbox)
Date: 2001-05-29 19:37

Message:
Logged In: YES 
user_id=215386

Moving this to later unless anyone is really bothered by
having to have mod_perl.

----------------------------------------------------------------------

Comment By: Malcolm Box (mbox)
Date: 2001-05-29 19:35

Message:
Logged In: YES 
user_id=215386

More investigation:

Removing the print "HTTP/1.0 200 OK" line from printhttp (in
Common.pm) allows the scripts to run under CGI without
problems, but then running under Apache::Registry causes
some HTTP headers to show up in the HTML.

Probably the correct solution for CGI at the moment is to
rename the scripts to nph-* so that they can issue the HTTP
headers directly (as they do under Apache::Registry). 
Currently I can find no way to switch mod_cgi into nph mode
for all/selected files.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=390117&aid=428514&group_id=27350

[Lxr-dev] [ lxr-Bugs-428514 ] cgi scripts only run under mod_perl

[<no...@so...>]

Bugs item #428514, was opened at 2001-05-29 18:19
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=390117&aid=428514&group_id=27350

Category: Browsing
Group: None
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Malcolm Box (mbox)
Assigned to: Nobody/Anonymous (nobody)
Summary: cgi scripts only run under mod_perl

Initial Comment:
There doesn't seem to be a good reason to require these
scripts to run under mod_perl only (although it has
obvious performance improvements).  Not requiring
mod_perl would enable other webservers/platforms to be
used more easily

----------------------------------------------------------------------

>Comment By: Malcolm Box (mbox)
Date: 2001-10-08 22:42

Message:
Logged In: YES 
user_id=215386

The workaround suggested below will work for those that
care, and it's not worth renaming everything in the main tree.

----------------------------------------------------------------------

Comment By: Malcolm Box (mbox)
Date: 2001-05-29 19:37

Message:
Logged In: YES 
user_id=215386

Moving this to later unless anyone is really bothered by
having to have mod_perl.

----------------------------------------------------------------------

Comment By: Malcolm Box (mbox)
Date: 2001-05-29 19:35

Message:
Logged In: YES 
user_id=215386

More investigation:

Removing the print "HTTP/1.0 200 OK" line from printhttp (in
Common.pm) allows the scripts to run under CGI without
problems, but then running under Apache::Registry causes
some HTTP headers to show up in the HTML.

Probably the correct solution for CGI at the moment is to
rename the scripts to nph-* so that they can issue the HTTP
headers directly (as they do under Apache::Registry). 
Currently I can find no way to switch mod_cgi into nph mode
for all/selected files.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=390117&aid=428514&group_id=27350

[Lxr-dev] [ lxr-Bugs-469413 ] Non-symbols can be mistaken for symbols

[<no...@so...>]

Bugs item #469413, was opened at 2001-10-08 22:38
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=390117&aid=469413&group_id=27350

Category: Database interface
Group: current cvs
Status: Open
Resolution: None
Priority: 3
Submitted By: Malcolm Box (mbox)
Assigned to: Malcolm Box (mbox)
Summary: Non-symbols can be mistaken for symbols

Initial Comment:
When marking up source code, each possible string is
checked to see if it is a symbol, by calling
issymbol().  The implementations in Mysql.pm and
Postgres.pm only use the string to lookup whether this
is a symbol.

Unfortunately it is possible that in one release a
string is a symbol, while in another it is not.  Since
the release of the file being looked at is not taken
into account, the current algorithm will highlight
symbols that, when clicked on, will return "Not used".

The solution is to change issymbol to do:

select s.symid from symbols s, releases r, indexes i
where s.symname = 'name' and i.symid = s.symid and
i.fileid = r.fileid and r.release = 'release';

This is not much slower, and the results could be cached.

Note that is problem shows up only rarely, since it is
unusual to have a string that both resembles an
identifier (not a reserved word, not a string/include
token) but matches a symbol name in another release. 
The easiest way to show it up is to look at the source
of a release that has not be indexed yet.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=390117&aid=469413&group_id=27350

[Lxr-dev] $SIG{__DIE__} considered harmful in a mod-perl environment?

[Jens-Uwe M. <ju...@he...>]

I have been chasing a strange error in my installation for a while that
I finally nailed down today. Occasionally users did mention to me that they
see strange error messages in their HTML pages that do mention they are
generated by LXR even though they are not on any page that is generated
by LXR. I do use also HTML::Embperl and other perl modules so most of
the pages do use some perl in any case, and I found that some pages use
eval statements to check for availability of modules.

If LXR happened to run once in that particular httpd then the problem
occurs that LXR happens to issue error messages for failing eval
statements even though it is not really associated to these. This
happens as mod-perl does implement a shared interpreter for all the
scripts, and some of the interpreter resources are shared across all
scripts loaded into mod-perl. In particular here the problem is httpinit
in LXR::Common.pm, which does modify (pseudo) signal handlers:

sub httpinit {
        $SIG{__WARN__} = \&warning;
	$SIG{__DIE__}  = \&fatal;

These are shared across all scripts and thus fatal or warning gets
called even though LXR is not processing a request currently. Would it
be possible to get around without setting these signal handlers? Looking
into the mod-perl mailing list archive it looks like this usage is
considered harmful in the mod-perl environment.

-- 
Jens-Uwe Mager

HELIOS Software GmbH
Steinriede 3
30827 Garbsen
Germany

Phone:		+49 5131 709320
FAX:		+49 5131 709325
Internet:	ju...@he...

[Lxr-dev] Re: [Lxr-commits] CVS: lxr CREDITS.txt,NONE,1.1

[Malcolm B. <ma...@br...>]

Sorry about that - I'll let you patch it then, shall I :-)

Malcolm

Peder O. Klingenberg wrote:

>Malcolm Box <mb...@us...> writes:
>
>>Peder O. Klingenberg <pe...@kl...>
>>
>                                      ^
>klingenberg.no, actually :)
>
>...Peder...
>

Re: [Lxr-dev] Re: [ lxr-Bugs-455480 ] Diff. btwn. --allversions and --version=

[Malcolm B. <ma...@br...>]

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

[Lxr-dev] Re: [ lxr-Bugs-455480 ] Diff. btwn. --allversions and --version=

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

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

[Lxr-dev] Re: [ lxr-Bugs-455480 ] Diff. btwn. --allversions and --version=

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

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

[Lxr-dev] [ lxr-Bugs-453387 ] variable 'v' range

[<no...@so...>]

Bugs item #453387, was opened at 2001-08-20 07:58
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=390117&aid=453387&group_id=27350

Category: genxref
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Pavel Hlavnicka (pavel_hlavnicka)
Assigned to: Peder O. Klingenberg (pok)
Summary: variable 'v' range

Initial Comment:
I downloaded devel version 0.8 (no group available :)

If you use the commented out example in the lxr.conf
how to set the range of the variable 'v' it doesn't work.

First, at the line 74 in genxref is this variable
accesed  directly, there should be
@versions->varrange('v') I guess.

Second, after hacking this line it still doesn't work,
because the $LXR::Common::pathname (used in lxr.conf)
is not set at the time of the execution. I've no clue,
what was the original author's intention :)
It seems, that the range sould be read once per
processed file, because the releases (probably) and
revisions (for sure) may differ for each file. But I
didn't read the code so carefully to be sure.

HTH

----------------------------------------------------------------------

Comment By: Joseph Wilhelm (tarken)
Date: 2001-09-26 08:13

Message:
Logged In: YES 
user_id=326177

Okay.. as far as I know, this is complete.  I took the list 
of reserved words from the list on php.net.

'php' => {
		  'reserved' => 
['and','$argv','$argc','break','case','class',
					
	 'continue','default','do','die','echo','else',
					
	 'elseif','empty','endfor','endforeach','endif',
					
	 'endswitch','endwhile','E_ALL','E_PARSE','E_ERROR',
					
	 'E_WARNING','exit','extends','FALSE','for','foreach
',
					
	 'function','HTTP_COOKIE_VARS','HTTP_GET_VARS',
					
	 'HTTP_POST_VARS','HTTP_POST_FILES','HTTP_ENV_VARS',
					
	 'HTTP_SERVER_VARS','if','global','list','new','not'
,
					
	 'NULL','or','parent','PHP_OS','PHP_SELF','PHP_VERSI
ON',
					
	 'print','return','static','switch','stdClass',
					
	 'this','TRUE','var','xor','virtual','while','__FILE
__',
					
	 '__LINE__','__sleep','__wakeup'
						],
		  'spec' => ['comment',  '/\*',       '\*/',
				
	 'comment',  '//',            "\$",
				
	 'comment',  '#',             "\$",
				
	 'string',   '"',             '"',
				
	 'string',   "'",             "'",
				
	 'include',  'require',      "\$",
				
	 'include',  'include',      "\$",
				
	 'include',  'require_once', "\$",
				
	 'include',  'include_once', "\$"
					],
		},


----------------------------------------------------------------------

Comment By: Malcolm Box (mbox)
Date: 2001-09-26 02:33

Message:
Logged In: YES 
user_id=215386

Is there any chance you could post the stuff you added to
generic.conf to get php working?  I'm trying to flesh the
file out, since it currently doesn't support a lot of the
languages that ctags can cope with.

----------------------------------------------------------------------

Comment By: Joseph Wilhelm (tarken)
Date: 2001-09-17 13:48

Message:
Logged In: YES 
user_id=326177

Hmm, on my last follow-up to this, perhaps it didn't work 
properly.  I added a 'php' entry to generic.conf so that 
everything should work great in my PHP files... but I'm not 
getting any cross-references on functions or anything else. 
All I'm getting them on is require()'ed files in the 
current directory.  Also, I looked at the lxr database in 
MySQL... and it's completely empty.  Perhaps this is 
evidence that genxref didn't do quite what it was supposed 
to? :)

----------------------------------------------------------------------

Comment By: Joseph Wilhelm (tarken)
Date: 2001-09-17 12:53

Message:
Logged In: YES 
user_id=326177

Actually I got this fixed on my copy by making the line 
look like this:
    @versions = eval($config->{variables}{v}{range});
Instead of:
    @versions = @{$config->{variables}{v}{range}};

And it's working perfectly now :)

----------------------------------------------------------------------

Comment By: Peder O. Klingenberg (pok)
Date: 2001-08-20 11:17

Message:
Logged In: YES 
user_id=222352

See patch 453450.

----------------------------------------------------------------------

Comment By: Peder O. Klingenberg (pok)
Date: 2001-08-20 10:59

Message:
Logged In: YES 
user_id=222352

No, it doesn't work at the moment, because genxref is
broken.  I have fixed it, but the patch has not been
committed yet.  Your hunch is correct, it's intended to be
called per file.

Stay tuned.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=390117&aid=453387&group_id=27350

[Lxr-dev] [ lxr-Bugs-455480 ] Diff. btwn. --allversions and --version=

[<no...@so...>]

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