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

[Lxr-dev] [ lxr-Bugs-716701 ] $SIG{__WARN__} and mod_perl

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

Bugs item #716701, was opened at 2003-04-07 13:17
Message generated for change (Settings changed) made by mbox
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=390117&aid=716701&group_id=27350

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Browsing
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
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: Malcolm Box (mbox)
Date: 2009-03-26 17:26

Message:
$wwwdebug is now 0 in distribution.

I agree the $SIG{__WARN__} abuse is dubious - but will leave this to
individual sites to remove if wanted.

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

Comment By: Malcolm Box (mbox)
Date: 2004-07-12 18:25

Message:
Logged In: YES 
user_id=215386

I've switched off wwwdebug in the CVS version, but the
underlying problem of the use of global signal handlers is
still there.

Any suggestions for how to remove these would be welcome!

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

Comment By: Pavel Hlavnicka (pavel_hlavnicka)
Date: 2003-04-07 13: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

[Lxr-dev] [ lxr-Bugs-745091 ] Infinite loop when indexing production source trees.

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

Bugs item #745091, was opened at 2003-05-28 19:47
Message generated for change (Comment added) made by mbox
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=390117&aid=745091&group_id=27350

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: genxref
Group: None
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Private: No
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: Malcolm Box (mbox)
Date: 2009-03-26 17:24

Message:
Not chasing links is bad in many environments, so won't apply this
globally.  Checking for being in the same tree is hard - I think the right
approach is to not have source trees which contain circular/infinite loops.

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

Comment By: Richard Munroe (munroe_r)
Date: 2003-05-29 02: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

[Lxr-dev] [ lxr-Bugs-758226 ] Apache 2/ mod_perl 1.99 doesn't work

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

Bugs item #758226, was opened at 2003-06-21 01:19
Message generated for change (Comment added) made by mbox
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=390117&aid=758226&group_id=27350

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Browsing
Group: v0.9.1
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Richard Offer (offer)
Assigned to: Nobody/Anonymous (nobody)
Summary: Apache 2/ mod_perl 1.99 doesn't work

Initial Comment:

LXR 0.9.2 / MySQL / Plain / brand new RH 8.0 box


It seems that LXR uses mod_perl API version 1, Apache 2
required mod_perl version 1.99 (beta for 2) which has
made changes.

>From spending, oh 30 mins looking at this

  Apache::Registry -> ModPerl::Registry

However, mod_perl 2 doesn't chdir() into the scripts
directory, since chdir() affects a whole process, and
Apache 2 can use threads.

In my case, it now fails to find the template file
(html-head.htmls ) files...

I've tried playing with the mod_perl compat interface,
but no luck.

Thanks for any insight you can provide.

richard.

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

>Comment By: Malcolm Box (mbox)
Date: 2009-03-26 17:22

Message:
Fixed with 0.9.6 release which includes multiple patches for improved
Apache2 support

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

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

[Lxr-dev] [ lxr-Bugs-785120 ] apache crash when loading source code file

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

Bugs item #785120, was opened at 2003-08-08 02:42
Message generated for change (Comment added) made by mbox
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=390117&aid=785120&group_id=27350

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Browsing
Group: current cvs
>Status: Pending
>Resolution: Out of Date
Priority: 5
Private: No
Submitted By: Jesse Brandeburg (go_jesse)
Assigned to: Nobody/Anonymous (nobody)
Summary: apache crash when loading source code file

Initial Comment:
I'm using the current CVS lxr, and I have checked in two 
seperate versions of a particular source module.
using
mysql  Ver 11.18 Distrib 3.23.56, for pc-linux (i686)
using CVS

when I try to view that source module's file with 
http://hauler/lxr/source/drivers/net/e1000/e1000_main.c

I get an error_log entry of
Out of memory!
co: output error: Broken pipe
co aborted

Callback called exit (#3)
    (F) A subroutine invoked from an external package 
via call_sv()
    exited by calling exit.

I believe there is some bad stuff going on the with the 
anno array, from the comments that I see when running 
with use diagnostics in the 'source' file.

anno seems to be trying to use the source line as the 
array index, and then assign a lrev to anno[<this is a 
line of source code>]

I believe this could be reproduced by checking in two 
fairly different versions of e1000_main.c (like from kernel 
2.4.21 and 2.6.0-test2) and trying to view one or the 
other from a web browser.

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

>Comment By: Malcolm Box (mbox)
Date: 2009-03-26 17:22

Message:
Can't reproduce this with latest CVS version in LXR, so closing.

If you have a source file that reliably causes this problem, then if you
can post this here I'll take another look.

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

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

[Lxr-dev] [ lxr-Bugs-833149 ] lxr-0.3.1 syntax error in diff.in

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

Bugs item #833149, was opened at 2003-10-30 15:52
Message generated for change (Settings changed) made by mbox
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=390117&aid=833149&group_id=27350

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Browsing
Group: v0.3
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: lxr-0.3.1 syntax error in diff.in

Initial Comment:
lxr-0.3/diff.in includes a perl syntax error (at least, with 
my version of perl).  The attached patch corrects the 
problem locally. 

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

Comment By: Malcolm Box (mbox)
Date: 2009-03-26 17:18

Message:
This bug is unlikely to be fixed in 0.3 as it is no longer being
actively worked on.

Please try to reproduce using the latest development release.  If
you can reproduce it then please update the bug to record this.

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

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

[Lxr-dev] [ lxr-Bugs-855880 ] 0.9.2: problem with virtroot = '/'

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

Bugs item #855880, was opened at 2003-12-07 19:44
Message generated for change (Comment added) made by mbox
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=390117&aid=855880&group_id=27350

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Browsing
Group: None
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Private: No
Submitted By: Schneelocke (arcticwolf)
Assigned to: Nobody/Anonymous (nobody)
Summary: 0.9.2: problem with virtroot = '/'

Initial Comment:
This happens with lxr 0.9.2, running under perl 5.6.1.

Setting the "virtroot" variable, which contains the
local part of the lxr base URL, to '/' in the
configuration file (lxr.conf) when lxr runs from the
top-level directory of a (virtual) host results in
generated links not working anymore; for example, an
expected link target of
"http://lxr.host.domain/source/" becomes
"http://source/src". Setting "virtroot" to '' (empty
string) instead solves the problem.


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

>Comment By: Malcolm Box (mbox)
Date: 2009-03-26 17:17

Message:
Since there's a simple work-around I don't think this needs fixing.

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

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

[Lxr-dev] [ lxr-Bugs-989603 ] Running with a hugh number of source versions.

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

Bugs item #989603, was opened at 2004-07-12 18:49
Message generated for change (Settings changed) made by mbox
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=390117&aid=989603&group_id=27350

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Browsing
Group: current cvs
Status: Open
Resolution: None
>Priority: 3
Private: No
Submitted By: Jan-Benedict Glaw (jbglaw)
Assigned to: Nobody/Anonymous (nobody)
>Summary: Running with a hugh number of source versions.

Initial Comment:
Hi!

This is a whishlist bug.

If you're running with a hugh number of source versions
(think of all linux kernel versions or the like),
showing them
off in the head part takes quite some space. Putting them
into a drop-down list would make it look better.

Thanks, JBG


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

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

[Lxr-dev] [ lxr-Bugs-1047761 ] duplicate entries in lxr_useage

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

Bugs item #1047761, was opened at 2004-10-15 14:01
Message generated for change (Settings changed) made by mbox
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=390117&aid=1047761&group_id=27350

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: genxref
Group: None
>Status: Closed
>Resolution: Works For Me
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: duplicate entries in lxr_useage

Initial Comment:
For some reason running genxref (lxr-0.9.3) duplicate 
entries are being inserted into lxr_useage.

The cross-referencing is all correct, but duplicated!



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

Comment By: Erik Huelsmann (dionisos)
Date: 2005-10-06 06:40

Message:
Logged In: YES 
user_id=664913

Or rather see
http://www.endrun.org/xr/svn/ident?i=svn_io_file_rename

I'll be patching my lxr and resetting the hix.nu db.



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

Comment By: Erik Huelsmann (dionisos)
Date: 2005-10-05 22:34

Message:
Logged In: YES 
user_id=664913

Cross referencing is not exactly duplicated, although it may
look like it is for most items.

This problem occurs when you use the Plain.pm module for
xref-ing with incremental changes. The rev of the file is
determined by its on-disc date, which is different for every
time it changes.

This leads to seemingly duplicate entries in the useage
table all referring to the same file, some to the wrong lines.

For an example, see:
http://hix.nu/subversion/lxr/ident?v=wc-replacements&i=svn_wc_add_repos_file

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

Comment By: Nobody/Anonymous (nobody)
Date: 2004-10-15 14:05

Message:
Logged In: NO 

Interestingly, this does not occur in the older version 0.9.2.

Perhaps a bug has been introduced between versions?

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

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

[Lxr-dev] [ lxr-Bugs-1183103 ] 0 search results with large number of glimpse results

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

Bugs item #1183103, was opened at 2005-04-14 15:54
Message generated for change (Settings changed) made by mbox
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=390117&aid=1183103&group_id=27350

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Browsing
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Malcolm Box (mbox)
Summary: 0 search results with large number of glimpse results

Initial Comment:
when searching for a common word and glimpse is
returning a lot of results (more than maxhits) but a
file name was chosen to search for, lxr is returning 0
search result when the directory containing this file
wasn't reached at this point, although there is perhaps
only one search result in this particular file.

i think its caused by first searching _all_ files for
the word and than comparing it to the file name.

suggestion: when a file name is given, to use the
agrep-version of glimpse.

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

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

[Lxr-dev] [ lxr-Bugs-1691407 ] genxref binary file detection flawed

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

Bugs item #1691407, was opened at 2007-03-30 17:04
Message generated for change (Settings changed) made by mbox
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=390117&aid=1691407&group_id=27350

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: genxref
Group: None
Status: Open
Resolution: None
>Priority: 7
Private: No
Submitted By: Paul D. Smith (psmith)
Assigned to: Nobody/Anonymous (nobody)
Summary: genxref binary file detection flawed

Initial Comment:
Genxref uses File::MMagic to determine what kind of file it's indexing, and that's great.  However, I noticed that a number of binary files in my tree were not being detected properly as "binary".

Looking more closely I see that Perl's File::MMagic module uses an older, less complete table of file types as its hardcoded defaults, which is causing it to not detect some types of non-text files.  However, it turns out that you can tell File:MMagic to use an external definition table for file types rather than the default builtin table.

So, I got the latest version of magic.mime from my Ubuntu system and added it to the LXR directory.  I needed to uncomment one or two lines, which magic.mime had commented out with the note 'Formats for "compress" proper have been moved into "compress.c"', which we don't have in File::MMagic apparently.

This helped a LOT in classifying my files.  It still gets a few wrong, though: apparently its method for detecting binary-ness of files that don't match any of the mime types is more liberal than the file(1) method.  But, this works much better than before (detects .z compressed files, RPMs, etc.)


Patch attached.

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

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

[Lxr-dev] [ lxr-Bugs-2714744 ] Tagger & Plain.pm inefficient

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

Bugs item #2714744, was opened at 2009-03-26 15:43
Message generated for change (Tracker Item Submitted) made by mbox
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=390117&aid=2714744&group_id=27350

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: genxref
Group: current cvs
Status: Open
Resolution: None
Priority: 3
Private: No
Submitted By: Malcolm Box (mbox)
Assigned to: Malcolm Box (mbox)
Summary: Tagger & Plain.pm inefficient

Initial Comment:
Tagger.pm uses Files::tmpfile to get a file for indexing.  In the plain file case, this is created by copying the existing file into a temporary file.  After indexing the temporary file is then deleted.

Should fix the interface from Tagger.pm to Files.pm to simply get a read-only reference to the file, and close it when no longer needed.  Leave it up to Files.pm to worry about where/how it's on the disk.

Alternatively on Unix systems Plain.pm could just create a hardlink and give that back to Tagger.pm, but this isn't portable.

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

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

[Lxr-dev] [ lxr-Bugs-1208448 ] not setting cvspath results in infinite looping

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

Bugs item #1208448, was opened at 2005-05-25 14:29
Message generated for change (Settings changed) made by mbox
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=390117&aid=1208448&group_id=27350

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: SCM support
Group: current cvs
>Status: Closed
>Resolution: Works For Me
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: not setting cvspath results in infinite looping

Initial Comment:
I upgraded my 0.9.3 installation to 0.9.4, and forgot
to set the new variable 'cvsroot' in lxr.conf

Clicking on any of the lxr links after that spawned
many, many perl and diff processes that never ended.
The only way they would end would be to restart the
apache process.

Setting the 'cvsroot' variable fixed these problems.

I believe the solution to this problem is to add a
check in lib/LXR/Files/CVS.pm to see if the variable
'cvsroot' is defined in the configuration, and, if not,
to die with an error message.

I am not logged in. If you need to reach me for comment
use mic...@ge...

Thanks,

Michael Gellman

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

>Comment By: Malcolm Box (mbox)
Date: 2009-03-25 17:30

Message:
There's no cvsroot variable in lxr.conf, so not sure what this defect is
reporting.

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

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

[Lxr-dev] [ lxr-Bugs-1111786 ] Failure to open file not detected

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

Bugs item #1111786, was opened at 2005-01-28 22:52
Message generated for change (Settings changed) made by mbox
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=390117&aid=1111786&group_id=27350

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: SCM support
>Group: current cvs
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Malcolm Box (mbox)
Summary: Failure to open file not detected

Initial Comment:
lxr-0.9.3, perl 5.8.2, running against a CVS tree.

The CVS code restricts the search path for "co"; in my
installation, it wasn't located in that path.  The
check for success running "co" looks at $fileh, but
open() sets $fileh regardless of success.  Instead,
check the return value from open() to determine whether
"co" was run successfully, e.g.

$rtn = open($fileh, "-|", "co -q -p$rev $clean_filename");
die ("...") unless $rtn;
(CVS.pm ca. line 170)

The open was failing silently, so the results from
genxref were all empty files.


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

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

[Lxr-dev] [ lxr-Bugs-1217451 ] lxr.css and CGI script handling mode

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

Bugs item #1217451, was opened at 2005-06-09 09:19
Message generated for change (Settings changed) made by mbox
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=390117&aid=1217451&group_id=27350

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Browsing
Group: current cvs
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Andrea Barbieri (abarbieri)
Assigned to: Malcolm Box (mbox)
Summary: lxr.css and CGI script handling mode

Initial Comment:
Hello,

in LXR v0.9.4 whenswitching .htaccess to be the CGI 
mode one, the lxr.css file generates the following 
apache (v1.3.x and v2.0.x) server error:
file permissions deny server execution: /var/lxr/lxr.css

there is no valid file permissions to resolve  the error.

the root of the problem is in the <Files> section of 
the .htaccess (cgi style):
<Files ~ (find|search|source|ident|diff|cgi-bin)$>
SetHandler cgi-script
ForceType text/html
</Files>

the use of the SetHandler directive forces *all* files to be 
treated as cgi scripts, even the stylesheet file.

a better approach would be to suffix the scripts with .pl 
and use the AddHandler directive.
this way the stylesheet will be treated normally.

many thanks
andrea

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

>Comment By: Malcolm Box (mbox)
Date: 2009-03-23 21:29

Message:
Fixed with update to the .htaccess_cgi file to treat lxr.css as a default
(non-script) file.

Thanks for reporting this - CGI isn't tested as much as it could be!

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

Comment By: Malcolm Box (mbox)
Date: 2005-06-20 23:07

Message:
Logged In: YES 
user_id=215386

I'm having problems reproducing this problem here - I see no
error messages about lxr.css, with ScriptAlias or Alias.

However, I do think there is an error in the installation
instructions in suggesting that the lxr directory should be
ScriptAlias'ed rather than Alias'ed - could those with
either more Apache experience or who have lxr using CGI
running comment on what they are using?

I'm reluctant to change the extensions of all the files, as
that wouldn't appear to be necessary to get Apache to do the
right thing.

Thanks,

Malcolm

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

Comment By: Andrea Barbieri (abarbieri)
Date: 2005-06-17 23:46

Message:
Logged In: YES 
user_id=65472

According to the INSTALL text file it is possible to use 
Apache without the mod_perl (running scrpts as CGI)...

This is why in this configuration ScriptAlias must be used in 
httpd.conf and the .htaccess_cgi renamed to .htaccess.

Only with this setup the problem mention in this thread is 
experienced.

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

Comment By: Ben Gamari (bgamari)
Date: 2005-06-17 14:23

Message:
Logged In: YES 
user_id=97638

I am running apache-2.0.52 and changing the ScriptAlias to a
normal Alias directive has somehow fixed the problem given
that the CGI .htaccess is used.

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

Comment By: Ben Gamari (bgamari)
Date: 2005-06-17 14:22

Message:
Logged In: YES 
user_id=97638

I am running apache-2.0.52 and changing the ScriptAlias to a
normal Alias directive has somehow fixed the problem given
that the CGI .htaccess is used.

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

Comment By: Andrea Barbieri (abarbieri)
Date: 2005-06-10 16:37

Message:
Logged In: YES 
user_id=65472

Hello,

the reason for the posting is actually to get the maintainers of 
the code to properly resolve the issue...

this actually requires a more thoughtful approach ...

and probably changing the involved filenames in all the 
occurrences, deep down in all .pm files will be required ... not 
just at the top level (and in the .htaccess) files

bests
andrea

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

Comment By: gd-smith (gd-smith)
Date: 2005-06-10 04:10

Message:
Logged In: YES 
user_id=1293603

Can I assume this is why I don't see the style sheet
effects, e.g., green bar across top, better file display, etc.?

If so, what files do I need to change to <name>.pl? The ones
listed in the <Files ~(find|...)$>  including source? Do I
need to run genxref again?

Also, how come this seemed to work ok with 0.9.3?

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

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

[Lxr-dev] [ lxr-Bugs-1347560 ] duplicated lxr_useage entries

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

Bugs item #1347560, was opened at 2005-11-03 18:53
Message generated for change (Settings changed) made by mbox
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=390117&aid=1347560&group_id=27350

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: genxref
Group: v0.9.4
Status: Open
Resolution: None
>Priority: 6
Private: No
Submitted By: Jean Mao (qijingmao)
>Assigned to: Malcolm Box (mbox)
Summary: duplicated lxr_useage entries

Initial Comment:
I am using lxr-0.9.2 currently, but I have tried lxr-0.9.4
and which has the same problem. We are using mysql 4.1.7
and plain files.

The 'genxref' creates duplicated lxr_useage entries
when the
source code has something like:

wchar_t *
foo(wchar_t *str, int len, char *ref_f, ...)
{
  va_list va;
    va_start(va,ref_f);

    return( smsg_put_buffer_va(str, len, ref_f, va));
}   /* End of smsg_put_buffer() */

..........

                                foo (buf, K_PATH_SIZE,
"Error reading the logfile:\\n    %0s\\n\\nSelect the
\"Cancel\" button to exit.",
                                filepath);
......
That is, when the next line for calling the function is
really long.

I have dug into the code and found the problem is at
the line 184
of the lib/LXR/Lang/Generic.pm (lxr-0.9.4):
@lines = ($frag =~ /(.*?\n)/g, $frag =~ /([^\n]*)$/);

Where the $frag is end with: "foo (buf, K_PATH_SIZE,"
with carriage return (\n) and code doubled the last line.

Could this be fixed? Please let me know if you have any
questions. Thank you in advance for your help.

Jean


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

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

[Lxr-dev] [ lxr-Bugs-1558177 ] Directories with 2 character names

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

Bugs item #1558177, was opened at 2006-09-13 21:44
Message generated for change (Settings changed) made by mbox
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=390117&aid=1558177&group_id=27350

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Browsing
Group: v0.9.3
>Status: Closed
Resolution: Out of Date
Priority: 5
Private: No
Submitted By: Joe Meadows (jameadows)
Assigned to: Malcolm Box (mbox)
Summary: Directories with 2 character names

Initial Comment:
Using LXR 0.9.3 I noticed that I could not browse into
directories that had two character names (e.g. fs, db,
nc).  I tracked the source of the problem down to this
code in Common.pm, around line 550:

# Clean out /../
while ($path =~ m!/../!) 
{
   $path = s!/\.\./!/!g;
}

I made the change on the first line:
while ($path =~ m!/\.\./!) 
{
   $path = s!/\.\./!/!g;
}

This appears to have fixed the problem for me, but when
it comes to Perl I know just about enough to be
dangerous so it would be good for someone more Perl
saavy check this out.  I think the previous regex
expression was matching any two chars and not the
literal '..' as intended.

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

Comment By: Malcolm Box (mbox)
Date: 2009-03-23 21:24

Message:
Fixed in more recent versions - the fix is exactly as described.   Thanks
for finding this and the fix.

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

Comment By: Joe Meadows (jameadows)
Date: 2006-09-13 21:53

Message:
Logged In: YES 
user_id=941094

This has now been fixed in CVS.

If you can install the new version and check that it solves your
problem, then it would be very useful.

Thanks for reporting this defect and helping to make LXR better.

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

Comment By: Joe Meadows (jameadows)
Date: 2006-09-13 21:53

Message:
Logged In: YES 
user_id=941094

Ah, should have checked v 0.9.5 first, it fixes this bug :)

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

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

[Lxr-dev] [ lxr-Bugs-1558177 ] Directories with 2 character names

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

Bugs item #1558177, was opened at 2006-09-13 21:44
Message generated for change (Comment added) made by mbox
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=390117&aid=1558177&group_id=27350

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Browsing
Group: v0.9.3
Status: Open
>Resolution: Out of Date
Priority: 5
Private: No
Submitted By: Joe Meadows (jameadows)
>Assigned to: Malcolm Box (mbox)
Summary: Directories with 2 character names

Initial Comment:
Using LXR 0.9.3 I noticed that I could not browse into
directories that had two character names (e.g. fs, db,
nc).  I tracked the source of the problem down to this
code in Common.pm, around line 550:

# Clean out /../
while ($path =~ m!/../!) 
{
   $path = s!/\.\./!/!g;
}

I made the change on the first line:
while ($path =~ m!/\.\./!) 
{
   $path = s!/\.\./!/!g;
}

This appears to have fixed the problem for me, but when
it comes to Perl I know just about enough to be
dangerous so it would be good for someone more Perl
saavy check this out.  I think the previous regex
expression was matching any two chars and not the
literal '..' as intended.

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

>Comment By: Malcolm Box (mbox)
Date: 2009-03-23 21:24

Message:
Fixed in more recent versions - the fix is exactly as described.   Thanks
for finding this and the fix.

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

Comment By: Joe Meadows (jameadows)
Date: 2006-09-13 21:53

Message:
Logged In: YES 
user_id=941094

This has now been fixed in CVS.

If you can install the new version and check that it solves your
problem, then it would be very useful.

Thanks for reporting this defect and helping to make LXR better.

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

Comment By: Joe Meadows (jameadows)
Date: 2006-09-13 21:53

Message:
Logged In: YES 
user_id=941094

Ah, should have checked v 0.9.5 first, it fixes this bug :)

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

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

[Lxr-dev] [ lxr-Bugs-1616875 ] Directory with the name of its parent

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

Bugs item #1616875, was opened at 2006-12-16 07:42
Message generated for change (Settings changed) made by mbox
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=390117&aid=1616875&group_id=27350

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Browsing
Group: v0.9.4
>Status: Closed
>Resolution: Works For Me
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Malcolm Box (mbox)
Summary: Directory with the name of its parent

Initial Comment:
In LXR 0.9.4, if a dirctory has the same name as its parent directory, LXR failed to display the content of the directory.

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

>Comment By: Malcolm Box (mbox)
Date: 2009-03-23 21:21

Message:
Works for me against latest CVS - tested using a directory
testdir/testdir/example.c.

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

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

[Lxr-dev] [ lxr-Bugs-1720862 ] Filename with space reports does not exist

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

Bugs item #1720862, was opened at 2007-05-17 10:07
Message generated for change (Comment added) made by dmulter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=390117&aid=1720862&group_id=27350

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: David Multer (dmulter)
Assigned to: Malcolm Box (mbox)
Summary: Filename with space reports does not exist

Initial Comment:
Any files in my CVS repository that contain spaces in the file name, report "file XXX does not exist" when clicking on them in Source Navigation. The actual filename displayed for XXX appears to have the name truncated at the space character.

Not sure if similar problems happen when traversing files like this using Identifier or General Search.

For reference, the file displays correctly when using ViewVC.

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

>Comment By: David Multer (dmulter)
Date: 2009-03-23 10:03

Message:
Appears fixed to me!

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

Comment By: Malcolm Box (mbox)
Date: 2009-03-23 09:45

Message:
This has now been fixed in CVS.

If you can install the new version and check that it solves your
problem, then it would be very useful.

Thanks for reporting this defect and helping to make LXR better.

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

Comment By: Malcolm Box (mbox)
Date: 2009-03-23 09:43

Message:
This has now been fixed in CVS.

If you can install the new version and check that it solves your
problem, then it would be very useful.

Thanks for reporting this defect and helping to make LXR better.

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

Comment By: David Multer (dmulter)
Date: 2007-06-13 16:15

Message:
Logged In: YES 
user_id=1344296
Originator: YES

Problem reported on the latest released source version: 0.9.5 tarball.

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

Comment By: Malcolm Box (mbox)
Date: 2007-06-13 15:47

Message:
Logged In: YES 
user_id=215386
Originator: NO

What version of LXR are you using?  This problem should be fixed in the
latest version in CVS.


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

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

[Lxr-dev] [ lxr-Bugs-1670720 ] ident script fails with MySQL 5 backend

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

Bugs item #1670720, was opened at 2007-02-28 10:45
Message generated for change (Comment added) made by mbox
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=390117&aid=1670720&group_id=27350

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Database interface
Group: current cvs
>Status: Closed
>Resolution: Works For Me
Priority: 5
Private: No
Submitted By: Tyrel Datwyler (tyreld)
>Assigned to: Malcolm Box (mbox)
Summary: ident script fails with MySQL 5 backend

Initial Comment:
The ident script erroneously returns 0 declarations and 0 references when using a MySQL v5 backend. No errors are reported in the web server error log. The ident script works fine when using a MySQL v4 backend.

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

>Comment By: Malcolm Box (mbox)
Date: 2009-03-23 16:53

Message:
Works for me with the latest fixes to make MySQL 5.x backends work.

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

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

[Lxr-dev] [ lxr-Bugs-1691391 ] genxref/swish-e/binary files is VERY inefficient

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

Bugs item #1691391, was opened at 2007-03-30 16:55
Message generated for change (Settings changed) made by mbox
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=390117&aid=1691391&group_id=27350

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: genxref
Group: current cvs
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Paul D. Smith (psmith)
>Assigned to: Malcolm Box (mbox)
Summary: genxref/swish-e/binary files is VERY inefficient

Initial Comment:
I have a number of very large binary files (cross-compilers, etc.) in my source trees, and when I genxref (using swish-e) it sucks up way more CPU/memory/time than I would expect.  I examined the code and found an algorithmic error.

For swish-e, genxref reads the contents of the files into memory (in Perl), THEN it examines the file to determine whether it's binary or not using File::MMagic::checktype_contents().  If the file is determined to be binary (or empty) we skip it.

This is obviously extremely inefficient, since File::MMagic never needs to see the entire file to know its file type: it needs to look at the filename (which it doesn't have here!) and possibly the first 8K or so of the file.

So, I rewrote this section of genxref to get a filehandle for the file, then test to see if it's binary, and only if it's not do we read the contents of the file into memory.  This sped up my genxref significantly and greatly reduced the load on my server during indexing.


Patch from latest CVS attached.

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

>Comment By: Malcolm Box (mbox)
Date: 2009-03-23 16:51

Message:
Thanks for the patch, have applied this to CVS.

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

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

[Lxr-dev] [ lxr-Bugs-1720862 ] Filename with space reports does not exist

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

Bugs item #1720862, was opened at 2007-05-17 18:07
Message generated for change (Comment added) made by mbox
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=390117&aid=1720862&group_id=27350

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: David Multer (dmulter)
Assigned to: Malcolm Box (mbox)
Summary: Filename with space reports does not exist

Initial Comment:
Any files in my CVS repository that contain spaces in the file name, report "file XXX does not exist" when clicking on them in Source Navigation. The actual filename displayed for XXX appears to have the name truncated at the space character.

Not sure if similar problems happen when traversing files like this using Identifier or General Search.

For reference, the file displays correctly when using ViewVC.

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

Comment By: Malcolm Box (mbox)
Date: 2009-03-23 16:45

Message:
This has now been fixed in CVS.

If you can install the new version and check that it solves your
problem, then it would be very useful.

Thanks for reporting this defect and helping to make LXR better.

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

Comment By: Malcolm Box (mbox)
Date: 2009-03-23 16:43

Message:
This has now been fixed in CVS.

If you can install the new version and check that it solves your
problem, then it would be very useful.

Thanks for reporting this defect and helping to make LXR better.

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

Comment By: David Multer (dmulter)
Date: 2007-06-14 00:15

Message:
Logged In: YES 
user_id=1344296
Originator: YES

Problem reported on the latest released source version: 0.9.5 tarball.

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

Comment By: Malcolm Box (mbox)
Date: 2007-06-13 23:47

Message:
Logged In: YES 
user_id=215386
Originator: NO

What version of LXR are you using?  This problem should be fixed in the
latest version in CVS.


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

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

[Lxr-dev] [ lxr-Bugs-1720862 ] Filename with space reports does not exist

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

Bugs item #1720862, was opened at 2007-05-17 18:07
Message generated for change (Settings changed) made by mbox
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=390117&aid=1720862&group_id=27350

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: David Multer (dmulter)
>Assigned to: Malcolm Box (mbox)
Summary: Filename with space reports does not exist

Initial Comment:
Any files in my CVS repository that contain spaces in the file name, report "file XXX does not exist" when clicking on them in Source Navigation. The actual filename displayed for XXX appears to have the name truncated at the space character.

Not sure if similar problems happen when traversing files like this using Identifier or General Search.

For reference, the file displays correctly when using ViewVC.

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

Comment By: Malcolm Box (mbox)
Date: 2009-03-23 16:43

Message:
This has now been fixed in CVS.

If you can install the new version and check that it solves your
problem, then it would be very useful.

Thanks for reporting this defect and helping to make LXR better.

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

Comment By: David Multer (dmulter)
Date: 2007-06-14 00:15

Message:
Logged In: YES 
user_id=1344296
Originator: YES

Problem reported on the latest released source version: 0.9.5 tarball.

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

Comment By: Malcolm Box (mbox)
Date: 2007-06-13 23:47

Message:
Logged In: YES 
user_id=215386
Originator: NO

What version of LXR are you using?  This problem should be fixed in the
latest version in CVS.


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

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

[Lxr-dev] [ lxr-Bugs-1645267 ] problem with MySQL syntax in delete statement

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

Bugs item #1645267, was opened at 2007-01-26 13:01
Message generated for change (Settings changed) made by mbox
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=390117&aid=1645267&group_id=27350

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Database interface
Group: v0.9.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Florian Zschocke (darope)
>Assigned to: Malcolm Box (mbox)
Summary: problem with MySQL syntax in delete statement

Initial Comment:
The genxref, when called with parameter --reindexall, generates MySQL errors when used with a MySQL 5.0 backend.

DBD::mysql::st execute failed: Unknown table 'lxr_indexes' in MULTI DELETE at /usr/share/perl5/LXR/Index/Mysql.pm line 334.
DBD::mysql::st execute failed: Unknown table 'lxr_useage' in MULTI DELETE at /usr/share/perl5/LXR/Index/Mysql.pm line 335.
DBD::mysql::st execute failed: Unknown table 'lxr_status' in MULTI DELETE at /usr/share/perl5/LXR/Index/Mysql.pm line 336.
DBD::mysql::st execute failed: Unknown table 'lxr_files' in MULTI DELETE at /usr/share/perl5/LXR/Index/Mysql.pm line 338.


The problem appeas to lie in the MySQL statements used for "delete_indexes", "delete_useage", "delete_status" and "delete_files" in Mysql.pm.

Between lines 114 and 131 the statements are defined as
"delete from ${prefix}indexes using ${prefix}indexes i, ${prefix}releases r where ...".
This is not working and according to the MySQL manual not correct syntax. Since aliases are used, the alias has to be used with DELETE, too. The correct sytnax (which works for me) would be:
"delete from i using ${prefix}indexes i, ${prefix}releases r where ..."

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

Comment By: Malcolm Box (mbox)
Date: 2009-03-23 13:30

Message:
This has now been fixed in CVS.

If you can install the new version and check that it solves your
problem, then it would be very useful.

Thanks for reporting this defect and helping to make LXR better.

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

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

[Lxr-dev] [ lxr-Bugs-1807357 ] MySQL server has gone away at lib/LXR/Index/Mysql.pm line258

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

Bugs item #1807357, was opened at 2007-10-04 09:08
Message generated for change (Comment added) made by mbox
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=390117&aid=1807357&group_id=27350

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: genxref
Group: v0.9.5
Status: Closed
Resolution: Rejected
Priority: 5
Private: No
Submitted By: aarunendra (aarunendra)
Assigned to: Nobody/Anonymous (nobody)
Summary: MySQL server has gone away at lib/LXR/Index/Mysql.pm line258

Initial Comment:
I am indexing the Biweekly releases. When I ran the genxref on the smaller releases (Size of the release is less) everything is going fine. For larger releases (more in size) initially for couple of release it worked fine. After that following error is coming while running genxref

------------------------------------------------------
DBD::mysql::st execute failed: MySQL server has gone away at lib/LXR/Index/Mysql.pm line 258, <GEN537963> line 201.
DBD::mysql::st fetchrow_array failed: fetch() without execute() at lib/LXR/Index/Mysql.pm line 259, <GEN537963> line 201.
BTYPE was: atom
DBD::mysql::st execute failed: MySQL server has gone away at lib/LXR/Index/Mysql.pm line 258, <GEN537963> line 204.
DBD::mysql::st fetchrow_array failed: fetch() without execute() at lib/LXR/Index/Mysql.pm line 259, <GEN537963> line 204.
DBD::mysql::st execute failed: MySQL server has gone away at lib/LXR/Index/Mysql.pm line 258, <GEN537963> line 204.
DBD::mysql::st fetchrow_array failed: fetch() without execute() at lib/LXR/Index/Mysql.pm line 259, <GEN537963> line 204.
BTYPE was: atom
DBD::mysql::st execute failed: MySQL server has gone away at lib/LXR/Index/Mysql.pm line 258, <GEN537963> line 206.
DBD::mysql::st fetchrow_array failed: fetch() without execute() at lib/LXR/Index/Mysql.pm line 259, <GEN537963> line 206.
BTYPE was: atom
DBD::mysql::st execute failed: MySQL server has gone away at lib/LXR/Index/Mysql.pm line 258, <GEN537963> line 208.
DBD::mysql::st fetchrow_array failed: fetch() without execute() at lib/LXR/Index/Mysql.pm line 259, <GEN537963> line 208.
BTYPE was: atom

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

Identifier search is not working 

Can some one help how to overcome the above problem.

Thanks


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

>Comment By: Malcolm Box (mbox)
Date: 2009-03-23 12:34

Message:
Not a defect in LXR - the Mysql server has crashed.

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

Comment By: Malcolm Box (mbox)
Date: 2009-03-23 12:34

Message:
Not a defect in LXR - the Mysql server has crashed.

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

Comment By: Malcolm Box (mbox)
Date: 2007-10-04 21:45

Message:
Logged In: YES 
user_id=215386
Originator: NO

Looks like your MySQL server has crashed, or the DBI driver to it has lost
the connection.

I suggest checking your mysql logs to see what's happening.


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

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