Uh oh!
There was an error while loading. Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork 367
trace: fixes to help for heap allocation debugging#4548
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Uh oh!
There was an error while loading. Please reload this page.
Changes from all commits
File filter
Filter by extension
Conversations
Uh oh!
There was an error while loading. Please reload this page.
Jump to
Uh oh!
There was an error while loading. Please reload this page.
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -35,22 +35,22 @@ config TRACEM | ||
| config TRACE_FILTERING | ||
| bool "Trace filtering" | ||
| depends on TRACE | ||
| default y | ||
| default n | ||
Collaborator There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is hiding a very big change in a PR with a totally unrelated name. ContributorAuthor There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. do you mean the PR subject, let me rename it. Anyway, the change is mentioned in the commit subject. Collaborator There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes the commit is fine, I was only referring to the PR name. This relatively complex feature took a lot of effort, so I'm pretty sure it was developed for a reason. This change could kill performance on all production systems with just one character change. So even a scary PR name may not be enough, it should probably be discussed in some larger forum / mailing list.
| ||
| help | ||
| Filtering of trace messages based on their verbosity level and frequency. | ||
| config TRACE_FILTERING_VERBOSITY | ||
| bool "Filter by verbosity" | ||
| depends on TRACE_FILTERING | ||
| default y | ||
| default n | ||
| help | ||
| Filtering by log verbosity level, where maximum verbosity allowed is specified for each | ||
| context and may be adjusted in runtime. | ||
| config TRACE_FILTERING_ADAPTIVE | ||
| bool "Adaptive rate limiting" | ||
| depends on TRACE_FILTERING | ||
| default y | ||
| default n | ||
| help | ||
| Adaptive filtering of trace messages, tracking up to CONFIG_TRACE_RECENT_ENTRIES_COUNT, | ||
| suppressing all repeated messages for up to CONFIG_TRACE_RECENT_TIME_THRESHOLD cycles. | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, I was meaning from my comment on the previous PR it would be good to dump the heap blocks on any allocation error. I see we are already doing this but in debug mode only ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's true. One more bad thing is that our trace are always filtered out by the trace filtering, that's why I tried to set the filtering to N by default
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we do something like this (it sames duplicating the print).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it doesnt look like this feedback was addressed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, definitely good to deduplicate, but can I propose a slight modification:
to always have
do { ... } while (0)externally