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

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

@maehne Are there any news regarding the bug?

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.