Above you say it compiles now, maybe something you did to get it to compile it is causing the runtime error. Try using gdb, the GNU debugger to determine which line is causing the crash and what parameters values are being passed in.
Marc
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I got such similar core dumps on Solaris for exactly the same tests that I thought to mention this - turned out to be shared object getting destructed twice or more - I ended up doing reference counting of the "shared" class using shared and shared_impl classes.
HOWEVER I had already hacked around with the code to make it compliant with a more "fussy" STL implementation (some std includes in redhat include other includes that in the STL standard they do not have to and size_t is in the std namespace etc) so this may be a red herring. Put some quick debug code in the destructor to prove this.
Andy
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
./bit_vector
----------------------------------------
Bit vector test.
Reserved 5 blocks starting at block: 0
Reserved 3 blocks starting at block: 5
Reserved 7 blocks starting at block: 8
Cleared 2 blocks starting at block: 5
Reserved 3 blocks starting at block: 15
Reserved 2 blocks starting at block: 5
Reserved 1 block starting at block: 18
Passed: 7
Failed: 0
----------------------------------------
./shared_header
make: *** [run_test] Segmentation fault (core dumped)
I found only 2 tests can run normally(bit_vector and lock_test ). Others core dumped.
Can you help me?
I'm using gcc 3.3.3 under slackware9 (kernel 2.4.20)
Thanks.
Above you say it compiles now, maybe something you did to get it to compile it is causing the runtime error. Try using gdb, the GNU debugger to determine which line is causing the crash and what parameters values are being passed in.
Marc
I got such similar core dumps on Solaris for exactly the same tests that I thought to mention this - turned out to be shared object getting destructed twice or more - I ended up doing reference counting of the "shared" class using shared and shared_impl classes.
HOWEVER I had already hacked around with the code to make it compliant with a more "fussy" STL implementation (some std includes in redhat include other includes that in the STL standard they do not have to and size_t is in the std namespace etc) so this may be a red herring. Put some quick debug code in the destructor to prove this.
Andy