On Mon, Feb 08, 2010 at 10:24:14PM +0000, Tim Bunce wrote: > On Mon, Feb 08, 2010 at 11:32:24AM +0000, Nicholas Clark wrote: > > On Sun, Feb 07, 2010 at 11:02:11AM -0800, Ivan Fomichev wrote: > > > On 14 ??????, 17:03, hhaldn <[email protected]> wrote: > > > > > > > I try to merge 2 datafiles generated undermod_perl, I get an error: > > > > > > I have the same problem. > > > > > > Reading tmp/nytprof.out.1144 > > > unknown eval_fid 9 at /usr/local/bin/nytprofmerge line 206 > > > main::__ANON__('NEW_FID', 8, 9, 1, 34, 0, 0, '(eval 4)') called at / > > ^ ^ > > | file ID for the container of this eval > > | > > file ID for this eval > > > > > What can be the root of the problem? Is there an instant workaround? > > > > I don't know what the root is. > > > > (Other than what the message means - that the merger encountered the > > 'NEW_FID' > > for an eval where that new file ID makes a reference to a file ID that > > doesn't > > (yet) exist. It seems that the eval has file ID 8, yet lives inside the file > > with ID 9, which is strange, as that means that the file IDs are being > > generated out of order.) > > This can happen when get_file_id() is called with an eval string like > > (eval 2)[/some/file:line] > > *if* "/some/file" hasn't been seen before so doesn't already have a fid > assigned to it. > > The underlying issue is that hash_op(), called by get_file_id(), > combines looking up a fid in the cache with assigning a new one if there > isn't an entry. So the fid for "(eval 2)[/some/file:line]" is assigned > first then "/some/file" is looked up, discovered to be new, and so gets > the next fid in sequence. > > The fids are _output_ to the file in the right order to avoid problems, > but (I think) that ordering workaround gets lost in the nytprofmerge > processing.
For this case, I don't think that it's specifically a *merge* problem, given the earlier report: On Thu, Jan 14, 2010 at 06:03:35AM -0800, hhaldn wrote: > There is a similar (warning) message, when I invoke nytprofhtml on one > of the data files: > > [r...@gnu ~]# nytprofhtml -f /tmp/nytprof.hhn.out.31110 -o /home/ > jobindex/html/nytprof > Generating report... > Reading /tmp/nytprof.hhn.out.31110 > Eval '(eval 0)' (fid 6) has unknown invoking fid 7 > Writing report to /home/jobindex/html/nytprof directory It looks very much like there's an obscure set of circumstances which can result in file IDs to be written out of order to the raw profile file. (I have no idea how it relates to your proposed fix. I admit that as I'm about to go to bed, I'm not a fit state of mind to digest what it's doing) Nicholas Clark -- 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]
