Closed Bug 490408 Opened 15 years ago Closed 15 years ago
Win2k3 trunk check failures: MSVCR80
There is a dialog message saying: TestFactory.exe - Unable To Locate Component "This application has failed to start because MSVCR80.dll was not found. Re-installing the application may fix this problem" Then another dialog that's pretty much the same: xpcshell.exe - Unable To Locate Component "This application has failed to start because MSVCR80.dll was not found. Re-installing the application may fix this problem"
Is this actually on a Win2000? Is it a regression?
(In reply to comment #1) > Is this actually on a Win2000? I expect so as that's what the box says it is. > Is it a regression? Yes. Tinderboxes weren't failing, now they are. Ted: this started with a clobber, so I expect this could be more fallout from bug 487396. What I don't understand is that our check boxes build with jemalloc, but we're getting a problem with xpcshell - as if its still expecting the msvcr80.dll?
This could just be another case where we need to port the patch of course.
(In reply to comment #1) > Is this actually on a Win2000? Apologies, missed a character when creating the bug. It's Win2k3 > Is it a regression? Looks like it might have been hiding by the dep builds and was uncovered when these builders ended up clobbering.
Summary: Win2k trunk check failures: MSVCR80.dll missing → Win2k3 trunk check failures: MSVCR80.dll missing
My patch for bug 489975 hasn't fixed this. I've got one other idea - can we try removing --enable-jemalloc from the mozconfig, at least temporarily? Firefox builds don't have --enable-jemalloc, so my suspicion is that cpp unit tests are broken if you have --enable-jemalloc.
Assignee: nobody → gozer
Not a bad idea, disabling jemalloc to see: comparing with ssh://hg.mozilla.org/build/buildbot-configs searching for changes changeset: 1129:57795301ff95 tag: tip user: Philippe M. Chiasson <email@example.com> date: Mon May 04 21:58:48 2009 -0400 summary: Bug 490408. See if disabling jemalloc will unbreak unittest. r=me These kind of differences make me uneasy some, as it means the codebase you unittest isn't the codebase you end up shipping.
Win2k3 comm-1.9.1 check just failed, but I expect that's because we switched from with --enable-jemalloc to without, without also doing a clobber. I've now clobbered it so hopefully this will go green soon. (In reply to comment #6) > Not a bad idea, disabling jemalloc to see: Given trunk is now green, I'm assuming this has worked. > These kind of differences make me uneasy some, as it means the codebase you > unittest isn't the codebase you end up shipping. Ditto, I've therefore raised bug 491449 as I expect this is a core issue. I think we should keep this open until we get a fix for that, to remind us to put --enable-jemalloc back in.
Whiteboard: [keep open until --enable-jemalloc is on check boxes again, when bug 491449 is fixed]
Latest update: We're not linking ldap correctly, so it still wants msvcr80.dll. I'm going to cover this in bug 491488.
Depends on: 491488
Now that the main issue should be fixed I've backed out the previous removal of --enable-jemalloc: http://hg.mozilla.org/build/buildbot-configs/rev/ce6ad32c848a I'll clobber the builds and set off new ones in a mo.
We've now got both branch & trunk check builds green again (with jemalloc on) so this is now fixed.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.