right usage of #line ??

[jjmoka]

This is native code of mod_perl:

ModPerl::RegistryCooker::get_mark_line     ()
sub get_mark_line {
    my $self = shift;
    $ModPerl::Registry::MarkLine ? "\n#line 1 $self->{FILENAME}\n" : "
+";
}

So #line is fixed to 1. That $line, as it is, is joined with other stuff to build an $eval (in the same file, method:  sub convert_script_to_compiled_handler { ( code ):

    my $eval = join '',
                    'package ',
                    $self->{PACKAGE}, ";",
                    "sub handler {",
                    "local \$0 = '$script_name';",
                    $nph,
                    $shebang,
                    $line, <------------------------------
                    ${ $self->{CODE} },
                    "\n}";

Anyhow it doesn't (always) work. With Apache::DB (the Perl debugger under mod_perl), The value 1 NEVER works on the FIRST file which is loaded. But it works magically if I step into another file, and still doesn't work when I return back in the first file. After this hint which suggested to write the 'next' line, I found that in my case it worked changing the value from 1 to 3 (2nd line was the shebang and 2 didn't work either). But in other cases, where the first loaded file is different I didn't find any working value. Usually I focus on MY code, to start searching where the problem is. Here I'm wondering what's wrong. Any idea or previous experience on this, are both welcome.

[LanX]

> Any idea or previous experience on this, are both welcome.

Just an idea: I seem to remember that perl5db.pl is using a hash to associate line numbers and op tree entries source lines for caching.

Line 3 will point to the #shebang line which has no conflicts (comments are never compiled)

Having multiple sequences of op-codes with the same line number is not only bad practice but a bug in my books.

PLEASE use a linenumber/file pointing to a reasonable code explaining what is happening.

The debugger will just show the static lines found in the file system.

It will not try to deparse your evaled code.

[jjmoka]

I'm delighted of the feedback. Thanks. It's not my main activity but I'm investigating this topic by a while. Now I found some workaround (fixing #line) so that I can have a quite effective remote debugging session. But I'm interested to fix it definitely and understand the problem. Besides starting to add a first question on this site ( here ), I then provided a more detailed question here but I got no solution.

I'm just trying to use 2 old (and I so guess stable-enough) modules, mod_perl and Apache::DB. Even developed by the same author, Doug MacEachern, so I believe they should understand each other. I'm running them out of the box. MY code is only the 4 lines snipped shown, just to see them working as expected for the most simple case.

So the lab is this:

1. have Apache and mod_perl

2. have module Apache::DB

3. use the most simple httpd.conf. Mine is this

4. excute Apache in not-forking mode httpd  -X -DPERLDB -f simple.httpd.conf

5. point your browser to your snippet

6. go to your new fresh debug prompt, arisen magically in the shell of point 4

7. step-step-step-step ... till reaching the sub default_handler of mod_perl

(all will happen inside mod_perl, the file ModPerl::RegistryCooker )

       A) sub default_handler {
          |
       B) |___| $rc = $self->convert_script_to_compiled_handler;
              |       |
              |       |___|  ....
       C)     |           | my $line = $self->get_mark_line;
       D)     |           | my $eval = join '' .....   <------ the joi
+n shown in my opening question above
       E)     |           | $rc = $self->compile(\$eval);
              |           |              |__
              |           |                 | ....
       F)     |           |                 |  eval $$eval;  <----- tr
+anslated in   return $self->error_check;
              |           |                 |
              |           |
       G)     |           | $self->cache_it;
              |
       H)     | $rc = $self->run;
              |              | ....
       I)     |              | eval { $cv->($r, @_) };  ------->   JUM
+P INTO USER CODE  (here #line will not be understood)

I much appreciate the work of sir MacEachern, as it's a complex matter, but it shouldn't be such a pain to turn them on, after having simplifed your code to 4 lines (shebang, and print CGI header included!, ... so 2 lines). Why that #line is so difficult to understand ? Moreover as already linked (here again) , I found some different opinion on how it should be used so the fixed #line 1 in mod_perl code is on a different choice..... that incidentally does not work so well :)

[jjmoka]

I found a working solution. I post it here, in case others will join this page from Google, one day. Instead of trying to fix the #line issue, I decided to work around those evals. The 'evaled' code is not properly stored in Symbol Tables (much on this can be found also on this site). As the problem is always on the first entering file, I made a wrapper.pl of 2 lines, giving the problem to it, and having my code clean:

 require '/home/jjmoka/TEST/code/test2.pl'
 $DB::single=2;

This worked both for the simplest example, and for my real production use case (with the proper path in the require).

[Anonymous Monk]

This is native code of mod_perl: ...ModPerl::RegistryCooker... Anyhow it doesn't (always) work. With Apache::DB (the Perl debugger under mod_perl), .. Usually I focus on MY code, to start searching where the problem is. Here I'm wondering what's wrong. Any idea or previous experience on this, are both welcome.

??Why not set a breakpoint in the code manually ? $DB::single=2; ## breakpoint

??Do you grok CGI to mod_perl Porting. mod_perl Coding guidelines??

[Anonymous Monk]

Thanks Monk. Breakpoints work already. Is the number of line that is not agreed between what mod_perl writes down (fixed #1) and what the Apache::DB tries to understand. The following 4 lines snippet makes it clear:

 1 #!/usr/bin/perl
 2 my $a=2;
 3 print "Content-type: text/plain\n\n";
 4 print "$a\n";

$my eval is 'evaluated' by mod_perl as:

   
   package ModPerl::ROOT::ModPerl::PerlRun::home_jjmoka_TEST_code_test
+2_2epl;sub handler {local $0 = '/home/jjmoka/TEST/code/test2.pl';
   #line 1 /home/jjmoka/TEST/code/test2.pl
   #!/usr/bin/perl
   my $a=2;
   print "Content-type: text/plain\n\n";
   print "$a\n";

And that doesn't work. In that case I must fix "#line 1" to "#line 3", and the debugger is able to step each line normally. With any other value X different from 3 "#line X" I see only blank lines on each step. Anyhow 3 is not the solution for every snippet I decide to submit.