The value from getglobal wasn't being removed from the stack,
resulting in an ever growing stack in the ubus event handler.
Signed-off-by: Karl Vogel <karl.vogel@gmail.com>
Signed-off-by: Hans Dedecker <dedeckeh@gmail.com>
ubus_connect_ctx() is equivalent to ubus_connect() but accepts a
pointer to a previously allocated ubus_context struct.
ubus_shutdown() is made available as an alternative to ubus_free()
to clean up contexts initialised by ubus_connect_ctx().
Signed-off-by: Delio Brignoli <dbrignoli@audioscience.com>
This fixes build warning:
/ubus.git/examples/server.c: In function 'test_hello_reply':
/ubus.git/examples/server.c:69:6: error: ignoring return value of 'pipe', declared with attribute warn_unused_result [-Werror=unused-result]
Signed-off-by: Zefir Kurtisi <zefir.kurtisi@neratec.com>
__init has a naming collision with C++ and prevents ubus_common.h
from being included. Instead, use __constructor as defined from
libubox.
Signed-off-by: Zefir Kurtisi <zefir.kurtisi@neratec.com>
Context: 1 loop with a single ubus_invoke() that times out calls
uloop_end() which ends the loop, and thus ends the application.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Set ctx->msgbuf.data to NULL during the call. If ctx->msgbuf is needed
during the call, a new buffer will be allocated. If not,
ctx->msgbuf.data is restored to the previous value afterwards
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Client creates a string "1 2 3 ... 10000 ...", sends it to the server
along with the maximum number in the string.
Server creates another string like the client sent.
It validates it and, returns strcmp()'s result.
This is loop-ed every 2 seconds.
The realloc is problematic mostly with large packets, as the pointer changes
so what eventually gets free'd is invalid.
Note that ub ptr param in the call will be passed on to a ubus_msg_free(),
right after ubus_msg_ref() finishes.
This bug stayed hidden the same way as the bug in libubus writev_retry().
Since the write/sendmsg function can send about ~200k the ubus_msg_enqueue()
call does not get triggered.
Seems this bug stayed hidden for a while, because the write/sendmsg function
can send up to ~200k in one send, so it looked at first why there was
some data mismatch.
This fixes recursion problems on config reload in netifd and simplifies
application handling of requests
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
This allows sharing a policy array across methods, but masking out
unused entries for individual methods.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
