core debug disabled.

[david_252]

Team:

We are unable to get any debug info from a Particular Xapplication core files. This GUI executable was compiled with '-g' compiler option to enable us to trace back from the core files this Xappln. However, it seems somehow these executable were stripped of the debug information when we installed on the production box (Nclass 11.0). Because of this, we have not been able to analyze the core files. We have looked at the executable we had shipped in the development server (Nclass 11.0) and they have the debug info. We were wondering in something was done to the executable before they were installed on the production servers such that the debug info is lost. Alternatively, is there some other setting on these servers that does not give the debug info in the core? The debug info is critical for us as it helps us analyze the core file to determine the exact line of code where the Xapplication executable dumps and we are sure that the same code was installed in production. Please let me know what would be the possible causes that I may have happened or things I have to check. Please advice.


Thanks & Regards,
David

[david_252]

Sir,

Thank you. Can you explain it more clearly to me. That would be very helpful.

Thanks
David.

[James R. Ferguson]

Hi David:

If your executable was relinked this information could have been striped ('ld -s'). Alternately, 'strip' (see the man pages) could have striped the information.

Regards!

...JRF...

[david_252]

Sir,

Ok. I understand. You say that they may have relinked it OR striped it. If so what would be the solution. Can we find out whether they have done it by looking into that executable? Please advice.

Thanks
David.

[James R. Ferguson · Accepted solution]

Hi David:

Do a 'file' on your two executables. For example:

# file a.out
a.out: PA-RISC1.1 shared executable dynamically linked -not stripped

# strip a.out
# file a.out
a.out: PA-RISC1.1 shared executable dynamically linked

Regards!

...JRF...

[James R. Ferguson]

Hi (again) David:

An aside; perchance does your first response at 15:45 actually apply to my response at 15:47 (?). I have reason to believe that it does, and therefore it constitutes more evidence of poor inter-server time synchronization. Thanks.

Regards!

...JRF...

[david_252]

Sir:

That is correct. There is a problem. Thanks a lot.

Regards
David.

[david_252]

Sir,

One last question. I did find that in the development environment when i do a file appln. it is not stripped but in the production it is stripped. Is there any systemwide setting that are changing the binary? Just a wild thought.

Thanks
David.

[Rick Beldin]

There aren't any system wide settings that would strip a binary. What I have seen in some build environments is the generation of a debug binary at the same time as the production binary. The scripts that collect all the necessary binaries to make a product then only collect the production bits for installation. You might want to check that something in the process of creating the production install package is not stipping the binary. This was the case in some products that I worked on.

There are techniques that can be used with stripped binaries. Sometimes folks who are *real* good at debugging can use system maps (made a link time) to figure out offsets. In other cases, a debug binary is squirreled away for safe-keeping and the production one is stripped. When you get a failure, you use the debug binary to do your analysis. Tricky, but I've seen it done.


If you know that the bits on the dev site are not stripped, then why not just move them over by hand to the production site?