hpux B.11.31 core crash but not in B.11.23

[Meir Yanovich]

Hello all
we compiling the application on :
HP-UX B.11.23 U ia64 with aCC HP C/aC++ B3910B A.06.15 linked with STLport 5.10

and when we run the application on B.11.23 machine , every thing is working great
but when we move the application to B.11.31
we get core that say :

1 0x4000000000aabe30:0 in stlp_std::basic_string,stlp_std::allocator >::_M_assign(char const*,stlp_std::allocator)+0x560 ()

how can we test what is the problem ?

[Steven E. Protter]

Shalom,

Install and use the gdb debugger for HP-UX 11.31 and analyze the core file.

use tusc to analyze the process as running if possible.

tusc is a system utility for hp-ux that mimics the functionality of strace on Linux.

SEP

[Meir Yanovich]

well we did try to analyze the core with gdb
we didn't found any thing except the problem with the :

#1 0x4000000000aabe30:0 in stlp_std::basic_string,stlp_std::allocator >::_M_assign(char const*,stlp_std::allocator)+0x560 ()

now we compiled the application on hpux 31 and
and run the application on hpux31 in our local server and its running great but when we move to different hpux 31
we still we getting this error .
what else we can try and find in the machine configuration that can impact ?

[Meir Yanovich]

also im getting this error in gdb :
#0 0x4000000003057620:0 in __milli_memmove+0x80 ()

[Dennis Handly]

>when we run the application on B.11.23 machine, every thing is working great
but when we move the application to B.11.31

11.31 should be forward compatible. If it fails it means your application is illegal and may have some uninitialized variables, or some problems with different inputs.

1 0x4000000000aabe30:0 stlp_std::basic_string,stlp_std::allocator >::_M_assign(char const*, stlp_std::allocator)+0x560
>how can we test what is the problem?

By printing out the variables that are used there. (Have you compiled with -g0?)
Or by looking at the machine code with:
(gdb) frame 1
(gdb) print *this
(gdb) disas 0x4000000000aabe30-16*20 0x4000000000aabe30+16*4
(gdb) info reg

Are you in a thread? You could have a thread stack overflow.

>we didn't found anything except the problem with the:

But did you look at the statement in question and look at all the variables?

>what else we can try and find in the machine configuration that can impact?

What does your application do? Does it look at your machine configuration?

>I'm getting this error in gdb:
#0 0x4000000003057620:0 __milli_memmove+0x80

This is a user error. You have bad addresses or a length in your call to memcpy or memmove.

What does this show?
(gdb) p /x $r32
(gdb) p /x $r33
(gdb) p /x $r34

Does it match what you see in frame 1?

[Meir Yanovich]

hello and thanks for the reply i will try to answer the questions
>Are you in a thread? You could have a thread stack overflow.
well i don't know .. how can i check this ?
>But did you look at the statement in question and look at all the variables?
yes we set all variables.
>What does your application do? Does it look at your machine configuration?
the application reads and process text files
in multi threaded mode. it does not read machine configuration just it local application configuration
just reminder we have the same machine
with the same configuration ( as we know .. )
and the application works fine .
im attaching the output of the gdb command in text file i do not know how to analyze it.
can you please take a quick look at it .
Thanks

[Duncan Edmonstone]

>> just reminder we have the same machine
with the same configuration ( as we know .. )
and the application works fine .


So have you compared the pathc level and product levels of the 2 systems?

If they're on the same network then:

sysdiff

will do a quick comparison for you.

Otherwise an "swlist -l product" output from both systems run through diff should show any differences.

HTH

Duncan

[Dennis Handly]

>well i don't know. how can I check this?

Provide the full stack trace.

>yes we set all variables.

Do they all have valid values? You need to print the contents of the string.

>reads and process text files in multi-threaded mode.

You might want to explain that? No more than one thread per file?

>I'm attaching the output of the gdb command

You need to redo this:
(gdb) bt
(gdb) frame 0
(gdb) disas $pc-16*20 $pc+16*4
(gdb) info reg

It appears you have a null pointer as a target. Relink your application with -z.

[Meir Yanovich]

Hello and thanks for the fast reply
well i cant do sysdiff because the second hp
in different place not related to our network×¥
also swlist -l product is problem because i have no root privileges but i emailed to the sysadmin and i hope i will have the diff shortly
about the questions:
>Do they all have valid values? You need to print the contents of the string.
which variable to print ? there is attached stack trace can you please point me where ?

>You might want to explain that? No more than one thread per file?
no its balk of files per thread

>Provide the full stack trace.
attached
>You need to redo this:
>(gdb) bt
>(gdb) frame 0
>(gdb) disas $pc-16*20 $pc+16*4
>(gdb) info reg
also in the attached file
Thanks

[Meir Yanovich]

im attaching the the swlist diff print
the test1 is the problematic machine
on the left.
thanks