On 09/03/2015 01:11 PM, Pavel Březina wrote:
On 09/03/2015 01:04 PM, Pavel Reichl wrote:
On 09/03/2015 12:48 PM, Pavel Březina wrote:
Hi, due to recent memory leak issues, I think it would be good to provide a built-in way to store talloc full report in a file. It proved to be very helpful in detection of the location where memory leak occurs, but we always obtained it from custom built.
+1
I would very much like to write a patch, but I'd like to hear your opinion on how it should be obtains. I have few ideas:
- Periodic task -- periodically (1 hour?) store talloc full report
into a file.
Some leaks might take too much memory to last more than a couple of minutes. Some "semi" leaks could be freed when their parent context is freed - but they should be freed way earlier on their own.
- Generate report on signal.
Do you have any signal in mind? I mean can we abuse some "standard" signals? Using SIGUSR works nice, alas we can steal it...unless we add new configuration option?
Well, it is possible to abuse SIGUSR signal or some other, but I would prefer not to do it anymore, since we have nice D-Bus support.
Converting our signal handlers to D-Bus is something I'd like to talk about next week in person.
OK, looking forward to that.
Generate report on D-Bus method.
Provide a tool that would do 2) or 3).
I personally favor 1). _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
Could we use inotify to handle creation of some file which would signal to generate talloc_report? Too weird? _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel