my application uses a static vector which is defined as a member variable of a class. When i try to close my application then it dumps a core . On analyzing the core ,it is pointing to the static vector initialization. I am running my application in red hat 5.3 and the g++ compiler version is gcc version 3.4.6 20060404 (Red Hat 3.4.6-8).
have anyone faced a similar issue . Plz help
Jump to Postdid you send the SIGARBT signal instead of the SIGKILL ?
when you send a process SIGARBT it happens.sure you are calling abort() some where.
did you send the SIGARBT signal instead of the SIGKILL ?
when you send a process SIGARBT it happens.
sure you are calling abort() some where.
did you send the SIGARBT signal instead of the SIGKILL ?
when you send a process SIGARBT it happens.sure you are calling abort() some where.
[Anil] Nick , i was sending a SIGINT signal (ctrl c) to close my process.
some more info on the problem
kindly find the code snippet and also the core file backtrace.
I am stopping the process by giving a ctrl c [SIGINT].
Initially the process was not dumping core ,after about 30-40 times of stopping and starting (stopping by ctrl c) its now dumping a core after every SIGINT .
include file --- TINTStats.h
23 class TINTStats
24 {
.
private :
static vector<int> ms_handles;
}
cpp file -- TINTStats.cpp
28 vector<int> TINTStats::ms_handles;
backtrace of core file ---
(gdb) bt
#0 0xffffe405 in __kernel_vsyscall ()
#1 0x008a7d80 in raise () from /lib/libc.so.6
#2 0x008a9691 in abort () from /lib/libc.so.6
#3 0x008e024b in __libc_message () from /lib/libc.so.6
#4 0x008e80f1 in _int_free () from /lib/libc.so.6
#5 0x008ebbc0 in free () from /lib/libc.so.6
#6 0x001b4571 in operator delete () from /usr/lib/libstdc++.so.6
#7 0x080c11d5 in __gnu_cxx::new_allocator<int>::deallocate (this=0xf7fc3aa0, __p=0x9a8f008)
at /usr/lib/gcc/i386-redhat-linux/3.4.6/../../../../include/c++/3.4.6/ext/new_allocator.h:86
#8 0x080bfe03 in std::_Vector_base<int, std::allocator<int> >::_M_deallocate (this=0xf7fc3aa0, __p=0x9a8f008, __n=2)
at /usr/lib/gcc/i386-redhat-linux/3.4.6/../../../../include/c++/3.4.6/bits/stl_vector.h:117
#9 0x080be965 in ~_Vector_base (this=0xf7fc3aa0)
at /usr/lib/gcc/i386-redhat-linux/3.4.6/../../../../include/c++/3.4.6/bits/stl_vector.h:106
#10 0x080bc140 in ~vector (this=0xf7fc3aa0)
at /usr/lib/gcc/i386-redhat-linux/3.4.6/../../../../include/c++/3.4.6/bits/stl_vector.h:256
#11 0xf7f1b44a in __tcf_0 () at TINTStats.cpp:28
#12 0x008aafe9 in __cxa_finalize () from /lib/libc.so.6
#13 0xf7e0c166 in __do_global_dtors_aux () from /usr/aethos/psa/current/lib/libservice01.so
#14 0xf7f39f4e in _fini () from /usr/aethos/psa/current/lib/libservice01.so
#15 0x0086f7ee in _dl_fini () from /lib/ld-linux.so.2
#16 0x008aad39 in exit () from /lib/libc.so.6
#17 0x00894e94 in __libc_start_main () from /lib/libc.so.6
#18 0x08071161 in _start ()
hi friends ....finally i have got a workaround for the above mentioned issue ..nd i have released my patch ..
well the workaround is to use a static pointer to vector instead of a static vector. the memory for this vector can be dynamically allocated during the initialisation(staticInit()) and freed at the time of dispose.
with this change there is no longer any core dump happening .
friends, if anyone knows the exact reason for the core dup ..then plz post it ...
We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.