490408 - Win2k3 trunk check failures: MSVCR80.dll missing

Status: RESOLVED FIXED

(Mozilla Messaging Graveyard :: Release Engineering, defect)

Description

[Philippe M. Chiasson (:gozer)]

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"

Comment 1

[Serge Gautherie (:sgautherie)]

Is this actually on a Win2000?
Is it a regression?

Comment 2

[Mark Banner (:standard8)]

(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?

Comment 3

[Mark Banner (:standard8)]

This could just be another case where we need to port the patch of course.

Comment 4

[Philippe M. Chiasson (:gozer)]

(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.

Comment 5

[Mark Banner (:standard8)]

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.

Comment 6

[Philippe M. Chiasson (: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 <[e-mail]>
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.

Comment 7

[Mark Banner (:standard8)]

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.

Comment 8

[Mark Banner (:standard8)]

Latest update: We're not linking ldap correctly, so it still wants msvcr80.dll. I'm going to cover this in bug 491488.

Comment 9

[Mark Banner (:standard8)]

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.

Comment 10

[Mark Banner (:standard8)]

We've now got both branch & trunk check builds green again (with jemalloc on) so this is now fixed.