On Fri, Jun 12, 2009 at 8:46 AM, Tim Bunce<[email protected]> wrote:
>
> On Fri, Jun 12, 2009 at 04:07:42PM +0100, Martin Evans wrote:
>> Just realised I may have sent this originally to an address you don't
>> use. If you've seen it already - sorry.
>
> Not so much "don't use" as "don't read". My [email protected] copies
> my emails to [email protected] so I can use gmail as my "searchable
> remote email archive", but I don't read emails that are sent directly there.
>
>> Hi Tim,
>>
>> I'm getting a lot of these. I am unsure whether to rt this so decided to
>> run it by you first. I found a reference in the HACKING file saying:
>>
>> Investigate and fix "Unable to determine line number" cases. Here's one:
>>
>> $ NYTPROF=begin=1:blocks=1:trace=1 perl -d:NYTProf -Mstrict -e 1
>>
>> and tried setting NYTPROF as above and I get:
>>
>> NYTPROF=begin=1:blocks=1:trace=1 perl -d:NYTProf -MCarp=verbose -I
>> /home/martin/bet/tools/modules/BET/lib/ -t refreshd.pl
>> Unknown NYTProf option: 'begin' <--------- notice
>
> I'll update the HACKING file, it's a bit dated. Thanks.
>
>> # trace=1
>> NYTProf init pid 5037, clock 1
>> Opened nytprof.out
>> NYTProf enable_profile (previously disabled) to nytprof.out at
>> /usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/Devel/NYTProf.pm
>> line 43.
>> Unable to determine line number in refreshd.pl.
>> NYTProf pid 5037: first statement line 0 of refreshd.pl.
>> Unable to determine line number in refreshd.pl.
>> Unable to determine line number in refreshd.pl.
>> Unable to determine line number in refreshd.pl.
>> Unable to determine line number in refreshd.pl.
>>
>> Is there something I can do to track these down?
>
> It probably requires wading deep into the guts of perl.
> If this means anything to you then you've got a hope:
>
> /* Might be a cop that has been optimised away. We can try to find such a
> * cop by searching through the optree starting from the sibling of PL_curcop.
>
> I've been working on the basis that I'll ignore it till someone
> complains. I guess you just have!
I have the theory that this has something to do with a use() line
since my real theory is that no dbstate or nextstate ops have fired
yet and therefor you have no "current" line yet. As an example, here's
a very short program. It's stored as a tree with pointers to the
"next" thing to run, the node's sibling and the node's first child.
The walking around stuff is that when at say "print" you have to walk
some "next" pointers to go upwards in the tree, then proceed downward
with child and sibling to find the nextstate op that precedes it.
[jbenj...@das1 ~]$ perl -MO=Concise -e 'print "hi"'
leave
enter
nextstate(main 1 -e:1)
print
pushmark
const "hi"
[jbenj...@das1 ~]$ perl -MO=Concise,-exec -e 'print "hi"'
enter
nextstate(main 1 -e:1)
pushmark
const "hi"
print
leave
Usually you've gotten around to executing some nextstate (or dbstate
when in the debugger) op and that's how the runtime knows what line
and file you're at when writing warnings and such.
I'm just guessing that somehow you've gotten to do some work without
ever hitting any normal line that actually has a line number. Or maybe
you're doing significant work in a command line -M invocation?
Josh
--~--~---------~--~----~------------~-------~--~----~
You've received this message because you are subscribed to
the Devel::NYTProf Development User group.
Group hosted at: http://groups.google.com/group/develnytprof-dev
Project hosted at: http://perl-devel-nytprof.googlecode.com
CPAN distribution: http://search.cpan.org/dist/Devel-NYTProf
To post, email: [email protected]
To unsubscribe, email: [email protected]
-~----------~----~----~----~------~----~------~--~---
