User Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; InfoPath.3)
Steps to reproduce:
1. Download firefox-10.0.5esr.source.tar.bz2 from ftp://ftp.mozilla.org/pub/mozilla.org/firefox/releases/10.0.5esr/source/ and extract the archive.
While in debugging, double-clic a callstack line that references Firefox code obtained in step 1; in the dialog, pont to the apprpriate file in the directory created in step 1.
Very likely you will get a message similar to this
Source file: ...\Downloads\Mozilla\FireFox\firefox-10.0.5esr.source\mozilla-esr10\layout\base\nsDocumentViewer.cpp
Module: C:\Program Files\Mozilla Firefox\xul.dll
Process: [0x15B0] firefox.exe
The source file is different from when the module was built. Would you like the debugger to use it anyway?
If you choose to use the file, in my experience it is always pertinebt to the binary. Probably this is related to to the way the code is published in the cross-platform environment something like altering line separators, removing/modifying whitespace.
It could even be that Visual Studio does something on the fly prior to verifying the file.
Files should open without the message quoted above. In case This is not related to Mozilla, or the effort cannot be justified, I'd add the information related to this problem to https://developer.mozilla.org/en/Debugging_Mozilla_on_Windows_FAQ .
Forgotten to mention to mark step 2 and to mention that Visul Studio nedds to point to Mozilla symbol server.
This should start in Releng, IMO.
I don't understand what this issue is, or what control we have over it.
Could you tell me what revision Visual Studio thinks the binaries should be ? How does it figure out that the source does not match ?
We deliberately don't have the exact same code in the source tarball as builds the installers, but it should only be differing by
* updating to the tip of the relbranch to get the change to .hgtags to record FIREFOX_10_0_5esr_RELEASE
* creating configure from configure.in
Is this just Visual Studio complaining that the timestamps are different or something?
You shouldn't need to download the source at all, we have source information in our symbols:
I use Visual Studio 2008, but I doubt other version of VS do it differently.
According to http://social.msdn.microsoft.com/forums/en-US/vcgeneral/thread/fbe7d7ee-11aa-4cb9-9055-f95cf5168453/, VS uses some kind of a checksum for source files in .pdb files. Timestamp is not included accordind to this page. Ted Mielczarek [:ted] is not right that there is no need to download source. Symbol server allows to download a binary (.dll, .exe, .ocx, etc) and a .pdb file, but the source, if needs to be referenced, needs to be dowloaded separately.
I did not try other windows debuggers, since in most cases VS is much more convenient, but I'd guess that they would also bring similar complains.
As I mentioned in the origial statement, if this cannot be fixed or the effort is not justifyable, but it is certain, that there is no code discrepancy, IMO https://developer.mozilla.org/en/Debugging_Mozilla_on_Windows_FAQ needs to be updated so that people who reference Mozilla source would not be confused.
Did you read the link I posted in comment 5? Microsoft's debuggers support embedding information about how to retrieve the matching source, and we use that in our PDB files. I have used this successfully many times.
Created attachment 632491 [details]
VS2010 Finf Source Dialog
Find Source: nsthread.cpp
Files of &type:
Dear Ted Mielczarek [:ted],
Considering the level of certainty in your message, and also considering that I normally use not the latest VS, I decided to give a chance to assumption that you know something I do not. Also, to rule-out the possibility of environmental issue, I did it on my home computer. I used VS2010, at the moment the latest officially released version of VS. Alas, no majic with loading the code transparently for me did not happen. Details:
Once I’ve got FF 10.0.5esr stopped at breakpoint and clicked on a Mozilla-related call stack line, ive got the flowing dialog (this is a text capture, I’m going to attach the image):
Find Source: nsthread.cpp
Files of &type:
Now if I have source, and for me the earlier mentioned FTP site is the only way to get the source, I can point to the location of the file, and VS will not ask about locations of other files built together with this one, but on almost every one of them it will show a dialog similar to the one I presented earlier.
If I would have the file at the location where it was built, I would not get the dialog I am presenting today, but if VS does not like the file, I would still get the dialog from my original message.
BTW, and maybe this makes a difference, the page talks about nightly builds and looks like requires CVS.exe to be already available, whereas it does not explain how to get CVS. Or possibley it is not pertinent to released builds, like 10.0.5 esr.
CVS is no longer relevant, it's all hg now and hopefully you have MozillaBuild installed to provide that (otherwise installed separately and on your PATH).
Could you just confirm that 'Enable source server support' is ticked as described in
How I can install HG or whatever is needed?
You don't need to install Mercurial. The files are indexed to be downloaded via HTTP directly from hg.mozilla.org.
I think this now works for me, files are referenced from locations similar to s:\symbolsCache\src\releases\mozilla-esr10\raw-file\5713c92407dd\xpcom\threads\nsThread.cpp. Probably https://developer.mozilla.org/en/Debugging_Mozilla_on_Windows_FAQ should have a reference to https://developer.mozilla.org/en/Using_the_Mozilla_source_server, so that others would not need to follow my path. With ESR program I'd guess more outsiders might need to reference Mozilla code. I can try to make a debut on Mozilla site and email to you when I am done.
I've made an MDN doc update I've promised in the comment 15.