sc_module/sc_object dynamic creating and delete

[Jiang]

Hello,

I have a access violation issue in my systemc program, the root cause is stated in below link;

Since when the parent's delete called, the kernel seems will colllect its chidren, but its children has already been "delete"'d in parent's DTOR;

But I do want to use dynamic creating of sub components becasue for example, I have a array of same class and want to initiate them in a for loop;

Anyone have idea on this?

 

[Eyck]

Without showing code to illustrate the issue it's hard to gitve suggestions. Therefore some general remarks:

• there is basically no difference in using a if you create submodules as members (aka on the stack) or as pointer to members (aka on the heap). In the first case the compiler takes a lot of burden from you managing the lifetime
• You should delete objects in the opposite order than they are created. This is what the compiler does when automatically creating the destructor
• Avoid raw pointer, use unique_ptr instead. They implicitly manage the lifetime of your objects

The best way to ask for help on such problems if you could provide an example using https://www.edaplayground.com/home

[Jiang]

2 hours ago, Eyck said:

Without showing code to illustrate the issue it's hard to gitve suggestions. Therefore some general remarks:

• there is basically no difference in using a if you create submodules as members (aka on the stack) or as pointer to members (aka on the heap). In the first case the compiler takes a lot of burden from you managing the lifetime
• You should delete objects in the opposite order than they are created. This is what the compiler does when automatically creating the destructor
• Avoid raw pointer, use unique_ptr instead. They implicitly manage the lifetime of your objects

The best way to ask for help on such problems if you could provide an example using https://www.edaplayground.com/home

Hi Eyck and All

Thanks for the advice, and I understand using unique ptr will solve this issue and it did, but stil want to dig this a bit further;

Just look at the stack trace at 2nd image, it's accessing orphan_child_objects() on 3rd image which triggers access on recycled memory area;

By looking at 4th image, this '*it' object 0x17108e935a0 is actually fifo[9], which has already been destroyed in 1st image line 962;

In this case, some of the elements in fifo[] are still there (marked as deleted on heap but still accessible), and some others are not because I think the system recycled them after the delete op;

Why not systemc kernel just wipe out all sub components before it's parent, but instead still need to access them such as in orphan_child_objects()?

In this way I can only use smart pointers, though it's a good idea. If it's true, but seems I can't find this guildline in any systemc documents;

 

 

 

Edited September 12 by Jiang
more explain