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

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; } pre

@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 whi