#22 Lost functionality from previous versions

Support needed

In last version I used (0.9.10) it worked fine. Now I jumped to 1.2.0 and noticed couple of things and cannot understand whether it is a bug or just I misconfigured LXR:

1) While viewing directory list all files have 'Not valid' in 'Last indexed' column.
2) When viewing file I have on top message in red : "Warning, cross-references for /DIR1/DIR2/FILE_NAME.c need to be fixed."
3) When I click on some link in the text of file in previous version it showed on top first small table with prototypes and definitions and lower it showed table with all places in files where it is used. Now it shows only first top table. To get second table I need to put function/variable name in 'General search' -> 'Or containing' and then I have it. And honestly from my point of view it was MOST USEFUL feature of LXR. And now I need to do it manually all time.

Please advice.



  • Andre-Littoz

    Hi, I am away for some days and won't be back before next mid-week.

    Here are short comments.

    0.9.10 -> 1.2.0 is a big leap. An intermediate release introduced an incompatibility in the cross-reference database (new tables and field changes in existing tables) and your problems may come from this. This is mentioned in doc/CHANGES (but reading this log is boring, I know).

    Symptom 1: 'Not valid' means last-modified-date of file is younger then last-LXR-indexation date (a file has changed since genxref was last run).

    If you installed the new LXR and kept the database, last indexation time defaults to 0, i.e. Linux epoch = 1 january 1970, older than any last-modified-date.

    Symptom 2: identical to #1, gives a reminder to run genxref to update the cross-references.

    Symptom 3: I don't understand exactly what's going on (I'm away and can't test) because it should not happen. If you kept the old DB, there's a discrepancy between the expected schema and the actual schema, but the queries should return something, be it garbage or inexact cross-references.

    And I agree with you, this data display is the distinctive LXR feature and is always maintained as core part in LXR.

    My recommendation:

    lxr.conf could be kept unchanged (this will no longer be true with the next release -- one new parameter added to give more robust tree selection in the URL, multiple-trees context). But, save it somewhere.

    Run ./scripts/configure-lxr.pl. This will create a DB description and a new lxr.conf and replace .htaccess (caution if you customized it!). Run ./custom.d/initdb.sh to create DB (erasing the old one) with the new tables. Finally, run ./genxref to load the DB with cross-references.

    Sorry if your project is a very big one (the genxref step lasts a few hours on the Linux kernel but you can launch it as a night run).

    I suggest you download the User's Manual corresponding to your LXR version.

    Better information as soon as I'm back.

  •  tarela_v

    Hello Andre,

    even though I am not power user I've been using LXR several years, so I understand problems with different databases. I did not use old database, I created new one and as I remember difference is only in one new field. So, my steps when I make ANY differences in sources or install new version of LXR are:

    1) Delete all files created by glimpse

    2) Login to MySQL and delete my LXR database.

    3) Stop MySQL and delete all /var/lib/MySQL/ib*

    4) Start MySQL, check /var/lib/MySQL

    5) Run script to create LXR database

    6) Run genxref.

    I run it usually during the night time since it takes about 6 hours to process everything. I have a lot of different products there, including 2 different kernel sources.

    I usually look through User's manual with every new version, but so far everything is the same.

    Do you see any problems in my steps above??

    Do you need any Apache error logs when I am using LXR???



    Last edit: Andre-Littoz 2013-09-11
  • Andre-Littoz

    Hello Val, I'm back.

    Your procedure is very safe, maybe overkill, but it does not harm.

    Step 1: I think it is done by glimpse. Anyway, I never did it and had no trouble.

    Step 2: was necessary in 0.9.x as a fail-safe measure; is now included in initdb.sh (first call to mysql with 'drop database' statement).

    Step 3: overkill in my opinion but does not harm and even protects against possible changes in MySQL upgrades.

    Steps 4 & 5: I never stopped/restarted mysqld when doing maintenance tasks on the DB and all went fine. But, again, it does not harm to be very careful.

    Steps 5 & 6: the true LXR steps; should be sufficient as such; if not, report to help improve the configuration wizard.

    Back to the identifier search malfunction

    If you get only the first table (definitions), see if the 'Definitions only' checkbox is checked or if the URL has a query string with ?_identdefonly=1 or if lxr.conf contains parameter 'identdefonly' => 1.

    In the last 2 cases, how did you happen to get them?

    If the cause is in the DB, there is very little debugging information available from genxref. You can try looking at the global DB info with phpMyAdmin (number of records in each table; usually usages >> definitions and definitions > symbols).
    If it is an LXR script (or library) malfunction, you may have an error logged. Tell me if you read something unusual ('Script xxx did not send HTTP headers' is a frequent transient bad condition solved by reloading the page after purging the browser cache; it is not relevant to your case).


  •  tarela_v

    Hello Andre,
    thanks for your help.
    1) In lxr.conf line with identdefonly is commented out. Did not understand about first table (definitions). Where exactly and what should I check?
    2) In apache error logs I can see messages like:
    error.log:[Tue Sep 10 17:28:22 2013] fatal: ModPerl::ROOT::ModPerl::Registry::usr_local_lxr_source, line 747: Software caused connection abort at /usr/local/lxr/source line 747, <GEN283> line 394.error.log.1:[Wed Sep 4 14:04:32 2013] fatal: ModPerl::ROOT::ModPerl::Registry::usr_local_lxr_source, line 747: Software caused connection abort at /usr/local/lxr/source line 747, <GEN302> line 252.
    and in access logs I see messages like
    [Tue Sep 10 17:28:01 2013] [warn] /ife/search did not send an HTTP header[Tue Sep 10 17:28:22 2013] [warn] /ife/source/VOB_IFE_AVI/AVI_AvServer/SRC/AVI_AvServerRtsp.c did not send an HTTP header
    3) I am trying to install phpMyAdmin, since I am using MySQL only for LXR

    Last edit: Andre-Littoz 2013-09-13
  • Andre-Littoz

    Hello Val,

    1) By design, you can limit identifier search to definitions only (through the check box, configuration parameter 'identdefonly' or URL argument ?_identdefonly=1) instead of full report (definitions + usages). This is why I was wondering if some misconfiguration was blocking usages display. Apparently, something else is wrong.

    Did you create lxr.conf manually or through the configuration wizard?

    2) Error location at source, line 747 is strange. It is a simple print statement. The preceding line contains a sub call, but in this case (plain files) the sub always returns undef. May it be a transient condition? (because LXR interacts with Apache only through print statement: a line is passed to Apache to be sent into the network under HTTP protocol)

    'did not send an HTTP header' is definitely a transient condition. It can be cleared by flushing the browser cache and refreshing the page (resetting the HTTP automaton to a normal state). If you really want to play it safe, you can also restart the Apache server before reloading the page. When developing (or debugging), it is a clue to something more serious: some user data is sent before or within the HTTP headers. This should not happen with the released version (global variable $wwwdebug in Common.pm is set to 0).

    3) LXR also supports PostgreSQL and SQLite. If these DB engines are installed on your computer, you can use one of them. It is only a matter of choice with the configuration wizard. To peek into the DB, there are tools like phpPgAdmin and SQLiteMan.