frequent Core Dumps in HP-UX

[Lalit Seth]

Hi all,

I have craeted a small c++ daemon running in HP-UX 11i 32 bit.

I am using gcc 3.2 i have configured gcc with following options.

./configure \
> > --enable-languages=c,c++ \
> > --enable-threads=posix \
> > --with-gnu-as \
> > --with-gnu-ld

As far as Daemon is concerned its an multithreaded application creating socket and hving 5 minimum threads running simaltaneously and a new thread is created after every 15 sec whos life is of 5 secs only.

But still gcc uses system linker as i tried to install bin-utiltites 2.13 but failed to install Gnu ld also i don't know whether its using gnu assembler or not as -g option do wrk and i can use GDB to debug.

I can run the daemon successfully but it does Memory fault and core dumps after few mins of exection which is varied a lot and the location of core dump is varing every time.

But it runs fine under RH8 and RH9.

I jst wnt to know is this a common problem in mutithreaded applications in HP-UX 11i 32 bit and if yes how can i remove this. is there any patch available to remove this type of errors. Does system linker or assemebler is causing these king of problms. Does using GNU LD and GNU AS can make this wrk with no prblm as on RH8 and RH9 this is not an problem.

Many Thanks
Lalit Seth

[Zeev Schultz]

Hi

What does this daemon do - malloc()'s?
What is the dump message - run 'file core' -
if its SIGSEGV - could be that data/stack/text segment isn't enough for your code (check : "kmtune | grep max[d,s,t]siz").

Another nice thing would be:

a)gdb on the binary and seeing the stack trace (bt)
b)tusc -vfp (where PID is your code's PID and tusc is here: http://hpux.cs.utah.edu)

rgds

Zeev

[Lalit Seth]

Many thnks for instance reply

I also wanted to know tht the frequent Memory faults or core dump can be result of not using Gnu ld instead of System Linker as my app use sytem linker of HP rather than GNUld.

My daemon is in c++ and yes frequent memory allocation and delocaion is done.

[Mike Stroyan · Accepted solution]

The most likely explanation is that the program has synchronization defects which did not show up until you ran it on HP-UX. That would be very likely if the other systems you used were single processor machines while the HP-UX system had multiple processors. It is difficult to test for correctness in multithreaded programs. It is really common to have defects that will almost never show themselves until a program is run on multiple processors.

It is very unlikely that the choice of linker would cause a problem that occurs at random intervals well after a program is running.

[A. Clay Stephenson]

Are you using realloc()? I've seen many cases where moving to a different platform will suddenly cause problems --- actually the problems were there all along due to the misuse of realloc. This occurs when a realloc'ed area is not able to expand "in place" so that pointers which were valid for the old allocation are no long valid BUT because the space has not yet be reallocated, the old pointers APPEAR to be okay. This can lead to failures which occur at seemingly random times.

Of course, missing or badly coded thread synchronization routines (mutex) will also cause exactly this kind of problem.

At this point, it is time to get some stack traces.