-
Notifications
You must be signed in to change notification settings - Fork 1.3k
Publish debug file (PDB) of binding.node #1337
Conversation
This is a little step to properly troubleshoot #1283 and other low-level Windows issues. Publishing PDB files is a recommended practice and we should do it as well. A test build https://github.com/saper/node-sass/releases/tag/v3.4.2_debug should have all PDB files attached shortly. For testing please use Unfortunately, Visual Studio is unable to perform so-called "reproducible builds" so one has to use regenerated "binding.node" files for debugging, because they have to match exactly the "binding.pdb" files. @am11 would love your feedback - I hope those files do load in Visual Studio :) You can attach source files by using Probably the PDB file needs to be renamed back to |
👍 The PDB files will definitely be useful to debug issue on Windows XP, as the remote debugging tools for XP are discontinued since VS2012. So getting the PDB file and using Dr. Watson: https://support.microsoft.com/en-us/kb/308538 will help us diagnosing binding issues on XP using WinDbg. I tried configuring Dr. Watson, but Event Viewer was not capturing dumps for crashes, so I had to fallback to rudimentary change-recompileOnWindows7-scpToWindowsXP-test-and-repeat approach. :) Might be even possible to install VS2010 on XP SP3 and use these PDBs to debug, even though VS2010 cannot compile the C99/C++11 code, it can understand PDB format. To do that, the program needs to throw an assertion exception (which we can probably get by compiling binding in Debug configuration -- passing |
I'll have a look at XP later. Can you try if those binding files and PDB files can be used to step through the code on modern Windows? Just check out sources into s:\node_modules\node-sass, put bindings and pdb into vendor and try to debug using local VS. Are you getting source files from S: drive displayed? |
I have now published https://github.com/saper/node-sass/releases/tag/v3.4.2_vs2013 and https://github.com/saper/node-sass/releases/tag/v3.4.2_vs2015 - same node-sass code (with modified libsass for VS2013 compatibility) compiled respectively with VS2013 and VS2015. |
What was the resolution here, is this going ahead? |
This is ready to merge. I have generated PDB files and they work. |
Please rebase and ship this @saper |
To ensure proper debugging of problems of Windows, publish PDB debug file along with the binary. In order to keep paths to the source files clean apply the technique described by John Robbins in "PDB Files: what every developer must know" http://www.wintellect.com/devcenter/jrobbins/pdb-files-what-every-developer-must-know and build node-sass in the "S:\node_modules\node-sass" During debugging, source files can be referenced via the virtual "S:" drive. This allows users and developers to assign S: drive to the project root ("node_modules") and access source files without having to redefine source paths. Artifact names are generated in a nice, Lisp-styled functional PowerShell hidden in a YAML folded scalar! Add node 5 to the PR testing build.
Use /RELEASE option of LINK.EXE
No need to wrap the section in a conditional
Fix the output of Maps with falsey keys and/or values
To ensure proper debugging of problems of Windows,
publish PDB debug file along with the binary.
In order to keep paths to the source files clean apply
the technique described by John Robbins in
"PDB Files: what every developer must know"
http://www.wintellect.com/devcenter/jrobbins/pdb-files-what-every-developer-must-know
and build node-sass in the "S:\node_modules\node-sass"
During debugging, source files can be referenced
via the virtual "S:" drive.
This allows users and developers to assign S: drive to the project
root ("node_modules") and access source files without having to redefine
source paths.
Artifact names are generated in a nice, Lisp-styled functional PowerShell
hidden in a YAML folded scalar!
Add node 5 to the PR testing build.