417640 - Configure: sh crashes on Dell laptops with latest Windows Updates, MozillaBuild1.2, VC7/8

Status: RESOLVED INVALID

(Firefox Build System :: MozillaBuild, task)

Description

[Alex Vincent [:WeirdAl]]

We've seen this on two separate Dell laptops, the first of which is brand-new, and the second could successfully build Mozilla only last week.  Neither machine can build Mozilla code now, and we're seeing evidence of sh crashing early.

"Dumping stack trace to sh.exe.stackdump"

Both machines are Dell Latitude D830 2GHz, 2GB RAM.

We suspect some combination of the latest Windows Update patches (over the past month) and MozillaBuild 1.2 leads to this untenable situation.

Comment 1

[Alex Vincent [:WeirdAl]]

Hint:  http://www.nabble.com/Re%3A--SPAM--Re%3A--sh.exe.stackdump-p8281348.html

Some program from Logitech (lvprcsrv.exe) seems to be the cause.

Comment 2

[[e-mail] (:bhearsum)]

I bet this has something to do with the fact that we rebase the MSYS DLLs. I don't have an immediate fix for you...have you tried running it after killing lvprcsrv.exe?

Comment 3

[David Humphrey (:humph)]

From the mingw FAQ (http://www.mingw.org/MinGWiki/index.php/FAQ):

Why does make often crash creating a sh.exe.stackdump file when I try to compile my source code?
If you experience random crashes with make as well as with the msysinfo command (i.e., repeating the command often allows to compile the source code successfully), the issue might be caused by the Logitech QuickCam software. Here is provided a solution to this issue:

    * type the command services.msc from a command prompt (you will need administrator privileges to do this), then find the "Logitech Process Monitor" service, and change the "Startup type" from "Auto" to "Manual". Do the same with the "LVSrvLauncher" service.
    * type the command regedit from the command prompt (you will need administrator privileges to do this), then find the key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run. Among the other REG_SZ keys, there should be three of them related to the Logitech QuickCam, namely: "LogitechCommunicationsManager", "LogitechQuickCamRibbon", "LVCOMSX". Make a backup of the registry, then remove them.
    * reboot your PC

In this way the Logitech QuickCam daemon won't be available anymore. Nonetheless, the camera will keep working just ok with 3rd party software (e.g., Skype). If you want a less drastic solution, just kill the lvprcsrv.exe process whenever you want to use MSYS by typing at the command prompt: pskill -t lvprcsrv.exe (you will need PsTools and administrator privileges to do this). However, as soon as you will plug in the USB cable of your Logitech QuickCam, the daemon will be restarted, while with the first procedure it won't.

Comment 4

[Alex Vincent [:WeirdAl]]

(In reply to comment #2)
>have you tried running it after killing lvprcsrv.exe?

Yes, and that works.

Comment 5

[(not currently active) Ted Mielczarek]

Even if we can find the root cause here, I'm not sure there's much we can do on our end.  Maybe rebase the DLLs to a different location?  You can experiment with this (the rebase tool is part of Visual Studio, I think?) by running rebase commands similar to these:

http://lxr.mozilla.org/mozilla/source/tools/build-environment/win32/packageit-msys.sh#65

You can try changing the value of "-b 60000000" to a different address.  You could also load lvprcsrv.exe in Dependency Walker or something else to see if it has address range conflicts.

Comment 6

[Calvin Liu]

Removing lvprcsrv.exe solved the problem. Thanks!

Comment 7

[Jon Baumgartner]

I'm having this problem on a Latitude D630 when trying to build Thunderbird trunk, but I do not have the Logitech software installed (so, no lvprcsrv.exe for me to remove.) I'm running MozillaBuild 1.3.

I can't find anywhere where the DLLs are being rebased. Is there anything that can be done?

Comment 8

[(not currently active) Ted Mielczarek]

We can't fix this for real. It would just turn into rebase whack-a-mole. Unless MSYS figures out a way to fix the underlying problem in their system, there isn't anything we can do except try to band-aid over the problem when we hit it. The current setup works for the vast majority of people, so others will just have to find workarounds. Sorry. :-( (See also bug 465711)

Comment 9

[Bruno Calvignac]

In the MinGW FAQ (http://www.mingw.org/MinGWiki/index.php/FAQ),
a compatibily problem with a logitech driver is solved by removing a
key with regedit in
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run.
I look here and see a key from GoogleDesktop (I already stopped it and
restarted my computer).

Then I uninstalled GoogleDesktop, I restarted and it works.

Comment 10

[(not currently active) Ted Mielczarek]

Yeah, see bug 465711.

Comment 11

[Michael Kraft [:morac]]

I have a Dell laptop and I'm also getting a crash in sh.exe during the configuration step when it tries to determine the host system type.  It happens every single time.  I don't have a lvprcsrv.exe processing running or the file installed anywhere.

I do have Google Desktop installed, but I stopped it and it still crashes.  Any ideas?

Comment 12

[Jon Baumgartner]

(In reply to comment #11)
> I do have Google Desktop installed, but I stopped it and it still crashes.  Any
> ideas?

I had to actually uninstall GDS. Stopping it was not enough.

Comment 13

[Michael Kraft [:morac]]

I didn't feel like uninstalling Google Desktop, but I found thatreplacing the existing msys-1.0.dll that came with Moz-Build 1.3 with the one available at http://sourceforge.net/project/showfiles.php?group_id=2435&package_id=24963&release_id=46827 stops the crashes from occurring. 

They both have the same version number, but the later has a build date of 2009-01-29 00:39 while the former has one of 2007-01-12 12:05.

So at least for me a newer version (or at least a more recent compiled version) of msys-1.0.dll fixed the crashing problem.


I still can't compile as it says I'm missing mawk and cl (which is true), but I'm assuming that's some kind of configuration issue.