SEO

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?

"pankajtakawale" <pankaj.takawale@gmail.com> 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.

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

> "pankajtakawale" <pankaj.takawale@gmail.com> 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.

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 .

"pankajtakawale" <pankaj.takawale@gmail.com> 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.

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?

Paul Pluzhnikov wrote:
> "pankajtakawale" <pankaj.takawale@gmail.com> 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.

"pankajtakawale" <pankaj.takawale@gmail.com> 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.

"pankajtakawale" <pankaj.takawale@gmail.com> 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.

Paul Pluzhnikov wrote:
> "pankajtakawale" <pankaj.takawale@gmail.com> 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.