Memory leak when sc_event is notified twice

[Lukas Steiner]

The SystemC standard says:

5.10.8 Multiple event notifications
A given event shall have no more than one pending notification.
If function notify is called for an event that already has a notification pending, only the notification
scheduled to occur at the earliest time shall survive. The notification scheduled to occur at the later time
shall be cancelled (or never be scheduled in the first place). An immediate notification is taken to occur
earlier than a delta notification, and a delta notification earlier than a timed notification. This is irrespective
of the order in which function notify is called.

If I run the following example the simulation stops after 100000000 ps as intended, however, the memory usage of the program increases rapidly to 1GB and more. 
 

#include <iostream>
#include <systemc.h>

SC_MODULE(Tester)
{
    sc_event event;
    uint64_t counter = 0;

    SC_CTOR(Tester)
    {
        SC_METHOD(process);
        sensitive << event;
    }

    void process()
    {
        if (counter == 100000000)
            sc_stop();

        counter++;

        event.notify(1, SC_MS);
        event.notify(1, SC_PS);
    }
};

int sc_main(int argc, char **argv)
{
    Tester tester("Tester");
    sc_start();

    return 0;
}

When both event notifications are swapped the memory leak is gone. When SC_MS is replaced by SC_US, the memory usage increases a lot slower.

The program was tested with the latest SystemC version from GitHub as well as SystemC 2.3.3 on the WSL with GCC 8 and GCC 6.

[maehne]

Thanks @Lukas Steiner for reporting this issue! I have forwarded it to the SystemC LWG for investigation.

[Lukas Steiner]

@maehne Are there any news regarding the bug?

[maehne]

No, unfortunately not yet. Due to the summer vacation period, no one found yet the time to investigate and find a potential fix for that issue.

[AmeyaVS]

Hello @Lukas Steiner,

Can you attach the result of any memory checker tool? e.g. valgrind etc.

Regards,

Ameya Vikram Singh

[Lukas Steiner]

Hello @AmeyaVS, you can find the results of Valgrind in the attached file (valgrind --tool=memcheck --leak-check=full --show-leak-kinds=all ./Tester). The interesting parts of the report are also shown below.

The insertion of sc_event_timed instances into m_timed_events of sc_simcontext seems to be the problem (sc_event.cpp). These instances are never deleted, so the m_heap of sc_ppq_base is growing very fast (sc_pq.cpp). 

If the events are notified in reverse order, it seems that the check 

if( m_timed->m_notify_time <= m_simc->time_stamp() + t ) {
  return;
  }

prevents the insertion. 

 

==18609== HEAP SUMMARY:
==18609==     in use at exit: 247,263,893 bytes in 156,323 blocks
==18609==   total heap usage: 156,408 allocs, 85 frees, 421,842,196 bytes allocated
...
==18609== 160,000,000 bytes in 156,250 blocks are still reachable in loss record 63 of 63
==18609==    at 0x483577F: malloc (vg_replace_malloc.c:299)
==18609==    by 0x1112F6: sc_core::sc_event_timed::allocate() (sc_event.cpp:556)
==18609==    by 0x111C2B: sc_core::sc_event_timed::operator new(unsigned long) (sc_event.h:381)
==18609==    by 0x1102C8: sc_core::sc_event::notify(sc_core::sc_time const&) (sc_event.cpp:161)
==18609==    by 0x10FA8E: sc_core::sc_event::notify(double, sc_core::sc_time_unit) (sc_event.h:412)
==18609==    by 0x10FD03: Tester::process() (main.cpp:23)
==18609==    by 0x12F19C: sc_core::sc_process_b::semantics() (sc_process.h:685)
==18609==    by 0x12F6D8: sc_core::sc_method_process::run_process() (sc_method_process.h:305)
==18609==    by 0x130E51: sc_core::sc_simcontext::crunch(bool) (sc_simcontext.cpp:486)
==18609==    by 0x12C921: sc_core::sc_simcontext::simulate(sc_core::sc_time const&) (sc_simcontext.cpp:887)
==18609==    by 0x12E6CC: sc_core::sc_start(sc_core::sc_time const&, sc_core::sc_starvation_policy) (sc_simcontext.cpp:1718)
==18609==    by 0x12E7F4: sc_core::sc_start() (sc_simcontext.cpp:1752)
==18609== 
==18609== LEAK SUMMARY:
==18609==    definitely lost: 0 bytes in 0 blocks
==18609==    indirectly lost: 0 bytes in 0 blocks
==18609==      possibly lost: 0 bytes in 0 blocks
==18609==    still reachable: 247,263,893 bytes in 156,323 blocks
==18609==         suppressed: 0 bytes in 0 blocks

valgrind_results.txt

[Philipp A Hartmann]

This is not really a memory leak, but a very bad „model“ for the current implementation. I wonder if you saw any such scenario in a real model?

„Canceled“ notifications like in your case will still be kept in the kernel‘s internal data structures until the notification time is reached (1ms in your case).  You would pile up 999,999,999 of these canceled notifications until they are „deallocated“, each of them taking entries in the event queue and 16 bytes for the notification itself. Which is a lot of memory.

I wrote „deallocated“ in quotes, because sc_event_timed uses a very simple memory pool based on a free list to reuse previously allocated structures.  So even when the canceled notifications are released, they won‘t be handed back to the OS (not even at the end of the simulation) but will be kept allocated for future notifications.  But they do not leak in an unintended way.

If you change your example to e.g. have the same number of iterations without piling up billions of pending events, you should see a stable memory consumption:

event.notify( 1, SC_NS );
event.notify( 1, SC_PS );

Hope that helps,
 Philipp

Edited September 5, 2020 by Philipp A Hartmann

[Lukas Steiner]

Hey Philipp, thanks a lot for your help!

In fact I found the issue in a real high level TLM model. I was "abusing" the kernel to find the earliest notification for an event that was triggered by different sources. If one of the sources did not want to trigger a real notification, it was just inserting a dummy with

event.notify(sc_max_time() - sc_time_stamp());

which would always be overwritten by a different source. I fixed the issue by manually calculating the earliest notification and only calling event.notify() once. 

But maybe you also come up with a better implementation in a future kernel version. 

Best Regards,

Lukas