Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Eclipse Titan » How to find memory leaks using MEMORY_DEBUG(There are memory leak messages in debug mode)
How to find memory leaks using MEMORY_DEBUG [message #1850029] Fri, 11 February 2022 11:38 Go to next message
Petro Shevchenko is currently offline Petro ShevchenkoFriend
Messages: 3
Registered: February 2022
Junior Member
Hi everyone,
I got memory leak messages after I had compiled Titan and our TTCN test cases in debug mode:

Quote:

../core/Charstring.cc:77: Memory leak at 0x55eb6514d190, size 72, ord 307327: ....?...>>> ADAPTER_DEBUG: Enter
new.cc:23: Memory leak at 0x55eb6514cd80, size 256, ord 307329: ..)d.U..........h.*d.U..........
new.cc:23: Memory leak at 0x55eb650eedf0, size 16, ord 307330: ..(d.U.....e.U..
new.cc:23: Memory leak at 0x55eb650eeca0, size 16, ord 307332: ................
../core/Charstring.cc:77: Memory leak at 0x55eb6514cec0, size 71, ord 307333: ....>...<<< ADAPTER_DEBUG: Exiti
new.cc:23: Memory leak at 0x55eb6514cab0, size 256, ord 307335: ..)d.U..........h.*d.U..........
new.cc:23: Memory leak at 0x55eb650ed170, size 16, ord 307336: ..(d.U.....e.U..
new.cc:23: Memory leak at 0x55eb650edfb0, size 16, ord 307338: ................
../core/Charstring.cc:77: Memory leak at 0x55eb6514cbf0, size 70, ord 307339: ....=...>>> ADAPTER_DEBUG: Enter
new.cc:23: Memory leak at 0x55eb6514c7e0, size 256, ord 307341: ..)d.U..........h.*d.U..........
new.cc:23: Memory leak at 0x55eb650ed920, size 16, ord 307342: ..(d.U.....e.U..
new.cc:23: Memory leak at 0x55eb650eb1d0, size 16, ord 307344: ................
../core/Charstring.cc:77: Memory leak at 0x55eb6514c920, size 69, ord 307345: ....<...<<< ADAPTER_DEBUG: Exiti
new.cc:23: Memory leak at 0x55eb6514a970, size 256, ord 307347: ..)d.U..........h.*d.U..........
new.cc:23: Memory leak at 0x55eb650edbc0, size 16, ord 307348: ..(d.U.. ..e.U..
new.cc:23: Memory leak at 0x55eb650eda70, size 16, ord 307350: ................
../core/Charstring.cc:77: Memory leak at 0x55eb6514aab0, size 72, ord 307351: ....?...>>> ADAPTER_DEBUG: Enter
new.cc:23: Memory leak at 0x55eb6513a4a0, size 256, ord 307353: ..)d.U..........h.*d.U..........
new.cc:23: Memory leak at 0x55eb650ede60, size 16, ord 307354: ..(d.U.....e.U..
new.cc:23: Memory leak at 0x55eb650edd10, size 16, ord 307356: ................
../core/Charstring.cc:77: Memory leak at 0x55eb64f6e360, size 92, ord 307357: ....S...=== ADAPTER_DEBUG: [clos
new.cc:23: Memory leak at 0x55eb6513a5e0, size 256, ord 307359: ..)d.U..........h.*d.U..........
new.cc:23: Memory leak at 0x55eb650ec6f0, size 16, ord 307360: ..(d.U..`..d.U..
new.cc:23: Memory leak at 0x55eb650ed020, size 16, ord 307362: ................
../core/Charstring.cc:77: Memory leak at 0x55eb64f51e50, size 106, ord 307363: ....a...=== ADAPTER_DEBUG: [clos
new.cc:23: Memory leak at 0x55eb6513c010, size 256, ord 307365: ..)d.U..........h.*d.U..........
new.cc:23: Memory leak at 0x55eb650ec990, size 16, ord 307366: ..(d.U..P..d.U..
new.cc:23: Memory leak at 0x55eb650ec840, size 16, ord 307368: ................
../core/Charstring.cc:77: Memory leak at 0x55eb6513c150, size 71, ord 307369: ....>...<<< ADAPTER_DEBUG: Exiti
new.cc:23: Memory leak at 0x55eb6513c1e0, size 256, ord 307371: ..)d.U..........h.*d.U..........
new.cc:23: Memory leak at 0x55eb650ecc30, size 16, ord 307372: ..(d.U..P..e.U..
total unallocated: 101578 bytes in 1134 blocks


My question is how I can use this information to find places in our source code which causes memory leaks.
I've found nothing in the Titan documentation.

Thanks in advance.
Re: How to find memory leaks using MEMORY_DEBUG [message #1850035 is a reply to message #1850029] Fri, 11 February 2022 16:28 Go to previous messageGo to next message
Gábor Szalai is currently offline Gábor SzalaiFriend
Messages: 134
Registered: December 2015
Senior Member
The address of the allocated object are printed out. Also the content of the unallocated charstrings, which give a hint about the allocation point.

You can log the address of the allocated memory in your code and compare the reported ones.

You can try to use the valgrnid tool also.
Re: How to find memory leaks using MEMORY_DEBUG [message #1850038 is a reply to message #1850035] Fri, 11 February 2022 17:38 Go to previous messageGo to next message
Petro Shevchenko is currently offline Petro ShevchenkoFriend
Messages: 3
Registered: February 2022
Junior Member
Gábor Szalai,
thank you for your answer.

Quote:

The address of the allocated object are printed out. Also the content of the unallocated charstrings, which give a hint about the allocation point.


The address points to the new operator and the CHARSTRING constructor:
Quote:

../core/Charstring.cc:77: Memory leak at 0x55eb6514d190, size 72, ord 307327: ....?...>>> ADAPTER_DEBUG: Enter
new.cc:23: Memory leak at 0x55eb6514cd80, size 256, ord 307329: ..)d.U..........h.*d.U..........


void *operator new(size_t size)
{
    return Malloc(size); // new.cc:23
}

void CHARSTRING::init_struct(int n_chars)
{
  if (n_chars < 0) {
    val_ptr = NULL;
    TTCN_error("Initializing a charstring with a negative length.");
  } else if (n_chars == 0) {
    /** This will represent the empty strings so they won't need allocated
      * memory, this delays the memory allocation until it is really needed.
      */
    static charstring_struct empty_string = { 1, 0, "" };
    val_ptr = &empty_string;
    empty_string.ref_count++;
  } else {
    val_ptr = (charstring_struct*)Malloc(MEMORY_SIZE(n_chars)); // core/Charstring.cc:77
    val_ptr->ref_count = 1;
    val_ptr->n_chars = n_chars;
    val_ptr->chars_ptr[n_chars] = '\0';
  }
}


This information can't help to know from where the memory allocation was called.
The content of the unallocated charstrings points to the ADAPTER_DEBUG macros that based on TTCN_Logger::log() :
#define ADAPTER_ERROR_LOG(fmt, args...) do { TTCN_Logger::log(TTCN_ERROR, "=== ADAPTER_DEBUG: [%s] " fmt, __FUNCTION__, ##args); } while (false)
#define ADAPTER_DEBUG_LOG(fmt, args...) do { TTCN_Logger::log(TTCN_DEBUG, "=== ADAPTER_DEBUG: [%s] " fmt, __FUNCTION__, ##args); } while (false)
#define ADAPTER_DEBUG_ENTER_LOG() do { TTCN_Logger::log(TTCN_DEBUG, ">>> ADAPTER_DEBUG: Entering %s at %s:%d", __FUNCTION__, __FILE__, __LINE__); } while (false)
#define ADAPTER_DEBUG_EXIT_LOG(val) do { \
		if (val != NULL) TTCN_Logger::log(TTCN_DEBUG, "<<< ADAPTER_DEBUG: Exiting %s at %s:%d with return code '%s'", __FUNCTION__, __FILE__, __LINE__, val); \
		else TTCN_Logger::log(TTCN_DEBUG, "<<< ADAPTER_DEBUG: Exiting %s at %s:%d", __FUNCTION__, __FILE__, __LINE__); \
	} while (false)


Quote:

You can log the address of the allocated memory in your code and compare the reported ones.


That is a good point, but I am afraid I'll spam the output log if I try to print every allocated address.
Anyway, I'll try to do that , thank you for advice.

Quote:

You can try to use the valgrnid tool also.

I tried to use valgrind but difficulties appear due to the fact that 'titan.core/Install/bin/ttcn3_start' used to launch test cases is a script, which creates several processes.

Re: How to find memory leaks using MEMORY_DEBUG [message #1850055 is a reply to message #1850038] Mon, 14 February 2022 07:22 Go to previous messageGo to next message
Gábor Szalai is currently offline Gábor SzalaiFriend
Messages: 134
Registered: December 2015
Senior Member
Valgrind usage:
You should start the test suite manually:

Open two terminals
In the first one, start the main controller:

> mctr_cli cfg.file


*************************************************************************
* TTCN-3 Test Executor - Main Controller 2                              *
* Version: 8.1.0                                                        *
* Copyright (c) 2000-2021 Ericsson Telecom AB                           *
* All rights reserved. This program and the accompanying materials      *
* are made available under the terms of the Eclipse Public License v2.0 *
* which accompanies this distribution, and is available at              *
* https://www.eclipse.org/org/documents/epl-2.0/EPL-2.0.html            *
*************************************************************************

MC@HU-00000183: Unix server socket created successfully.
MC@HU-00000183: Listening on TCP port 59724.
MC2> 



Not the printed tcp port number. And start the test suite with valgrind on teh other terminal:

valgring  --trace-children=yes <exeutable_ts> <your_host_name> <tcp_port>


When the host controller connected to the main controller start the test with the commands of the main controller:
MC2> cmtc
MC2> smtc



Are there any threads in your code?
Re: How to find memory leaks using MEMORY_DEBUG [message #1850059 is a reply to message #1850055] Mon, 14 February 2022 10:58 Go to previous messageGo to next message
Petro Shevchenko is currently offline Petro ShevchenkoFriend
Messages: 3
Registered: February 2022
Junior Member
Hi Gábor Szalai,
thank you for help.

Quote:

Are there any threads in your code?

Yes, there are.
We tried to add a mutex to the TTCN_Logger class to safe the logger to be called from different threads. It doesn't solve the memory leaks.

I followed your recommendations.

Here is the most significant part of the Valgrind log I got:
==29189== Invalid read of size 1
==29189==    at 0xDDEAE67: bcmp (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==29189==    by 0x8BBECB4: check_magic_values (memory.c:178)
==29189==    by 0x8BBF347: Free_dbg (memory.c:490)
==29189==    by 0x8BCD5BE: operator delete(void*, unsigned long) (new.cc:39)
==29189==    by 0x8AD0072: CHARSTRING::~CHARSTRING() (Charstring.cc:185)
==29189==    by 0x1ABBEED: OPTIONAL<CHARSTRING>::~OPTIONAL() (Optional.hh:156)
==29189==    by 0x8D25D83: TitanLoggerApi::ExecutorRuntime::~ExecutorRuntime() (TitanLoggerApi.hh:1895)
==29189==    by 0x8D25DBB: TitanLoggerApi::ExecutorRuntime::~ExecutorRuntime() (TitanLoggerApi.hh:1895)
==29189==    by 0x8BFB120: TitanLoggerApi::ExecutorEvent_choice::clean_up() (TitanLoggerApi.cc:10351)
==29189==    by 0x8BFA7F1: TitanLoggerApi::ExecutorEvent_choice::~ExecutorEvent_choice() (TitanLoggerApi.cc:10173)
==29189==    by 0x8D25895: TitanLoggerApi::ExecutorEvent::~ExecutorEvent() (TitanLoggerApi.hh:2601)
==29189==    by 0x8D258BD: TitanLoggerApi::ExecutorEvent::~ExecutorEvent() (TitanLoggerApi.hh:2601)
==29189==  Address 0x120026d8 is 8 bytes before a block of size 16 alloc'd
==29189==    at 0xDDE517F: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==29189==    by 0x8B1CF2B: OPTIONAL<CHARSTRING>& OPTIONAL<CHARSTRING>::operator=<char const*>(char const* const&) (Optional.hh:566)
==29189==    by 0x8B179B4: LoggerPluginManager::log_HC_start(char const*) (LoggerPluginManager.cc:995)
==29189==    by 0x8B12266: TTCN_Logger::log_HC_start(char const*) (Logger.cc:1283)
==29189==    by 0x8B3D9CF: TTCN_Runtime::hc_main(char const*, char const*, unsigned short) (Runtime.cc:525)
==29189==    by 0x8BCE0C5: main (Parallel_main.cc:251)
==29189== 
new.cc:39: Fatal error: memory corruption detected at block begin when freeing pointer 0x120026e0.


The full logs are attached


Re: How to find memory leaks using MEMORY_DEBUG [message #1850061 is a reply to message #1850059] Mon, 14 February 2022 11:19 Go to previous message
Gábor Szalai is currently offline Gábor SzalaiFriend
Messages: 134
Registered: December 2015
Senior Member
The TITAN is designed to be single threaded. So every API of the TITAN are NOT thread safe.

Simply do not log, or use any API call from the started thread. The mutexes won't help because they are just a signals, and all of the thread should use the same mutex to protect the data. And the TITAN code is not aware of your mutex.

The only "safe" way to use threads is to use pipes to send every data to the test port event handler. The every data includes the logging data.

The symptoms of the TITAN API usage from threads:
- memory corruption
- free/delete issues
- segmentation faults
Previous Topic:ETSI TTCN-3 Tests
Next Topic:Serial-Port "hex-mode"
Goto Forum:
  


Current Time: Fri Oct 04 03:33:53 GMT 2024

Powered by FUDForum. Page generated in 0.03704 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top