- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - HP-UX
- >
- cc "-g" option fixes SIGSEGV?
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-05-2002 12:50 PM
тАО08-05-2002 12:50 PM
I re-compiled it on the new machine - no joy, still SIGSEGV'd, but the core dump was useless because there were no symbols.
I amended the compile just to use "-g" to get the symbols into the executable. And guess what - the program ran fine.
Any ideas why -g fixed the problem? I can't "debug" the problem now because it won't occur!!
(The original program was written and compiled 3-4 years ago and hasn't been touched since...)
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-05-2002 12:59 PM
тАО08-05-2002 12:59 PM
SolutionThe other likely explanation is that the code is still broken; it's just not broken enough.
Consider this example:
int my_array[100];
my_array[-1] = 100;
my_array[100] = 200;
Now, you might expect either of these bogus assignments to cause a segmentation violation; in many cases, neither of these might because no page boundary was crossed so that the hardware might not detect it.
What you might try is compiling without -g but do not run 'strip' on the code file. This will certainly not give you enough data to zero in on the offending line but a stack trace should still work so that you can at least identify the function.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-05-2002 07:43 PM
тАО08-05-2002 07:43 PM
Re: cc "-g" option fixes SIGSEGV?
I've seen this behavior over and over in poorly written code. As Clay says, -g retains the symbol table, which in turn, results in some of pesky bugs 'being suppressed'.
I'd strongly recommend using Rational's Purify. It can help to zero in on array overflows, uninitialized memory access, freeing unallocated memory, etc.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-05-2002 09:43 PM
тАО08-05-2002 09:43 PM
Re: cc "-g" option fixes SIGSEGV?
Just check for the
maxdsiz
maxdsiz_64bit
maxssiz
maxssiz_64bit
values
Probably the program is exceeding the value of data segment size for a process.
Thanks
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-05-2002 11:08 PM
тАО08-05-2002 11:08 PM
Re: cc "-g" option fixes SIGSEGV?
The most common cause is that when you compile code with debug information, the memory layout of your program is a little different. Now when you have bad memory writes in your code, they can go unnoticed because now, by conincidence, the memory area you write too belongs to your process, and the program does not crash. (However, it alters data it should leave alone, so it is obviously still broken.)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-06-2002 02:22 AM
тАО08-06-2002 02:22 AM
Re: cc "-g" option fixes SIGSEGV?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-06-2002 03:17 AM
тАО08-06-2002 03:17 AM
Re: cc "-g" option fixes SIGSEGV?
I'd already checked all the stack sizes etc. on both machines, both globally and the ulimit on the users concerned. All looked fine. If it was a "size" issue I'd have expected the debug version to fail as well.
I suspected the lack of optimisations and/or the different offsets/code padding (the symbols could well be getting corrupted, but that's not going to stop the program running!)
Just downloading an eval of Rational's Purify stuff. I'll see if that helps - thanks for the pointer.
I did try compiling it on NT (with Visual Studio .NET) because I'm far more au fait with NT development and tools. Unfortunately it gpf's on that when the filehandle for a file gets overwritten for some reason - different problem to that on the Unix system, as on Unix I can get it to process some files, but even the files that work on Unix crash on NT, so I suspect another bug got introduced then.
Anyway, enough rambling.
Thanks again