• 10 dec 2017: forum version update. In case of issues use this topic.
  • 30 nov 2017: pilight moved servers. In case of issues use this topic.
Hello There, Guest! Login Register

Thread Rating:
  • 1 Vote(s) - 2 Average
  • 1
  • 2
  • 3
  • 4
  • 5
[Solved] First transmission causes full cpu usage
the first code transmission causes full cpu load for me. after the second one all seems to work as expected.

it's reproducible for me by the following:
  • compile current rewrite
  • run "pilight-daemon -D"
  • connect to the webinterface
  • trigger a single state change e.g. light on
  • cpu load gets ~95%
  • trigger a second state change e.g. light off
  • normalized cpu load (~30% for me)

i was not able to catch any logs about this.

this happens in the same call hierarchy of the send call from the hardware. because if i use my csma module (https://github.com/andiwand/pilight/tree/feature/csmacd), which threads the sending, the first code is not transmitted because the load is too high and the sending thread gets delayed too much.
Can you pull from github.com/wo-rasp/pilight.git the branch pointer_check
and test if the problem is still present ?
maybe i'm wrong, but isn't your branch a fork of development? but the bug was introduced with rewrite. at least i was not able to merge your branch into rewrite automatically.

Edit: it does not occur with your branch.
You are right, will rebase pointer_check on rewrite

send from tapatalk
You were faster - i was checking why GPIO_PLATFOM was giving me headaches .... focus has shifted to s_mfy already

The changes I wanted you to test are now integrated into the official rewrite branch.
@wo_rasp, Not sure where you asked about the buffer overflows, but i'm currently testing with efence. You can compile pilight with the static lib and it will specificly search for buffer overflows.
It was in the SOENS innovation thread, XANKER noticed that the modified tfa.c code caused high CPU load in the received parser thread thread , and when i analysed the issue i detected that i had a buggy check in validate leading to a buffer overflow condition in the decoder loop (raw to binary conversion). This led to the additional check that the decoder loop never exceeds the length of the binary array.

can you give me a brief quick start howto integrate efence ?

I do assume that another buffer overflow condition does exist, causing issues with overwriting json structures in memory.

Symptoms monitored:
I had set log_level to 6 (triggering a lot of rule activities recorded in the pilight.log file).

One log entry in pilight.log with the string pool.ntp.org was partly destroyed: p???.ntp.org. It could be that the string defined in the settings section gets partly overwritten.

The WEBGUI protocol was showing only 2 buttons for somfy, if this occurs, pilight.js does no longer detect the protocol somfy_rts requiring a GUI element with three buttons, but will default to the 2 button interface.

Both issues were gone after reboot of the machine.
Manually compile libefence.a then staticly link pilight-daemon to libefence.a when compiling and run the whole thing in gdb.
Actually, i have been wondering whether there was a helpful line available to customize the "target_link_libraries" statement in CMakeLists.txt and what has proven to work already .....

(gdb) run -D
Starting program: /usr/local/sbin/pilight-daemon -D
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".

  Electric Fence 2.2 Copyright (C) 1987-1999 Bruce Perens <bruce@perens.com>

ElectricFence Aborting: Allocating 0 bytes, probably a bug.

Program received signal SIGILL, Illegal instruction.
0x76d251ec in kill () at ../sysdeps/unix/syscall-template.S:81
81      ../sysdeps/unix/syscall-template.S: Datei oder Verzeichnis nicht gefunden.
(gdb) l

As a side note, in addition i think a couple of other options would be helpful as well (May be i have not yet found it):

--print-map - the memory map is on the top of my list, as i am used to use this information to get an overview on what is located where and may be affected as well (to deduce from a symptom of memory locations overwritten by the machine to a reason why the machine did it)
-Wa (to get c-code plus assembly code for the aforementioned analysis)
-g (to turn it on or off, as a lot of subtle problems produce other symptoms after debugging information has increased the memory requirements)

I am using gcc V4.9.2, and this version supports the following option that wil catch bugs like the "raw/binary loop bug":
More info can be found here:

With the libefence lib installed you can use an environment variable to turn libefence debugging support on/off using an environment variable:
export LD_PRELOAD=libefence.so.0.0
I believe the buffer overflow is fixed.

Possibly Related Threads...
Thread Author Replies Views Last Post
  Resource usage curlymo 3 2,796 05-22-2016, 02:43 PM
Last Post: curlymo
Bug Full cpu usage after random time andiwand 4 3,304 05-01-2016, 09:05 PM
Last Post: andiwand
  [Solved] openSUSE 13.2 "pilight-daemon -H" segfault pilino1234 2 2,768 04-22-2016, 08:39 AM
Last Post: pilino1234
Bug [Solved] no gpio-platform configured koos147 5 10,461 04-20-2016, 08:01 PM
Last Post: ksmedts
  [Solved] Compilation error under openSUSE pilino1234 4 3,186 04-16-2016, 08:23 AM
Last Post: pilino1234
  [Solved] pilight-receive fills log with empty DEBUG messages pilino1234 1 2,435 04-12-2016, 07:29 PM
Last Post: curlymo
  [Solved] wiringX initialisation error ksmedts 6 5,892 04-11-2016, 08:06 PM
Last Post: ksmedts
  [Solved] Crash on invalid config.json syntax pilino1234 10 7,170 04-01-2016, 05:40 PM
Last Post: curlymo
  [Solved] Time Stamp Information wo_rasp 5 3,798 03-05-2016, 11:29 PM
Last Post: curlymo

Forum Jump:

Browsing: 1 Guest(s)