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:
>
> 1) 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.
>
> 2) 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.
> 3) Generate report on D-Bus method.
>
> 4) Provide a tool that would do 2) or 3).
>
> I personally favor 1).
> _______________________________________________
> sssd-devel mailing list
> sssd-devel(a)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(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel