Closed Bug 711036 Opened 13 years ago Closed 4 years ago

Investigate and document execution of debug builds on Windows

Categories

(Developer Documentation Graveyard :: Mozilla Platform, defect, P5)

defect

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: whimboo, Unassigned)

References

Details

I have downloaded debug builds for aurora and beta and both cannot be executed on my Windows XP machine. http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-aurora-win32-debug/1323932174/ From within MSYS: $ debug/firefox.exe bash: debug/firefox.exe: Bad file number
So MDN states that you will need the CRT DLLs from at least Microsoft Visual Studio 2005 to run debug builds. Does it mean that there is no way to run debug builds without having to pay? https://developer.mozilla.org/en/Running_Windows_Debug_Builds Would be great if we could enhance the MDN page if that's the case, or/and add download links to VS.
Keywords: dev-doc-needed
Ted or Kyle will know definitively.
You have to install VS 2005 (or install whatever copy of the Windows SDK includes the corresponding compiler binaries), but we're prohibited by the EULA from redistributing the CRT to you.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → INVALID
Kyle, can you please tell us the exact files which are necessary to get this working? With that information I could try to find out the SDK's we would have to install to make it work - I still hope that VS 2005 is not necessary for it.
Neil likes to tell me this is easy, so maybe he can answer comment 4.
The Vista SDK includes the VC2005 compiler and debug libraries.
If you can verify this and update the docs, that'd be great. Sorry that it sucks, but we're limited by Microsoft's licensing.
Sure, will try to verify. Moving bug over to MDN content.
Status: RESOLVED → REOPENED
Component: Release Engineering → Documentation Requests
Product: mozilla.org → Mozilla Developer Network
QA Contact: release → doc-request
Resolution: INVALID → ---
Version: other → MDN
Ok, I'm a step further. I can now start debug builds but I get dozen of the following errors: SymGetModuleInfo64: T### ERROR: What does it mean and is there a lib I still have not installed?
Does the browser still start? I suspect those are just assertions firing and trying to produce a stacktrace, but failing because you don't actually have the symbol files.
Yes, the builds can be started now. Before I want to document anything I kinda would like to see everything solved. Does it mean it is unimportant for this specific topic? Would I have to use windbg with symbols setup instead to see those stacks instead of the errors?
Getting useful stacks from assertions when running packaged debug builds is a pain. The way we solve it on tinderbox is by piping the output through a script that points at the Breakpad symbols, and fixing it up using those: http://mxr.mozilla.org/mozilla-central/source/tools/rb/fix_stack_using_bpsyms.py
So there are different SDK's available. Which one we should refer to for running debug builds? Windows 7 SDK http://www.microsoft.com/download/en/confirmation.aspx?id=3138
Send to early. Once again... Microsoft Windows SDK for Windows 7 and .NET Framework 3.5 SP1: http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=3138 Windows SDK for Windows Server 2008 and .NET Framework 3.5: http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=11310 Microsoft® Windows® Software Development Kit Update for Windows Vista™: http://www.microsoft.com/download/en/details.aspx?id=23719 So what's the right one here?
Status: REOPENED → NEW
Neil answered the question on IRC. So only the Windows Vista SDK contains the VC2005 compiler and the debug CRT. Given the above investigation those are the necessary minimal steps: 1. Download the web install of the Windows Vista SDK from http://www.microsoft.com/download/en/details.aspx?id=23719 2. Execute the setup.exe and only install the Visual C++ compilers (minimum requirement) Sheppy, can you update the MDN page please?
MDN is totally unstable today and always times out for me when trying to save the content. So nothing I can do for the time being. As reference, does this sound ok? Or do we have to do some more tweaks? If you run the windows debug builds you will often get "This application has failed to start because the application configuration is incorrect..." This is because the debug builds need the msvc80 crt debug dlls. You can see this by looking in at firefox.exe with http://www.dependencywalker.com/. To get these DLLs you only have to install the Visual C++ compilers from the <Windows Vista SDK>. No other packages are necessary.
Keywords: dev-doc-needed
Summary: Tinderbox debug builds on Windows cannot be started → Investigate and document execution of debug builds on Windows
Sheppy, can you please get back to us or update the page when you think it's ok? Thanks.
(In reply to Henrik Skupin (:whimboo) from comment #9) > Ok, I'm a step further. I can now start debug builds but I get dozen of the > following errors: > > SymGetModuleInfo64: T### ERROR: > > What does it mean and is there a lib I still have not installed? I get that error too, all the time. The browser also seems to be pretty much unusably slow. Not sure if that's related.
(In reply to Henrik Skupin from comment #9) > Ok, I'm a step further. I can now start debug builds but I get dozen of the > following errors: > > SymGetModuleInfo64: T### ERROR: > > What does it mean and is there a lib I still have not installed? Maybe you don't have a new enough version of DbgHelp.dll? I'm not sure which version comes with the Vista SDK and you probably have to specifically install the Debugging Tools component to install it.
Since the bug I filed has been made a duplicate of this bug, I'm posting what I put for expected results here for easy reference. Firefox should have named the "specified module" in the debug output. Generally in builds the user should be notified and given the opportunity to remove the directive to load a nonexistent "specified module". - What's the significance of the 64? This is a 32-bit build.
(In reply to Robert Claypool from comment #21) > What's the significance of the 64? This is a 32-bit build. SymGetModuleInfo64 is the name of the function that returned an error. It has the "64" suffix because it can be used in both 32-bit and 64-bit builds. > Firefox should have named the "specified module" in the debug output. > Generally in builds the user should be notified and given the opportunity to > remove the directive to load a nonexistent "specified module". Error 126 has been returned by SymGetModuleInfo64. Firefox does not know which module SymGetModuleInfo64 failed to load. (I don't even know under what conditions SymGetModuleInfo64 can return error 126.)
http://msdn.microsoft.com/en-us/library/windows/desktop/ms681336(v=vs.85).aspx says SymGetModuleInfo64 returns a BOOL, and essentially is paired with a SymInitialize function, which is apparently the funtion that consumed the path to the module that SymGetModuleInfo64 failed to load.
Latest builds now use VC10 instead of VC8, so for 32-bit builds you can just install VC10Express. Alternatively, install the Windows 7.1 SDK compilers.
Thanks Neil.
Version: MDN → unspecified
Component: Documentation Requests → Documentation
I can reproduce ### ERROR: SymGetModuleInfo64: in the following debug build in Windows7 x64. http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2012-09-24-mozilla-beta-debug/firefox-16.0.en-US.debug-win32.installer.exe
Is it normal to run so slowly the debug builds on Windows ?
Yes, debug builds are expected to be significantly slower than normal release builds.
Component: Documentation → General
Product: Mozilla Developer Network → Developer Documentation
For what it's worth, if someone can update the docs now, the site is stable. :)
Component: General → Mozilla Platform
Whiteboard: u=mozdev p=0
OS: Windows XP → All
Hardware: x86 → All
Whiteboard: u=mozdev p=0 → u=mozdev p=0 c=Platform
Severity: major → normal
Priority: -- → P5
Whiteboard: u=mozdev p=0 c=Platform
MDN Web Docs' bug reporting has now moved to GitHub. From now on, please file content bugs at https://github.com/mdn/sprints/issues/ and platform bugs at https://github.com/mdn/kuma/issues/.
Status: NEW → RESOLVED
Closed: 13 years ago4 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.