Lukas Steiner Posted July 24, 2020 Report Posted July 24, 2020 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 1 Quote
maehne Posted July 25, 2020 Report Posted July 25, 2020 Thanks @Lukas Steiner for reporting this issue! I have forwarded it to the SystemC LWG for investigation. Quote
Lukas Steiner Posted August 24, 2020 Author Report Posted August 24, 2020 @maehne Are there any news regarding the bug? Quote
maehne Posted August 25, 2020 Report Posted August 25, 2020 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. Quote
AmeyaVS Posted August 29, 2020 Report Posted August 29, 2020 Hello @Lukas Steiner, Can you attach the result of any memory checker tool? e.g. valgrind etc. Regards, Ameya Vikram Singh Quote
Lukas Steiner Posted September 2, 2020 Author Report Posted September 2, 2020 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 Quote
Philipp A Hartmann Posted September 5, 2020 Report Posted September 5, 2020 (edited) 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 maehne 1 Quote
Lukas Steiner Posted September 16, 2020 Author Report Posted September 16, 2020 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 Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.