Closed Bug 506702 Opened 15 years ago Closed 15 years ago

need to set PDBSTR_PATH for win32 builds

Categories

(Release Engineering :: General, defect, P2)

x86
Windows Server 2003
defect

Tracking

(status1.9.2 beta1-fixed, status1.9.1 .4-fixed)

RESOLVED FIXED
Tracking Status
status1.9.2 --- beta1-fixed
status1.9.1 --- .4-fixed

People

(Reporter: ted, Assigned: nthomas)

References

Details

Attachments

(2 files)

Source server support for Hg builds requires PDBSTR_PATH to be set in the environment, pointing to pdbstr.exe. This is set here for Tinderbox builds on 1.9.0: http://mxr.mozilla.org/mozilla/source/tools/tinderbox-configs/firefox/win32/tinder-config.pl#14
Assignee: nobody → bhearsum
Priority: -- → P2
I gave this a quick go in staging and it seemed to work OK - the .txt file that sits with the symbols had a bunch of: pdbstr -r/w -p:PdbFileName -i:StreamFileName -s:StreamName in it. Strangely though, the Firefox 3.0 ones don't have anything like this. I tried to test this out but I have no idea how to make windbg work.
Attachment #392703 - Flags: review?(ted.mielczarek)
Comment on attachment 392703 [details] [diff] [review] add PDBSTR_PATH to production, staging, try builders This looks reasonable, but having those pdbstr command lines wind up in the -symbols.txt is definitely not right. We should figure out what's happening there before landing this.
Attachment #392703 - Flags: review?(ted.mielczarek) → review+
Is there anything in the .txt or logs, or any other place that we can verify it is working before checking this in?
Oops, I told you on IRC that I put info in the bug, but it was the wrong bug! Check bug 440001 comment 19 for a commandline that you can use to check the info contained in the PDB files.
oops, wrong bug
Probably not getting to this soon.
Assignee: bhearsum → nobody
Component: Release Engineering → Release Engineering: Future
Priority: P2 → P3
Figured out the root cause, bug 520141.
I hear this is slowing down finding out more about our top-crashes, we should jump on this ASAP! Ideally we'd get this in for 3.5.4, even.
blocking1.9.1: --- → ?
ted, bhearsum: whats left to do here? Set this env.variable and install pdbstr.exe on all the slaves? Is this going ok in staging?
This is nominated for blocking the already late 1.9.1 branch, but it's assigned to nobody and in the component "RelEng: Future" neither of which is very confidence building.
I'm not really sure what needs to be done here. I believe that my patch is needed, but it sounds like we need bug 520141 before anything will work.
Yeah, we need bug 520141 on trunk, 1.9.2, 1.9.1, and then we need Ben's patch.
Depends on: 520141
So I talked to peterv about this and it's not *critical* to get this in for 3.5.4, but we should still get this fixed ASAP, and if we can do it for 3.5.4 w/o delaying it further, I think we should at least try...
Ben: I just landed bug 520141 on m-c. When you get a chance, could you land just the m-c portion of this patch? I think landing the whole thing will break branches I haven't landed on, but I want to get a nightly out with both of our patches to verify that it's working right.
blocking1.9.1: ? → ---
Attachment #392703 - Flags: approval1.9.1.4+
Comment on attachment 392703 [details] [diff] [review] add PDBSTR_PATH to production, staging, try builders Approved for 1.9.1.4, a=dveditz for release-drivers This must land today, Oct 5, because we will be doing builds tomorrow morning.
This needs to land on 1.9.2 as well.
Assignee: nobody → nthomas
Component: Release Engineering: Future → Release Engineering
OS: Windows NT → Windows Server 2003
Priority: P3 → P2
pm, pm02 and try reconfigured to pick up 79479c0ab82c.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: