- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Debug application without source code
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
тАО06-30-2008 09:04 AM
тАО06-30-2008 09:04 AM
How do we keep debugging info, INCLUDING able to look at the source code itself (that is, go to that line number and see actual code) in our case? This is needed so that we can remotely support our customers' system when it crashes, and we can instruct them to do debugging step-by-step.
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-30-2008 09:38 AM
тАО06-30-2008 09:38 AM
SolutionAs for what you can do, you can perform a remote SET SOURCE (assuming DECnet is available between the target system and the source pool) and gain access to your debugging in the target environment. But this gets ugly. This also does not benefit from compiler optimizations.
You could compile and link with debugging (though with the debugging disabled during image activation), and then drop the source code onto the system if/when needed. This does not benefit from the compiler optimizations.
Here, I would embed debugging mechanisms into the target application (such as capturing and logging failures in your signal handler, possibly with a self-throttling restart), would embed logging capabilities, would set up to acquire a process dump, and would also maintain the requisite source listings and map files so that you can field support calls in your environment and can debug the code in sutu. The listings (with machine code) and maps allow you to go from the raw binary process dump back to the source file.
Here is some related reading material on this area:
http://64.223.189.234/node/861
http://64.223.189.234/node/800
http://64.223.189.234/node/848
http://64.223.189.234/node/654
The other extreme is to ship full source code, and toss the whole problem over onto the target system. But you probably don't want to do that.
If you are seriously considering this, I might suggest you actually try it. Work with somebody with a skill level of your target customers here, and walk that person through a debugging session.
Most software houses here use the compiler listings and linker maps for this purpose. And integrated debugging.
Stephen Hoffman
HoffmanLabs LLC
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-30-2008 10:48 AM
тАО06-30-2008 10:48 AM
Re: Debug application without source code
thank you for your reply and suggestions.
The deal is, in the past, we used to ship source code together with application to our customers based in Asia. Because they require almost zero-level downtime tolerance, they have a bunch of OpenVMS and Fortran programmers who will assist us in debugging on target environment whenever application crashes. We give instructions over phone. So, the source code is important so that they can read the offending source line to us almost immediately.
However, at the same time, we want to protect and preserve the proprietary rights of the application/software we develop.
Hope this explains the approach. We are open to any other approaches you can suggest.
Thank you.
Jenwae
ITS
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-30-2008 11:51 AM
тАО06-30-2008 11:51 AM
Re: Debug application without source code
There's no magic elixir here, and there's no way available within OpenVMS to embed the source code into an executable.
Obfuscating the source code has most definitely been tried by many folks, and hasn't been found particularly effective. Or you can ship an encrypted archive. And once decrypted, there's no protection against replication. Which means this is a one-shot source code protection scheme. Which quickly reaches the "why bother" stage.
You can run this in-house (with built-in debugging assists in your code and source access), or you set up a DECnet path to allow remote access into your source code servers from the client boxes, or you run with the sources available in the client environment.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-30-2008 01:56 PM
тАО06-30-2008 01:56 PM
Re: Debug application without source code
Look carefully at all the available debugging options. You can separate the debug information from your image using /DSF. You can also use process dumps, so if there's a problem, the customer can send you the dump, which you can analyze on your system (which has DSF and sources).
You may also be able to move the sources to the client system when/if required, perform your debugging, then scrub them away afterwards.
See also the SET IMAGE command to turn debugging on or off.
At an architectural level, you could use one or more logical names to enable and control application tracing and logging. Build yourself a shareable image with calls to log events or state changes. It can control ir and where messages are written.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-01-2008 04:03 AM
тАО07-01-2008 04:03 AM
Re: Debug application without source code
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-01-2008 05:52 AM
тАО07-01-2008 05:52 AM
Re: Debug application without source code
http://h71000.www7.hp.com/doc/83final/6048/6048pro_021.html#startsubcommand_121 in /encrypt.
Not very safe but a beginning.
Wim
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-01-2008 08:02 AM
тАО07-01-2008 08:02 AM
Re: Debug application without source code
Hi Hoff,
thanks for the clarification. Looks like there is no effective way to do what is required.
Hi John,
Yes, the DSF provides the symbols on a file. I believe the same can be done by using /DEBUG which will store symbols with image itself. Sending the DUMP is one option considered, but because our intention is to resolve the problem at the target environment as soon as possible over the phone, this limits its effectiveness.
Hi Kari,
from what I understand, I will still require the source to be delivered. We never know which program section the system will crash real-time in the future.
Hi Wim,
that's an idea too, again, like you said, not very safe. Once decrypted, customers have full access to source. At the moment, we do not have remote control of the target system, something we are thinking to do in the future.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-01-2008 02:13 PM
тАО07-01-2008 02:13 PM
Re: Debug application without source code
Sure, it's possible.
It gets really, really ugly. Really quickly.
And any code that's exposed is gone.
Plus you leave a very bad taste lingering in your customer base.
The other obvious approaches here are to crash less (yep, my stranglehold grip on the obvious), and to automate the receipt and processing of known fixes, to automate detection of crash-prone code, and to respond to downtime within the customer's window.
(There are ways to fully automate crash processing. That goal is at the core of the CLUE CRASH stuff, for instance.)
To eliminate the need to distribute the source code in all but the most extreme cases.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-02-2008 06:29 AM
тАО07-02-2008 06:29 AM
Re: Debug application without source code
This is a similar in scope to attempting to limit what a privileged process can do, for example granting one a "single" privilege in the "ALL" class and thinking that the process will be limited to what is suggested by the privilege name.
If you can't do the debugging needed using the process dump facility, then you really need to get remote access to the system. You may be able to remotely mount a disk at your site using an encrypted connection, but that is not going to be transparent. It would give you the least exposure, as the disk would only be available while the link was up. It would be a very low performance "disk", but for debugging purposes, it would probably be acceptable, and it would also make it a bit harder for the customer to copy the data (at least in a way that was not detectable).
But as Hoff also said, the best solution is to write robust code that doesn't need to be debugged at the customer's location.
Good Luck,
Jon