A series of patches towards limiting memory corruption and foot print
by Kalowsky, Daniel
Hi Powertop,
I've been working with the interactive mode and have run into cases where powertop will crash due to a series of memory corruptions. The following series of patches have helped to reduce the frequency of the issue, although not completely solved it. The issues arise much faster on platforms where there are constrained amounts of RAM to work within.
Patch 1 - When shutting down the interactive display, the display bits of memory is not correctly released. This patch provides a method for correctly doing so.
Patch 2 - Solving a documented memory leak with a non-elegant solution. The path either adds the bundle to the stack, or it forgets about it. If it is forgotten about, make sure to clear that memory before moving on. This is done with a simple flag variable being set.
Patch 3 - When the tuning window is updated, the current pointer is just set adrift and not properly free'd. This patch catches that issue and removes the dangling pointer by holding a reference to the pointer until it is reset or specifically free'd.
Patch 4 - Someone actually added in the code to create a onetime pretty-print array, this patch just puts it to use by setting the variable.
Patch 5 - Limiting the buffer copy to the size of the allocated buffer with snprintf.
Patch 6 - There exist some processes and entries that can and do extend beyond the length of these buffers. This limits those entries so as not to corrupt other memory on the system when in interactive mode.
Patch 7 - This is an untested patch, but follows along the same lines of Patch 6. It applies the same principals only for the report method.
Patch 8 - Creates a clean_shutdown function that can be used to cleanup the memory space at shutdown time. Calls upon parts of Patch 1 to make this happen.
There will more than likely be some more patches in the future as time permits.
7 years, 2 months
[PATCH] Add csstosh.sh to EXTRA_DIST
by Tobias Klauser
Since css.h is in CLEANFILES, `make clean' will delete it and thus
cause the build to fail afterwards due to a missing csstoh.sh to
regenerate it. Fix this by adding csstoh.sh to EXTRA_DIST which will
cause it to be included in the tarball.
Signed-off-by: Tobias Klauser <tklauser(a)distanz.ch>
---
src/Makefile.am | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/Makefile.am b/src/Makefile.am
index 9d053a4..6886388 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -52,3 +52,4 @@ CLEANFILES = css.h
css.h: powertop.css
$(SHELL) ${srcdir}/csstoh.sh ${srcdir}/powertop.css css.h
+EXTRA_DIST = ${srcdir}/csstoh.sh
--
1.7.9.5
7 years, 7 months
[PATCH v2] Bug-fix: for html & csv value for CPU Information
by Alexandra Yates
This patch fixes an error encounterd when printing "CPU Information"
on html and csv.
Alexandra Yates (1):
Bug-fix: for html & csv value for CPU Information
src/report/report.cpp | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--
1.7.9.5
7 years, 7 months
[PATCH 0/3] Fix all warnings
by Alexandra Yates
This patch fixes all warning encountered when building PowerTOP.
Alexandra Yates (3):
fix-warnings: Ignoring return value of system()
fix-warnings: Ignoring return value
fix-warnings: Ignoring return value
src/calibrate/calibrate.cpp | 16 +++++++++++-----
src/measurement/extech.cpp | 13 +++++++------
src/tuning/bluetooth.cpp | 6 ++++--
3 files changed, 22 insertions(+), 13 deletions(-)
--
1.7.9.5
7 years, 7 months
[PATCH] Bug-fix: for html & csv value for CPU Information
by Alexandra Yates
This patch fixes an error encounterd when printing "CPU Information"
on html and csv.
Alexandra Yates (1):
Bug-fix: for html & csv value for CPU Information
src/report/report.cpp | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--
1.7.9.5
7 years, 7 months
[PATCH] fix-csv: cell alignment with regional formats
by Alexandra Yates
This patch fixes translation cvs errors and coma parsing error.
Alexandra Yates (1):
fix-csv: cell alignment with regional formats
src/report/report-formatter-csv.cpp | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--
1.7.9.5
7 years, 7 months
[PATCH] Fix compile warning in cpu.cpp
by Srinivas Pandruvada
Fix
cpu/cpu.cpp: In function ‘void report_display_cpu_cstates()’:
cpu/cpu.cpp:616:28: warning: ‘_core’ may be used uninitialized in this function [-Wmaybe-uninitialized]
cpu/cpu.cpp: In function ‘void report_display_cpu_pstates()’:
cpu/cpu.cpp:797:27: warning: ‘_core’ may be used uninitialized in this function [-Wmaybe-uninitialized]
---
src/cpu/cpu.cpp | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/cpu/cpu.cpp b/src/cpu/cpu.cpp
index 37cc409..d360f2f 100644
--- a/src/cpu/cpu.cpp
+++ b/src/cpu/cpu.cpp
@@ -428,7 +428,7 @@ void report_display_cpu_cstates(void)
char buffer[512], buffer2[512], tmp_num[50];
unsigned int package, core, cpu;
int line, cstates_num, title=0, core_num=0;
- class abstract_cpu *_package, * _core, * _cpu;
+ class abstract_cpu *_package, *_core = NULL, * _cpu;
const char* core_type = NULL;
cstates_num = get_cstates_num();
@@ -608,7 +608,7 @@ void report_display_cpu_cstates(void)
/* Report Output */
if(core_num > 0)
title=title/core_num;
- else if( _core->children.size() > 0)
+ else if(_core && _core->children.size() > 0)
title=title/_core->children.size();
init_pkg_table_attr(&std_table_css, pkg_tbl_size.rows, pkg_tbl_size.cols);
@@ -630,7 +630,7 @@ void report_display_cpu_pstates(void)
char buffer[512], buffer2[512], tmp_num[50];
unsigned int package, core, cpu;
int line, title=0;
- class abstract_cpu *_package, * _core, * _cpu;
+ class abstract_cpu *_package, *_core = NULL, * _cpu;
unsigned int i, pstates_num;
const char* core_type = NULL;
@@ -794,7 +794,7 @@ void report_display_cpu_pstates(void)
}
init_pkg_table_attr(&std_table_css, pkg_tbl_size.rows, pkg_tbl_size.cols);
report.add_table(pkg_data, &std_table_css);
- if(!_core->can_collapse()){
+ if(_core && !_core->can_collapse()){
title=pstates_num+2;
init_core_table_attr(&std_table_css, title,
core_tbl_size.rows, core_tbl_size.cols);
--
1.7.11.7
7 years, 7 months
Re: [Powertop] Fix out of tree builds [Was: PowerTOP v2.6.1 released]
by Alexandra Yates
Hi Joerg,
Unfortunately the patches you sent don't fix the issue. Here is how to
reproduced the issue:
1- Applied your patches.
2- Generated an new dist/tarball,
3- Untared on different location
4- Executed: ./autogen; ./configure; make; make clean; make
The error still points that /bin/bash: ./csstoh.sh: No such file or directory
===== Complete output ======
make all-recursive
make[1]: Entering directory `/home/magd/Downloads/powertop-2.6.1'
Making all in traceevent
make[2]: Entering directory `/home/magd/Downloads/powertop-2.6.1/traceevent'
CC event-parse.lo
CC parse-filter.lo
CC parse-utils.lo
CC trace-seq.lo
CCLD libtraceevnet.la
make[2]: Leaving directory `/home/magd/Downloads/powertop-2.6.1/traceevent'
Making all in src
make[2]: Entering directory `/home/magd/Downloads/powertop-2.6.1/src'
/bin/bash ./csstoh.sh ./powertop.css css.h
/bin/bash: ./csstoh.sh: No such file or directory
make[2]: *** [css.h] Error 127
make[2]: Leaving directory `/home/magd/Downloads/powertop-2.6.1/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/magd/Downloads/powertop-2.6.1'
make: *** [all] Error 2
> On Wed, May 28, 2014 at 09:28:12AM -0700, Alexandra Yates wrote:
>> > On Tue, May 27, 2014 at 10:24:44AM -0700, Alexandra Yates wrote:
>> >> > Also it is not possible to compile it after running:
>> >> > $ make clean
>> >> >
>> >> > It seems csstoh.sh script is missing
>> >
>> > I've had this patch in my tree for at least some months...
>>
>> Can you send the patch to the mailing list?
>
> I verified that I did attach it. For people who prefer inline patches
> find a regenerated version below. Btw, to find out about problems with
> the source: Please run "make distcheck" before doing a release - which
> will currently fail due to the included object files.
>
> Ciao
> Jörg
>
> From 22a76b66041f27017de302ae5650ec973471a01a Mon Sep 17 00:00:00 2001
> From: Joerg Mayer <jmpt(a)loplof.de>
> Date: Sun, 1 Jun 2014 09:36:17 +0200
> Subject: [PATCH] Fix out of tree builds
>
> Signed-off-by: Joerg Mayer <jmpt(a)loplof.de>
> ---
> src/Makefile.am | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/Makefile.am b/src/Makefile.am
> index 0fe3c04..605f285 100644
> --- a/src/Makefile.am
> +++ b/src/Makefile.am
> @@ -50,5 +50,5 @@ AM_LDFLAGS = $(LIBS) $(NCURSES_LIBS) $(PCIUTILS_LIBS)
> $(LIBNL_LIBS) $(LIBZ_LIBS)
> BUILT_SOURCES = css.h
> CLEANFILES = css.h
> css.h: powertop.css
> - $(SHELL) ./csstoh.sh powertop.css css.h
> + $(SHELL) ${srcdir}/csstoh.sh ${srcdir}/powertop.css css.h
>
> --
> 1.8.4.5
>
> --
> Joerg Mayer <jmayer(a)loplof.de>
> We are stuck with technology when what we really want is just stuff that
> works. Some say that should read Microsoft instead of technology.
>
Thank you,
Alexandra.
7 years, 7 months
Re: [Powertop] [systemd-devel] How to quiet cron sessions logging with systemd-212?
by Ivan Shapovalov
On Monday 09 June 2014 at 23:32:28, Mike Gilbert wrote:
> On Mon, Jun 9, 2014 at 4:42 PM, Reindl Harald <h.reindl(a)thelounge.net> wrote:
> >
> > Am 09.06.2014 22:32, schrieb Leonid Isaev:
> >> On Mon, Jun 09, 2014 at 09:19:20PM +0200, Reindl Harald wrote:
> >>> [...]
> >>>
> >>> on our production infrastrcuture these messages would be
> >>> *a lot* more than all other logs summarized
> >>>
> >>> *and* they are spitted to /var/log/messages to make things worst
> >>>
> >>>> But why can't you write a syslog filter which uses facility as well as program
> >>>> name? So if you believe that systemd-generated messages are useless, drop them
> >>>
> >>> because you *can not* distinguish between *that* user messages
> >>> and system message sbecause they have systemd as program name
> >>> common, the PID changes and you don't want to drop *system
> >>> messages* from systemd
> >>
> >> So, systemd starts certain things on _any_ user "login": be it a real user, or
> >> a daemon. However
> >
> > * why do it need to do that much stuff
> > * why can't it keep that stuff long-running
> >
> > you have already "/usr/lib/systemd/systemd --user" and "(sd-pam)"
> > processes for every userid ever started a cronjob running all
> > the time - so why flood the logs every minute again?
> >
>
> Now that you mention it, you can cut down on a lot of the log spam by
> enabling "linger" for root and other users which run cron jobs.
>
> loginctl enable-linger <user>
>
> This will keep a systemd user instance running so that a new one is
> not spawned every time cron wakes up.
It's more interesting, why a logind session is ever being created for the cron job...
It shouldn't be that way, or do I misunderstand something?
--
Ivan Shapovalov / intelfx /
7 years, 7 months
