Bug 603085 - windows sdk requires .pdb files in order to debug qpid issues.
windows sdk requires .pdb files in order to debug qpid issues.
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise MRG
Classification: Red Hat
Component: qpid-cpp (Show other bugs)
beta
All Windows
low Severity medium
: 1.3
: ---
Assigned To: Andrew Stitcher
MRG Quality Engineering
:
Depends On:
Blocks: 603204
  Show dependency treegraph
 
Reported: 2010-06-11 09:52 EDT by Timothy St. Clair
Modified: 2012-12-11 14:23 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-12-11 14:23:37 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Change build scripts to build Debug/Release with PDB debug files (8.73 KB, application/octet-stream)
2010-06-21 17:09 EDT, Chuck Rolke
no flags Details
patch to add the PDB files to the build (8.25 KB, patch)
2010-06-22 16:05 EDT, Chuck Rolke
no flags Details | Diff
A build script that installs the Messaging DOTNET binding (5.58 KB, application/octet-stream)
2010-06-25 08:11 EDT, Chuck Rolke
no flags Details

  None (edit)
Description Timothy St. Clair 2010-06-11 09:52:36 EDT
Description of problem:
There have been numerous occasions where a customer will need the .pdb files in the sdk in order to diagnose an issue to determine if it is their issue or qpid.   

Version-Release number of selected component (if applicable):
qpid-cpp-0.7.946106-x.zip

How reproducible:
100%

Steps to Reproduce:
1. Try to single step into qpid. 

Actual results:
debug symbols not found

Expected results:
the ability to walk in.
Comment 1 Timothy St. Clair 2010-06-11 10:02:46 EDT
In grid our output is from the RelWithDebInfo build configuration, which will produce a .pdb file to allow users to debug.  

Below is an excerpt-example cmake macro used in grid, which will install the .pdb file based on user specified build configuration.  

# the following will install the .pdb files, some hackery needs to occur because of build configuration is not known till runtime.
if ( WINDOWS )		
	INSTALL(CODE "FILE(INSTALL DESTINATION \"\${CMAKE_INSTALL_PREFIX}/bin\" TYPE EXECUTABLE FILES \"${CMAKE_CURRENT_BINARY_DIR}/\${CMAKE_INSTALL_CONFIG_NAME}/${_CNDR_TARGET}.pdb\")")
endif( WINDOWS )
Comment 2 Andrew Stitcher 2010-06-11 10:15:16 EDT
Is the bug here that the debug libraries do not have debug info embedded in the libraries. Or is this a feature request that we should include .pdb files for the release libraries?

Also I don't understand why this is marked a mrg blocker.
Comment 3 Timothy St. Clair 2010-06-11 10:28:30 EDT
In order for you to accurately single step, or view frames during exception situations, you need the .pdb files whether release or debug.  

It's marked as a blocker because this is pretty important.  E.g. I recently rcv'd 

First-chance exception at 0x7c812afb in
condor_startd.exe: Microsoft C++ exception: qpid::TransportFailure at
memory location 0x066cf444

without proper frame information this is quite difficult to diagnose for free running qpid threads.
Comment 4 Andrew Stitcher 2010-06-11 10:36:16 EDT
Sorry you've not answered the question: are you saying that debug information is not available in the debug libraries?

.pdb files are not necessary if the debug information is embedded in the library are you saying that no debug info is embedded in the debug libraries?
Comment 5 Timothy St. Clair 2010-06-11 11:00:06 EDT
IIRC, no.

http://msdn.microsoft.com/en-us/library/xe4t6fc1(VS.80).aspx

"It is not possible to create an .exe or .dll that contains debug information.
Debug information is always placed in a .pdb file."
Comment 6 Chuck Rolke 2010-06-21 16:43:34 EDT
After a crash course in cmake I have some observations and a plan.

1. In the current scheme we never ship .PDB files, not even for the debug build. 

2. There already exists a 'configuration' called RelWithDebInfo that is a release build with debug info. This is nice but is not exactly the same as the real release build. The exceptions are InlineFunctionExpansion and LinkIncremental.

The plan is to put yet another switch in the process to select a "regular" build and a "debug" build. This switch is to the bld-winsdk.ps1 script. 
 * In regular mode the script produces a Debug and a Release build with no PDB files, exactly like today's build.
 * In debug mode the script produces a Debug and a RelWithDebInfo build and both variants get PDB files.

My thinking is:
 * I don't want to mess with the Release build compile/link switches and try to discover any new wrinkles introduced by the build process. The real Release build ships unchanged.
 * I want to leverage the RelWithDebInfo build as it is built-in to cmake and to use it is easy. Built-ins are good.
 * Folks who want to debug a release build aren't going to care that the build is one-off the real release build.
 * The debug builds with 18 PDB files of 25 Mbytes each are big.

I can use some advice/opinions on how we'll package two zip files instead of just one.
Comment 7 Chuck Rolke 2010-06-21 17:09:40 EDT
Created attachment 425752 [details]
Change build scripts to build Debug/Release with PDB debug files

Implements suggested method of build debug/release versions of code and shipping PDB files in the .zip kit.
Comment 9 Chuck Rolke 2010-06-22 10:52:30 EDT
Another proposal:

1. Select build for Debug and RelWithDebInfo. Both of these builds create PDB files.

2. Package the regular dlls and the debug dlls into the /bin directory as normal.

3. Zip the Debug PDBs and place the DebugPDB zip file into /bin. Same for the RelWithDebInfo PDBs and zip file.

4. Ship only one zip file for the works.

The file sizes today are:

File             Uncompressed Compressed
---------------  ------------ ----------
Grand zip file   53 Mb        29 Mb
Release PDBs     54 Mb        10 Mb
Debug PDBs       61 Mb        11 Mb

A normal customer unzips the original package and gets the /bin directory with the DLLs and two zipped PDB archives. If he needs the PDBs then he can unzip the inner PDB archives.

The package to download goes from 7Mb before PDB additions to 29Mb after. I don't know where I got the 500Mb number from at today's meeting but I was wrong.
Comment 10 Chuck Rolke 2010-06-22 16:05:22 EDT
Created attachment 426077 [details]
patch to add the PDB files to the build

This patch:
1. sets the RelWithDebInfo compile and link switches equal to the Release switches (except for the debug part).
2. Packages the PDB files into two .zip files in the /bin directory.
Comment 11 Chuck Rolke 2010-06-23 09:59:56 EDT
Patch for upstream project propagated to Jira https://issues.apache.org/jira/browse/QPID-2689

Also, along the way I found a CMake debug gem in:

get_cmake_property (res VARIABLES)
foreach (v ${res})
  message (STATUS "${v} = ${${v}}")
endforeach (v)

Seeing the actual variables cut down on the guessing/frustration.
Comment 12 Chuck Rolke 2010-06-24 18:47:33 EDT
Updated QPID-2689 with improved changes.
Comment 13 Chuck Rolke 2010-06-25 08:11:59 EDT
Created attachment 426865 [details]
A build script that installs the Messaging DOTNET binding

Adds commands to compile and package the cpp/bindings/qpid/dotnet DLLs. 
1. This is not integrated with cmake as cmake doesn't do C# projects. 
2. Only does debug variant. C# dll does not specify lib.dll and libd.dll using same rules as C++ so packaging the PDB is not clean.
3. There was no opinion on what bld-winsdk.cp1 is or does on the wider mailing list. I think we can jam this in for our purposes and not upset anyone.
Comment 14 Andrew Stitcher 2010-06-28 05:16:22 EDT
I suggest you open a new BZ for adding the dotnet binding to the Windows SDK: It's not really connected to adding pdb files to the sdk.
Comment 15 Andrew Stitcher 2010-06-28 16:56:05 EDT
changes based on the first patfch were checked into the upstream trunk as of r958703.

Also checked into the mrg_1.3 release branch

Note You need to log in before you can comment on or make changes to this bug.