Unix Programming - coredump

Author

coredump

Benjamin Wang

2004-11-23, 8:27 am

Hello,

I have a program run on solaris 8. It always coredump even before the first
code line is run. I have emptied its main function and only left two lines.
I found if it is linked with a library libduplex.so when it is compiled, it
will core dump and "test" will not be output. But if I did not link it with
the library libduplex.so, it will not generate coredump and "test" will be
output. This program looks like as follows:

#include <time.h>
#include <iostream.h>

ofstream OnDemandLogFile;

main()
{
printf("test\n");

return 0;
} //end main

How do I debug this kind of problem?
In addition, if I run this program on other solaris 8 machine, there is no
problem.

Thanks very much for your help!

Trent Buck

2004-11-23, 8:27 am

Quoth Benjamin Wang on or about 2004-11-23:
> I have a program run on solaris 8. It always coredump even before the first
> code line is run.

s/coredump/coredumps/

In C++, you can have non-static global initializers. For example

char x = getchar();

These intializers will be run before main() is entered. Your symptoms
suggest that there is a bug in an initializer for a non-static global
variable in the libduplex code, or in the way you are including /
linking to it.

Sorry I can't be more help; I'm not a C++ programmer.

-trent

Paul Pluzhnikov

2004-11-23, 8:27 am

"Benjamin Wang" <zwang2@lucent.com> writes:

> How do I debug this kind of problem?

The same way you debug any other coredump: run the program under
debugger (gdb, dbx), get the stack trace at the moment the problem
occures (when debugger stops with 'program received SIGSEGV', issue
"where" command).

If you do not have any idea what your stack trace means, post it
here, and someone may suggest likely cause.

Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.

Martin Carpenter

2004-11-23, 6:08 pm

"Paul Pluzhnikov" <ppluzhnikov-nsp@charter.net> wrote:

> The same way you debug any other coredump: run the
> program under debugger (gdb, dbx), get the stack trace
> at the moment the problem occures

I just happened to read about "backtrace past-main" for gdb yesterday. It
sounds like it may be useful in this case? See Ch.6 of the GDB User Manual.

Benjamin Wang

2004-11-24, 2:59 am

No dbx on the machine.
I just get trace the core file with pstack as follows and is there any clue
for the core dump?

> pstack core
core 'core' of 25227: pmOnDemandCli
----------------- lwp# 1 / thread# 1 --------------------
fe9ab9d4 mutex_trylock (ff1b997c, 0, 3400, 3528, ff10daa0, 1)
ff08a700 __1cDiosPsync_with_stdio6F_v_ (fefa6e74, 1, fefa9324, fefa6dec, 0,
0) + 28
fefa6f14 __1cFBlzOSEinit6F_i_ (ff16b7e0, 1, fefa5bb8, 36e4, 0, 0) + 4
fefa6e74 __SLIP.INIT_C (ff11a069, 4, 0, 40, 3400, 363c) + 1c
ff090d7c _init (0, ccad8, 1, ff3e2660, 29360, ff3bad78) + 2cc
ff3bad80 call_init (fe4f1070, 3, ff3e21f0, ff3e2660, 400000, fe4f1074) +
180
ff3c3844 elf_bndr (fee0c940, b09, ff3a1a7c, 0, ff3e2660, fee25319) + 3bc
ff3b2980 elf_rtbndr (ff084b70, 0, 0, 0, 0, 0) + 1c
ff1116a0 ???????? (0, 0, 3358, ff084b68, 3628, 0)
ff084b70 __1cNIostream_init2t6M_v_ (ff1b9888, fea1a87c, ff375f90, 88f84, 0,
0) + 58
fea43dec __1cU__STATIC_CONSTRUCTOR6F_v_ (0, 0, 0, fea59608, 293b0, 0) + 8
fea59624 _init (0, ccad8, 1, ff3e2660, 29360, ff3bad78) + 48
ff3bad80 call_init (fe4f0ff8, 3, ff3e21f0, ff3e2660, 400000, fe4f0ffc) +
180
ff3c3844 elf_bndr (fea33980, 61, ff2c0018, 0, ff3e2660, 19856) + 3bc
ff3b2980 elf_rtbndr (652b4, 0, 0, 0, 0, 0) + 1c
000a3edc ???????? (28, 0, 0, 0, 0, 0)
000652b4 __1cH__rwstdNlocale_vector4Cpn0AJfacet_i
mp__2t5B6MIrk2_v_ (ccda0,
ccda0, ffbed564, a, 0, 0) + 1c
00061da0 __1cH__rwstdKlocale_imp2t6MII_v_ (ccd78, a, 0, a3c18, ccd80,
ccda0) + 60
00062908 __1cDstdGlocaleEinit6F_v_ (ccd78, ccd78, a3c18, b9438, 0, 0) + 150
000758dc __1cDstdPbasic_streambuf4Ccn0ALchar_trai
ts4Cc___2t5B6M_v_ (b9430,
1, ffbed740, c14b8, b9438, b946c) + 4c
0006f180 __1cDstdNbasic_filebuf4Ccn0ALchar_traits
4Cc___2t5B6Mi_v_ (b9430,
0, a3c18, 0, 0, 0) + 14
0005ea64 __1cDstdIios_baseEInit2t5B6M_v_ (ffbed86f, b9430, 0, 0, 0, a3c18)
+ 40
0005f4c8 __SUNW_init_iostreams (5f4bc, fea1a87c, ff375f90, fea1a118, 0, 0)
+ c
fea07cb0 __1cH__CimplKcplus_init6F_v_ (b5974, fea1a884, 1, 4, ffffffff, 0)
+ 90
fea08220 _init (0, ccad8, 1, ff3e2660, 29360, ff3bad78) + 40
ff3bad80 call_init (fe4f0fe0, 3, ff3e21f0, ff3e2660, 400000, fe4f0fe4) +
180
ff3c3844 elf_bndr (fea0134c, 7c, ff2c042c, 0, ff3e2660, 230d1) + 3bc
ff3b2980 elf_rtbndr (ff35a88c, 0, ff375f90, 0, 0, 0) + 1c
000a3edc ???????? (0, 0, 0, ff35a878, 293b0, 0)
ff35a88c _init (0, ccad8, 1, ff3e2660, 29360, ff3bad78) + 40
ff3bad80 call_init (fe4f0f08, 3, ff3e21f0, ff3e2660, 400000, fe4f0f0c) +
180
ff3c3844 elf_bndr (ff3414c8, 7e, ff3a0818, 0, ff3e2660, 20ad3) + 3bc
ff3b2980 elf_rtbndr (fe852bac, 0, 0, 0, 0, 0) + 1c
000a3edc ???????? (fe864280, 178e0, 0, fe9be000, 293b0, 0)
fe852bac _init (0, ccad8, 1, ff3e2660, 29360, ff3bad78) + 2c
ff3bad80 call_init (fe4f0e0c, 1, ff3e21f0, ff3e2660, 400000, fe4f0e20) +
180
ff3ba9f8 setup (ff3a0018, ff3e2000, ff3e20d0, ff3e3c30, ff3e2030,
ff3e2660) + 730
ff3c4d58 _setup (d4, ff3e2660, ff3a0018, 5, 100d4, 0) + 8a8
ff3b2938 _rt_boot (0, 0, 0, 0, 0, 0) + 88
00000000 ???????? (0, 0, 0, 0, 0, 0)
----------------- lwp# 2 / thread# 2 --------------------
fe91b688 _signotifywait (fe9be000, 59, 0, 0, ffbed9cc, 4) + 8
fe9a2028 thr_yield (0, 0, 0, 0, 0, 0) + 8c
----------------- lwp# 3 --------------------------------
fe91922c _door_return (3, fe9bf690, fe9bf6a8, 3, fe9be000, 1) + 10
fe99a72c _lwp_start (fe4d5d70, 0, 6000, ffbed9a4, 0, 0) + 18
fe9a2028 thr_yield (0, 0, 0, 0, 0, 0) + 8c
-------------------------- thread# 3 --------------------
fe99ddb4 _reap_wait (fe9c29e8, 20528, 0, fe9be000, 0, 0) + 38
fe99db0c _reaper (fe9bee38, fe9c4748, fe9c29e8, fe9bee10, 1, fe400000) +
38
fe9ab6e0 _thread_start (0, 0, 0, 0, 0, 0) + 40

"Paul Pluzhnikov" <ppluzhnikov-nsp@charter.net> wrote in message
news:m3d5y4boa9.fsf@salmon.parasoft.com...
> "Benjamin Wang" <zwang2@lucent.com> writes:
>
>
> The same way you debug any other coredump: run the program under
> debugger (gdb, dbx), get the stack trace at the moment the problem
> occures (when debugger stops with 'program received SIGSEGV', issue
> "where" command).
>
> If you do not have any idea what your stack trace means, post it
> here, and someone may suggest likely cause.
>
> Cheers,
> --
> In order to understand recursion you must first understand recursion.
> Remove /-nsp/ for email.

Paul Pluzhnikov

2004-11-24, 8:12 am

"Benjamin Wang" <zwang2@lucent.com> writes:

A. Because doing so makes the conversation harder to read.
Q. Why should I not top-post?

Please do not top-post. Rest of the message re-ordered.

Also please read about proper way to trim the message to which you
are replying: http://c2.com/cgi/wiki?TrimYourPosts

> "Paul Pluzhnikov" <ppluzhnikov-nsp@charter.net> wrote
[vbcol=seagreen]
> No dbx on the machine.

So what stopped you from installing gdb on it?

> I just get trace the core file with pstack as follows and is there any clue
> for the core dump?
>
> core 'core' of 25227: pmOnDemandCli
> ----------------- lwp# 1 / thread# 1 --------------------
> fe9ab9d4 mutex_trylock (ff1b997c, 0, 3400, 3528, ff10daa0, 1)
> ff08a700 __1cDiosPsync_with_stdio6F_v_ (fefa6e74, 1, fefa9324, fefa6dec, 0,

Your stack trace, after passign through c++filt:

mutex_trylock()
void ios::sync_with_stdio()
BlzOS::init()
__SLIP.INIT_C()
_init() ## this init is probably in your library
call_init()
elf_bndr()
elf_rtbndr()
???????? ()
Iostream_init::Iostream_init()
__STATIC_CONSTRUCTOR()
_init()
call_init()
elf_bndr()
elf_rtbndr()
????????()
__rwstd::locale_vector<__rwstd::facet_imp*>::locale_vector()
__rwstd::locale_imp::locale_imp(unsigned
,unsigned)()
void std::locale::init()
std::basic_streambuf<char,std::char_traits<char> >::basic_streambuf()
std::basic_filebuf<char,std::char_traits<char> >::basic_filebuf()
std::ios_base::Init::Init()
__SUNW_init_iostreams()
__Cimpl::cplus_init()
_init()

Apparently your library has a global object, which is being
constructed, but which depends on one of the global iostreams,
which have not been completely constructed yet.

One possible explanation for the crash is that you built the library
in which 'BlzOS::init()' resides incorrectly. Did you link it with
'ld' by any chance? Use 'CC -G' instead.

Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.