-
Notifications
You must be signed in to change notification settings - Fork 51
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
NYTProf.xs: Spurious logwarning being generated #164
Comments
In commit 8f4088c, I added debugging statements to NYTProf.xs and to t/rt70211.t. When I run the test file via
... which at first appears to demonstrate the conditions under which the spurious warnings will be generated. *However, when I run Line 3741 in 8f4088c
Line 3751 in 8f4088c
|
Data point: you get this spurious log warning whenever you simply include Devel::NYTProf via the command line.
|
To clarify (at least for my future self): In the test suite as it currently stands we never encounter a situation where the "GHI" case -- And since, in the absence of setting But that logwarn is clearly exercised in real code, so we have a coverage shortfall in the test suite. |
If I do set
Note that the "GHI" condition is still not met, so Thank you very much. |
This ticket was originally filed in 2011 as RT 70211. The ticket failed to be correctly converted to a GitHub issue in 2015 and so has remained unresolved. The original ticket began like this:
Subsequently, in 2013, Zefram reported being able to reduce the problem to the following:
The puzzling warning emanates from https://github.com/timbunce/devel-nytprof/blob/master/NYTProf.xs#L3742:
Since the warning is being generated when
trace_level
is unset, it follows that the warning is being generated from*hint
. This can be confirmed by changing the assignment tohint
at line 3740 above and recompiling. In addition, ifhint
is assigned an empty string at line 3740 above and you re-compile, the warning goes away.In the rt70211-20210424 branch, I have added one test file which demonstrates the problem. The sole test in that file is currently
TODO
-ed. Once we solve the problem, that test can be un-TODO
-ed, but we may have to fix some tests in other files that are expecting the current sub-optimal behavior.This should enable us to close #53.
Thank you very much.
Jim Keenan
The text was updated successfully, but these errors were encountered: