core dump doesn't show back trace - HP UX

This is a discussion on core dump doesn't show back trace - HP UX ; I am having a core dump (aix 5.1) which doesnt show back trace. It only shows frame#0 pthread_mutex_destroy()......... I can not figure out the problem point in my c++ application. It also says .. no debugging symbols found. My application ...

+ Reply to Thread
Results 1 to 11 of 11

Thread: core dump doesn't show back trace

  1. core dump doesn't show back trace

    I am having a core dump (aix 5.1) which doesnt show back trace. It only
    shows frame#0 pthread_mutex_destroy().........
    I can not figure out the problem point in my c++ application.
    It also says .. no debugging symbols found.
    My application is built without "-g" option.
    What do i need to do?


  2. Re: core dump doesn't show back trace

    "pankajtakawale" writes:

    > I am having a core dump (aix 5.1) which doesnt show back trace.


    In which debugger? Sometimes gdb is unable to decode stack trace
    when dbx can do so.

    > It only shows frame#0 pthread_mutex_destroy().........
    > I can not figure out the problem point in my c++ application.


    You may have corrupted stack to the point where recovering the
    stack trace is impossible.

    > What do i need to do?


    - Step through your code, periodically executing "where" and see
    at which point the stack "disappears".
    - Remove application code piece by piece, until you isolate the
    problem, or until you arrive at a <100 line test case in which you
    do not see the problem but which still crashes. Post it here and
    the bug will be revealed.
    - Use specialized tools to help you catch all kinds of bugs, e.g.
    Insure++ (www.parasoft.com) or ZeroFault (www.zerofault.com)

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

  3. Re: core dump doesn't show back trace

    Paul Pluzhnikov writes:

    > "pankajtakawale" writes:
    >
    >> What do i need to do?

    >
    > - Step through your code, periodically executing "where" and see
    > at which point the stack "disappears".


    - Use the WDB RTC enhancements to see if WDB can catch your problem.
    http://h21007.www2.hp.com/dspp/tech/...3,1662,00.html

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

  4. Re: core dump doesn't show back trace

    Thanx for your comments.
    Im using gdb. I'll update the results of dbx.

    I can not use narrow down method u have suggested, as i can not
    reproduce problem on my machine. Im facing problem on client side.

    One more observation is :
    Process is showing very abrupt behaviour.
    Last time I faced similar problem on windows 2003.
    On 2003, process was showing abrupt behaviour only in case of heavy
    memory requirement. But after building application using .Net compiler
    (VC7) instead of VC6, problem *disappeared*.
    Now on AIX 5.1, memory requirement of process is huge. Do i need to
    build application with other compiler? Im usin xlc compiler.
    Because same application is running fine on windows .


  5. Re: core dump doesn't show back trace

    "pankajtakawale" writes:

    > I can not use narrow down method u have suggested, as i can not
    > reproduce problem on my machine. Im facing problem on client side.


    In that case, you should definitely test your app with specialized
    tools I mentioned before.

    > One more observation is :
    > Process is showing very abrupt behaviour.


    What the hell does that mean?

    > Last time I faced similar problem on windows 2003.
    > On 2003, process was showing abrupt behaviour only in case of heavy
    > memory requirement. But after building application using .Net compiler
    > (VC7) instead of VC6, problem *disappeared*.


    You are programming by coincidence:
    http://www.awprofessional.com/articl...le.asp?p=31538
    Don't do that. The problem most likely didn't disappear, it simply
    moved someplace else, where its effect remains hidden.

    > Now on AIX 5.1,


    And you are posting this to HP-UX group because?

    > memory requirement of process is huge.


    Do you mean that the app is supposed to take (say) 10MB but instead takes 100?
    Did you observe that "unexplained" behaviour on your development machine?

    If so, did you investigate it? It is quite likley related to the
    problem your client is facing.

    > Do i need to
    > build application with other compiler? Im usin xlc compiler.


    "Randomly" changing compiler or compilation options in hope that
    the problem will just disappear is a sure sign of programming
    by coincidence.

    > Because same application is running fine on windows .


    That means nothing: it is quite often the case that many serious
    bugs are discovered while porting from one platform to another.

    Besides, you *know* that there is a problem on Windows as well,
    when the app is compiled with VC6. Did you check your program with
    e.g. BoundsChecker on Windows? If not, why not?

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

  6. Re: core dump doesn't show back trace

    Here is the snippet of truss output

    thread_twakeup(0x000C08CF, 0x10000000, 0xF00D6348, 0xF013C420,
    0x000000EC, 0x00000004, 0x00000018, 0x00000004) = 0x00000000
    = 0x10000000
    sbrk(0x000000D0) = 0x00000000
    Err#12 ENOMEM
    sbrk(0x00000090) Err#12 ENOMEM
    sbrk(0x000000C0) Err#12 ENOMEM
    sbrk(0x00000060) Err#12 ENOMEM
    thread_unlock(0x202C6580, 0x207D59A8, 0x00000008, 0x0000D0B2,
    0x00000000, 0x10091A17, 0x30091A17, 0x00000000) = 0x00000000
    = 0x00000001
    thread_waitlock(0x200C04B0, 0x200C04A8, 0x206CF7F0, 0x200C04B0,
    0x100C08CF, 0x000C08CF, 0x10091A17, 0x00000005) = 0x00000000
    thread_setmystate(0x204A2118, 0x00000000, 0x00000000, 0x00000000,
    0x204A236C, 0x204A2374, 0xF013E010, 0x5876D003) = 0x00000000
    thread_tsleep(0x00000000, 0x200C04B0, 0x00000000, 0x00000008,
    0xF00D627C, 0x200C04A8, 0x204A2528, 0x204A2530) = 0x00000001
    thread_twakeup(0x0002F641, 0x10000000, 0xF00D6348, 0xF013C420,
    0x000000EC, 0x00000004, 0x00000018, 0x00000004) = 0x00000000
    sbrk(0x000000D0) = 0x10000000
    Err#12 ENOMEM
    sbrk(0x00000090) Err#12 ENOMEM
    sbrk(0x000000C0) = 0x00000000
    Err#12 ENOMEM
    sbrk(0x00000060) = 0x00000000
    Err#12 ENOMEM
    sbrk(0x000000D0) Err#12 ENOMEM
    sbrk(0x00000090) Err#12 ENOMEM
    sbrk(0x000000C0) Err#12 ENOMEM
    sbrk(0x00000060) Err#12 ENOMEM

    Do i need to increase swap space or thread stack size?


  7. Re: core dump doesn't show back trace


    Paul Pluzhnikov wrote:
    > "pankajtakawale" writes:
    >
    > > I can not use narrow down method u have suggested, as i can not
    > > reproduce problem on my machine. Im facing problem on client side.

    >
    > In that case, you should definitely test your app with specialized
    > tools I mentioned before.
    >
    > > One more observation is :
    > > Process is showing very abrupt behaviour.

    >
    > What the hell does that mean?
    >
    >>Process is not dying at particular point.
    > > Last time I faced similar problem on windows 2003.
    > > On 2003, process was showing abrupt behaviour only in case of heavy
    > > memory requirement. But after building application using .Net compiler
    > > (VC7) instead of VC6, problem *disappeared*.

    >
    > You are programming by coincidence:
    > http://www.awprofessional.com/articl...le.asp?p=31538
    > Don't do that. The problem most likely didn't disappear, it simply
    > moved someplace else, where its effect remains hidden.
    >
    > > Now on AIX 5.1,

    >
    > And you are posting this to HP-UX group because?
    >>>I could not find a good group for aix

    > > memory requirement of process is huge.

    >
    > Do you mean that the app is supposed to take (say) 10MB but instead takes 100?
    >>No. Memory requirement of process depends upon configuration. And client has very heavy configuration.

    > Did you observe that "unexplained" behaviour on your development machine?
    >
    > If so, did you investigate it? It is quite likley related to the
    > problem your client is facing.
    > >I haven't observed behaviour on my box, even under heavy configurations. Still Im planning to test app for more heavy configuration or more mem reqmt
    > > Do i need to
    > > build application with other compiler? Im usin xlc compiler.

    >
    > "Randomly" changing compiler or compilation options in hope that
    > the problem will just disappear is a sure sign of programming
    > by coincidence.
    >
    > > Because same application is running fine on windows .

    >
    > That means nothing: it is quite often the case that many serious
    > bugs are discovered while porting from one platform to another.
    >
    > Besides, you *know* that there is a problem on Windows as well,
    > when the app is compiled with VC6. Did you check your program with
    > e.g. BoundsChecker on Windows? If not, why not?
    > > I will try BoundsChecker. Probably I have logical answer why VC7 compiled application ran fine. for same configuration, memory reqmt for VC7 built app is less than that of VC6. Here is explanation http://www.codecomments.com/archive3...-4-434111.html

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



  8. Re: core dump doesn't show back trace

    "pankajtakawale" writes:

    > Here is the snippet of truss output

    ....
    > sbrk(0x00000060) Err#12 ENOMEM
    >
    > Do i need to increase swap space or thread stack size?


    Increasing swap might help, but I would not expect it.
    You are running out of *heap* space. Check your limits, e.g. 'ulimit
    -a' in *sh or 'limit' in *csh.

    Also, if your program legitimately needs more then 256M of heap,
    read this:
    http://publib16.boulder.ibm.com/pser...rg_support.htm

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

  9. Re: core dump doesn't show back trace

    "pankajtakawale" writes:

    >> What the hell does that mean?
    >>
    >>>Process is not dying at particular point.


    Why did you prefix your replies with >>> ???
    Please don't do that. Rest of the message reformatted.

    >> And you are posting this to HP-UX group because?

    > I could not find a good group for aix


    comp.unix.aix

    > Probably I have logical answer why VC7
    > compiled application ran fine. for same configuration, memory reqmt
    > for VC7 built app is less than that of VC6. Here is explanation
    > http://www.codecomments.com/archive3...-4-434111.html


    That explanation only explains anything if you are relying on
    incorrect VC7 behaviour.

    If you are, you shouldn't. If you aren't, that thread doesn't
    explain anything.

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

  10. Re: core dump doesn't show back trace


    Paul Pluzhnikov wrote:
    > "pankajtakawale" writes:
    >
    > > Here is the snippet of truss output

    > ...
    > > sbrk(0x00000060) Err#12 ENOMEM
    > >
    > > Do i need to increase swap space or thread stack size?

    >
    > Increasing swap might help, but I would not expect it.
    > You are running out of *heap* space. Check your limits, e.g. 'ulimit
    > -a' in *sh or 'limit' in *csh.
    >


    Yes process was running out of heap space. In my local environment I
    decreased soft limit of data segment and ran app. truss showed 'sbrk
    faild with ENOMEM'. Now Im planning to run app in very heavy
    configuration such that 'unlimited data segment' too will be
    insufficient. And on same configuration I will make app large addr
    space model by setting env variable LDR_CNTRL (app shud run in large
    addr space model). And will update thread with results.
    Thanks for your valuable help Paul.


    > Also, if your program legitimately needs more then 256M of heap,
    > read this:
    > http://publib16.boulder.ibm.com/pser...rg_support.htm
    >
    > Cheers,
    > --
    > In order to understand recursion you must first understand recursion.
    > Remove /-nsp/ for email.



  11. Re: core dump doesn't show back trace

    Making process large addres space solved the problem
    If I take precaution of keeping swap space large enough, are there any
    adverse effect to other memory intensive processes such as database
    server? OR any disadavantageous of it?


+ Reply to Thread