start=no generates corrupted profile data?

[frioux]

I could be wrong about this, but I tested it a few times with a lot of different settings.

When I run my app with PERL5OPT=-d:NYTProf NYTPROF=sigexit=1, I can successfully profile and look at the profile, but I end up with a lot of needless compile time records. I tried all of PERL5OPT=-d:NYTProf NYTPROF=sigexit=1:start=no, PERL5OPT=-d:NYTProf NYTPROF=libcexit=1:start=no, PERL5OPT=-d:NYTProf NYTPROF=posix_exit=1:start=no, and PERL5OPT=-d:NYTProf NYTPROF=endatexit=1:start=no, and all of these trigger the Profile data incomplete, inflate error -5 ((null)) at end of input file error.

I'm happy to do any other investigation to track down the issue here. Just let me know how I can help.

[timbunce]

I think you want start=init to avoid the compile time records.
start=no is only of use if you add code into your app to explicitly start profiling.
See the start option docs for more info.
I can see that they could use some clarification.

[frioux]

I'll add more info here if I can boil down a failing case; I can see that start=no works perfectly for a contrived script.

[timbunce]

Ping! Any news on this @frioux?

[frioux]

Woah blast from the past! Lemme follow up on this at work on Monday

sent from a rotary phone, pardon my brevity
On Mar 19, 2016 3:01 PM, "Tim Bunce" notifications@github.com wrote:

Ping! Any news on this @frioux https://github.com/frioux?

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#85 (comment)

[timbunce]

Whooosh!
Cool.
I'm skimming the issues for low-hanging fruit for a new release fairly soonish. Monday would be great.

[frioux]

Before I dig much deeper here's the context for this issue; we have a middleware (ZR::Plack::Middleware::NYTProf) and at the top there is the following in pod:

This middleware calls C<DB::enable_profile()> at the beginning of a request
and C<DB::disable_profile()> at the end of the request.

The assumption being that you:

  use Devel::NYTProf;
  BEGIN { DB::disable_profile() }

In your application entry point.  Passing C<start=no> to L<Devel::NYTProf> seems
to produce broken data files which C<nytprofhtml> cannot read.  Doing it as
above seems to make everything work fine.

So while start=init may be more correct in general, I am not sure if it makes sense in this context. I sadly don't think I can build up to a working example, but I may be able to break down to one. Will keep you up to date with that effort.

[frioux]

I don't see myself coming up with the time to track this down any time soon. I'll see if any coworkers want to try to repro; otherwise I'll close it.

[jkeenan]

I don't see myself coming up with the time to track this down any time soon. I'll see if any coworkers want to try to repro; otherwise I'll close it.

@frioux, since we haven't heard back from you on this issue, we're closing this ticket. However, a new version of Devel-NYTProf (6.07) was released this morning. Please let us know (via opening a new issue) if your in-house module has any problems working with it.

Thank you very much.
Jim Keenan