Memory leak with concatenation operator

[knhan930]

I had a problem with a SystemC code, which generated correct results but began to produce random results after thousands of iterations. Both SystemC 2.2.0 and 2.3.0 showed the same error. What I found is that the main culprit of this error came from the concatenation operation, which was reported both by Valgrind and Purify that there were memory leaks. Let me share some testcases with these symptoms.

1. sc_uint, sc_int datatypes

#include "systemc.h"
int sc_main(int argc, char* argv[]) {
 sc_uint<4> a, b;
 sc_uint<8> c, z1;
 bool z2;

 a = 0x5;
 b = 0x3;
 c = 0x11;

 z1 = (a, b ) - c;	   // memory leak
 z2 = ((a, b ) == c);  // memory leak
}

In this testcase, memory leak came from both z1 and z2 lines.

2. sc_biguint, sc_bigint datatypes

#include "systemc.h"
int sc_main(int argc, char* argv[]) {
 sc_biguint<4> a, b;
 sc_biguint<8> c;
 sc_biguint<8> z1, z3;
 bool z2;

 a = 0x5;
 b = 0x3;
 c = 0x11;

 z1 = (a, b ) - c;	  // memory leak
 z2 = ((a, b ) == c); // memory leak
 z3 = (a, b );		   // memory leak
}

With sc_biguint datatype, z1, z2 and z3 lines have memory leak. Especially z3 line caused random results after iterations.

So, I would like to know if it’s known issues with SystemC 2.2.0 and 2.3.0, and if there is any bug patch plan with SystemC 2.3.x or any applicable workarounds. Thank you.

[Philipp A Hartmann]

A memory leak would not cause "random results". It would just consume more memory.

Can you post some information about these "random results"?

Secondly. whether or not a memory leak exists requires more details as well. The reports from Valgrind and Purify could be false positives as well, especially since there are memory pools used behind the scenes. Why do you suspect a memory leak here?

Greetings from Oldenburg,

Philipp

[knhan930]

Philipp,

Thank you for the quick reply.

The reason I mention about the concatenation operator is that I have a workaround that removed the random result error after replacing the concatenation operator of sc_biguint to arithmetic equations. For example, after I changed the code

from code A,

z = (f[3]) ? (a == (sc_biguint<1>(1), sc_biguint<width>(0))) :
(f[4]) ? (a == (sc_biguint<1>(0), sc_biguint<width>)) : 0;

to code B,

z = (f[3]) ? (a == (1 << width)) :
(f[4]) ? (a == 0) : 0;

, the random result error was disappeared. The source code with code A showed random error after 6000+ iterations with unchanged input values like this:

...
Iteration #: 6446
Input: 011001001110111101100010, Output: 000110100000100011100011  <= correct results
Iteration #: 6447
Input: 011001001110111101100010, Output: 000110100000100101011011 <= wrong results from 6447 loops
Iteration #: 6448
Input: 011001001110111101100010, Output: 000110100000100101001011 <= another wrong results
Iteration #: 6449
Input: 011001001110111101100010, Output: 000110100000100101001011 <= wrong
Iteration #: 6450
Input: 011001001110111101100010, Output: 000110100000100011100011 <= wrong
Iteration #: 6451
Input: 011001001110111101100010, Output: 000110100000100110101011 <= wrong
...

In this code, please note that the efficiency of sc_biguint<1>(1) is not the issue at this post, because it's simply translated from another source code by scripts and directives.

Now code B shows no error from the output, and it does not have any valgrind nor purify error messages as well, while code A has errors. Although valgrind and purify might have a false positive, this error case shows that there is something wrong with the concatenation operator. Please correct me if there is something I missed. Thank you.

[Philipp A Hartmann]

The reason I mention about the concatenation operator is that I have a workaround that removed the random result error after replacing the concatenation operator of sc_biguint to arithmetic equations.

Ok, after having a closer look at your code, I know remember that a similar issue has popped up very shortly before the release of SystemC 2.3.0. On Microsoft VC++ something strange has been going on in the sc_concatref conersion to sc_big(u)int, which especially affects the comparison operator in certain corner cases.

Your workaround is known to avoid this problem.

Since a "hotfix" made it into the 2.3.0 release (see src/sysc/datatymes/misc/sc_concatref.h:247, and we have not observed this (or a similar) problem on other platforms, we need more information from your side:

• SystemC version (Accellera's 2.3.0, right?)
  
• platform, compiler, compiler flags
  
• compile/runtime warnings and errors
  
• a self-contained code sample, preferable less than 100 lines, demonstrating the problem
  

Now code B shows no error from the output, and it does not have any valgrind nor purify error messages as well, while code A has errors. Although valgrind and purify might have a false positive, this error case shows that there is something wrong with the concatenation operator. Please correct me if there is something I missed. Thank you.

Any valgrind and purify reported memory leaks are probably false positives here. Reported accesses to uninitialized memory may be a better indication for the bug's origin. Can you paste the (first) related error in this case?

You can also download the SystemC regression test suite from the accellera.org website and check the

systemc/datatypes/misc/concat/test07

test case, which has originally triggered the related issue on MSVC.

Greetings from Oldenburg,

Philipp