calling juice_send ，the memory leak is very fast

[LiuAriel]

Calling juice_send, on linux such as Ubuntu on the X86 platform, there is no problem, there is no memory leak.
But when calling juice_send on an embedded platform like arm, the memory leak is very fast，Increase memory by 264kb every 1S to 3S.
At present, I want to fix this problem, can you please give some directions for exclusion?

If the network does not go to relay mode in the end, then I looked at the code, mainly sendto, but sendto causes leakage, I think it is unlikely, whether it is necessary to release the incoming data additionally

[paullouisageneau]

This is very surprising as I'm quite sure there is no memory allocation when sending.

What is the embedded ARM platform?

Are you sure the leak is inside the send function and with the calling code? Could you run valgrind or a similar tool to locate it?

[LiuAriel]

Using Cortex-A55, linux4.1.9,
The memory leak is very regular and the growth is 264kb. when calling juice_send。Do not call juice_send api, the memory is very stable
Because I read the code, no one can apply for the resource and send it directly, and now I am trying to find a way to locate the utility.

In the case of a memory leak, the length of the sent data print is not normal: Not sure what length 32 means
need to force keyframes now

07:56:16 VERBOSE conn_poll.c:199: Receiving datagram
07:56:16 VERBOSE conn_poll.c:207: No more datagrams to receive
07:56:16 VERBOSE agent.c:722: Bookkeeping...
07:56:16 VERBOSE agent.c:796: STUN entry 1: Must be rearmed
07:56:16 VERBOSE conn_poll.c:310: Entering poll on 1 sockets for 10000 ms
07:56:16 VERBOSE conn_poll.c:417: Sending datagram, size=453
07:56:16 VERBOSE conn_poll.c:417: Sending datagram, size=32
07:56:16 VERBOSE conn_poll.c:417: Sending datagram, size=302
07:56:16 VERBOSE conn_poll.c:417: Sending datagram, size=32
07:56:16 VERBOSE conn_poll.c:417: Sending datagram, size=643
07:56:16 VERBOSE conn_poll.c:417: Sending datagram, size=32
07:56:16 VERBOSE conn_poll.c:417: Sending datagram, size=262
07:56:16 VERBOSE conn_poll.c:417: Sending datagram, size=32
07:56:16 VERBOSE conn_poll.c:417: Sending datagram, size=1063
07:56:16 VERBOSE conn_poll.c:417: Sending datagram, size=32
07:56:16 VERBOSE conn_poll.c:417: Sending datagram, size=320
07:56:16 VERBOSE conn_poll.c:417: Sending datagram, size=32
07:56:16 VERBOSE conn_poll.c:417: Sending datagram, size=630
07:56:16 VERBOSE conn_poll.c:417: Sending datagram, size=32
07:56:16 VERBOSE conn_poll.c:417: Sending datagram, size=322
07:56:16 VERBOSE conn_poll.c:417: Sending datagram, size=32
07:56:16 VERBOSE conn_poll.c:417: Sending datagram, size=869
07:56:16 VERBOSE conn_poll.c:417: Sending datagram, size=32
07:56:16 VERBOSE conn_poll.c:417: Sending datagram, size=368
07:56:16 VERBOSE conn_poll.c:417: Sending datagram, size=32

[LiuAriel]

The system rootfs has valgrind enabled. According to the normal operation of the project, no leaked information is printed, but the vmRSS memory regularly increases by 264kb, which is very strange!

[paullouisageneau]

In the case of a memory leak, the length of the sent data print is not normal: Not sure what length 32 means
need to force keyframes now

What do you mean? If TURN relaying is not involved, it should send a datagram the same size as specified when calling juice_send.

The system rootfs has valgrind enabled. According to the normal operation of the project, no leaked information is printed, but the vmRSS memory regularly increases by 264kb, which is very strange!

If you send at a rate too high for the network interface, datagrams will be buffered up to 1MB, but that should be kernel memory not counted in vmRSS. Do you use a custom socket implementation by any chance?

[LiuAriel]

I'm sorry, I also tested it according to which method, but it didn't work. On this basis, I also found a very strange problem. Write a cpp file, compile the library with gcc, and then use a C++ class to call libjuice, use When g++ compiles and runs, the memory is 2M. In the same situation, I just implement the C function interface call, and the g++ compile and run memory is only 1M. Of course, the C++ class is the simplest structure, and there is no other processing. It seems that as long as any interface of the libjuice library is called by the C++ class, Memory immediately 2M VmRSS

int main() 
{
	juice_set_log_level(JUICE_LOG_LEVEL_WARN);

	test_connectivity();
       connectivity* conn = new connectivity();
       conn->sendas();
	while(true){
		sleep(2);
	}

	return 0;
}

[paullouisageneau]

If there is a memory leak in the library, valgrind must be able to report it. You could also use valgrind --tool=massif to profile the heap usage. You can't really study the memory behavior of a program by looking at VmRSS or VmSize.

[LiuAriel]

That problem has been solved. If appropriate, I will implement a set of business logic in C language.