c++ class destructor

Hello there!

I have noticed some strange behavior on c++ classes in shared objects, and perhaps someone could help me on this one. I noticed this after long time try, and do not really understand it.

Defining a non virtual destructor in a class in a shared object allways lead to guru meditations trying to call it.
For example:

namespace Amiga
{
class Test
{
public:
Test();
~Test();
};
}

will cause the crash if done in an so-lib.
Doing:

namespace Amiga
{
class Test
{
public:
Test();
virtual ~Test();
};
}

will not cause it to crash, it simply works.
I must admit, in my "crash" code I plain forgot to use "virtual" (the class I am writing will be derived from, so i actually needed the virtual method. But what if I just write a plain class not needed to be derived from, and not in need of a virtual destructor?

I did not test it in a simple c++ program, it was compiled in a lib with -fPIC and -shared, the executioner which loads my lib is done with -use-dynld -lauto.

Anyone has seen this before??? Am I in need of some other compiler/linker flags which I am forgetting?

Thanks in advance for any help!
JeanLuc

@jeanluc72

Could you post additional info, like when it crashes, what the GrimReaper log looks like? etc etc Otherwise it's very hard to work out what's up.

GR wise probably just the stack trace and diassembly parts would be useful for now....

@jeanluc72

No idea about the shared object problem, but you should always declare destructors virtual. Otherwise, the following code causes the wrong destructor to be called.



In the code above, if the destructors had all been declared virtual, then the destructor for class B would have been called, resulting in destructing the object properly. The code above could cause all sorts of nasty things.

Hans

@jeanluc72

Just a thought are you using the latest SDK?

If you do a readelf -d yousobj.so what does it show?

sorry to get back to you this late, but Christmas tends to go with social obilgations ))

@broadblues
Can I sent you the crashlog by mail?
The readelf shows what it should show:

Dynamic section at offset 0x100a4 contains 13 entries:
Tag Type Name/Value
0x00000001 (NEEDED) Shared library: [libstdc++.so]
0x00000001 (NEEDED) Shared library: [libgcc.so]
0x00000001 (NEEDED) Shared library: [libc.so]
0x00000004 (HASH) 0x1000094
0x00000005 (STRTAB) 0x1000210
0x00000006 (SYMTAB) 0x10000f0
0x0000000a (STRSZ) 376 (bytes)
0x0000000b (SYMENT) 16 (bytes)
0x00000007 (RELA) 0x1000388
0x00000008 (RELASZ) 24 (bytes)
0x00000009 (RELAENT) 12 (bytes)
0x6ffffff9 (RELACOUNT) 2
0x00000000 (NULL) 0x0

Does look quite normal to me...

Grim reaper tells me:

Guru Med 80000003
Task 0x... ("") generated an error of type DSI in address 0x...
Redzone was not damaged.
Stackpointer is inside bounds.

The weird thing: I press "more", and "Continue program". And guess what: the program continues and the output makes sense ))

@hans
Thanks for reminding me As I described in my start post, I forgot to add the virtual keyword, and the error occured to me in a piece of code I did not tend to write like I posted it. I know about the use of virtual destructors in classes to be derived, but it is anyway a good reminder for me and all readers here )) Nevertheless, i still wonder why it happens, because as long as the class is not derived from, the construction is correct, the behavior on Amiga is (what I think about it) not...

@jeanluc72

Quote:

It tells me want I wanted that's for sure but in a sense it's not what it should be, it shows you haven't upgraded you SDK to the latest (specifically the binutils)
there a fixed bugs WRT sobjs in the latest SDK which may or may not be the cause of your problem.

compare with this one

readelf -d AV:blender_beta/sobjs/libIex.so

Dynamic section at offset 0x2106c contains 19 entries:
Tag Type Name/Value
0x00000001 (NEEDED) Shared library: [libpthread.so]
0x00000001 (NEEDED) Shared library: [libstdc++.so]
0x00000001 (NEEDED) Shared library: [libgcc.so]
0x00000001 (NEEDED) Shared library: [libc.so]
0x00000004 (HASH) 0x100000b4
0x00000005 (STRTAB) 0x10003ae0
0x00000006 (SYMTAB) 0x100012e0
0x0000000a (STRSZ) 14837 (bytes)
0x0000000b (SYMENT) 16 (bytes)
0x00000003 (PLTGOT) 0x10016000
0x00000002 (PLTRELSZ) 336 (bytes)
0x00000014 (PLTREL) RELA
0x00000017 (JMPREL) 0x1000d304
0x00000007 (RELA) 0x100074d8
0x00000008 (RELASZ) 24444 (bytes)
0x00000009 (RELAENT) 12 (bytes)
0x6000000e (AMIGAOS_DYNVERSION) 0x2
0x6ffffff9 (RELACOUNT) 844
0x00000000 (NULL) 0x0


Notice the line
0x6000000e (AMIGAOS_DYNVERSION) 0x2

Quote:

Just cut and paste the stack trace / dissassembly parts here if you want to save space...

@broadblues

I am starting to understand the problems now. I use the compiled version of the crosscompiler from zerohero, I did not compile the crosscompiler and binutils myself. It seems the whole cross environment is not updated towards the newest SDK from hyperion (my impression). So I am using binaries which are not compatible with the newest SDK. It all makes sense now.

We have been building a linux script at the end from last year to get the cross tools working, and I remember we had some rough days and nights getting it all together. Building the cross toolchain for linux 64bit was not that easy, and I fear we will run into this nightmare again. I also noticed zerohero has put the cross compiler for AOS4 offline, so I guess he is having the same nightmare as we did last year

I hope there will be a day we have a working script to buil the cross toolchain for at least some standard linux distros.

I personally do my amiga coding on Code::Bench, and then transfer it by tool written by myself to the Amiga (kind of a mini ftp-server on the amiga side).
I will upload this tool in the next couple of days on os4depot.

Anyway thanks for your help, it cleared a lot of things for me. And I am again in for the little nightmare now

JeanLuc