MinGW - Minimalist GNU for Windows

I've got the same problem. sh.exe stack dumps whatever I try to build. 
Right now I'm trying to build gnucash and songbird, each according to 
the recommended build method. The stack dumps seem random -- sometimes I 
get a few steps into the build; sometimes it dumps immediately. I am 
never able to complete a build.

I've tried msys 1.0.1, as well as the latest stable version (1.0.10). 
I've also tried the mozilla-build 1.3 msys, as recommended by songbird. 
They all behave the same.

I've never had a logitech camera and have none of the related drivers or 
services that seem to come up most frequently in discussions of this 
problem.

The only thing I've noticed is disabling on-access virus scanning seems 
to slightly reduce the frequency of crashes, but I'm still not able to 
build anything.

Any ideas?

Adam Rosi-Kessel <adam@...> wrote:
> The only thing I've noticed is disabling on-access virus scanning seems
> to slightly reduce the frequency of crashes, but I'm still not able to
> build anything.

Since MSYS shares much code with Cygwin, perhaps some Cygwin-related
advice could help:

1) Please try uninstalling the anti-virus software completely,
sometimes disabling it is not enough.
2) The following page has some other software that is known to cause problems:
     http://cygwin.com/faq/faq.using.html#faq.using.bloda
3) Try downloading rebase.exe from
     http://www.tishler.net/jason/software/rebase/
   Then close all MSYS programs and run from the Command Prompt:
     rebase -b 0x30000000 msys-1.0.dll

Hope this helps,

Cesar

Cesar Strauss wrote, on 11/29/2008 1:04 PM:
> Adam Rosi-Kessel <adam@...> wrote:
>> The only thing I've noticed is disabling on-access virus scanning seems
>> to slightly reduce the frequency of crashes, but I'm still not able to
>> build anything.
> 
> Since MSYS shares much code with Cygwin, perhaps some Cygwin-related
> advice could help:
> 
> 1) Please try uninstalling the anti-virus software completely,
> sometimes disabling it is not enough.
> 2) The following page has some other software that is known to cause problems:
>      http://cygwin.com/faq/faq.using.html#faq.using.bloda
> 3) Try downloading rebase.exe from
>      http://www.tishler.net/jason/software/rebase/
>    Then close all MSYS programs and run from the Command Prompt:
>      rebase -b 0x30000000 msys-1.0.dll

Thanks for the suggestions. I tried both and still no luck. I also tried 
killing/stopping every process/service that seemed potentially invasive 
(i.e., everything that was not essential to running the OS) and still 
get the same result. What's particularly surprising to me is how random 
the crashes seem to be -- I can run the same make command ten times, and 
each time get a different crash. It's also surprising that there is no 
useful debug information coming out -- the stack dump itself doesn't 
seem enlightening.

The only other possible cause I might mention is pointsec, which is the 
tool for the encrypted hard drive. I don't have any way to disable it 
and still run my laptop. I wouldn't think that should interfere -- I've 
never heard of any other application having any issues with pointsec -- 
but if it is the cause I can't think of a good way to test it.

Any other suggestions?

Adam

On 2008-11-30 01:53Z, Adam Rosi-Kessel wrote:
> 
> What's particularly surprising to me is how random 
> the crashes seem to be -- I can run the same make command ten times, and 
> each time get a different crash. It's also surprising that there is no 
> useful debug information coming out -- the stack dump itself doesn't 
> seem enlightening.

When it stops, try typing the same 'make' command again. If it goes
further, then crashes elsewhere, it might be hardware:
  http://www.bitwizard.nl/sig11/

Greg Chicares wrote, on 11/30/2008 2:50 PM:
>> What's particularly surprising to me is how random 
>> the crashes seem to be -- I can run the same make command ten times, and 
>> each time get a different crash. It's also surprising that there is no 
>> useful debug information coming out -- the stack dump itself doesn't 
>> seem enlightening.
> When it stops, try typing the same 'make' command again. If it goes
> further, then crashes elsewhere, it might be hardware:
>   http://www.bitwizard.nl/sig11/

Repeatedly executing 'make' does have inconsistent results, but it 
doesn't necessarily go further. Sometimes it crashes immediately, 
sometimes further on. It's not linear. I can run 'make' ten times in a 
row and crash at ten different points, some earlier, some later, in the 
make process.

I'm pretty sure it's not hardware--I was having this identical problem 
on the predecessor machine to this one. They are both Lenovo Laptops but 
different models (x60 vs. x61) with no common parts.

Adam Rosi-Kessel wrote:
> Cesar Strauss wrote, on 11/29/2008 1:04 PM:
>> Adam Rosi-Kessel wrote:
>>> The only thing I've noticed is disabling on-access virus scanning seems
>>> to slightly reduce the frequency of crashes, but I'm still not able to
>>> build anything.
>>
>> Since MSYS shares much code with Cygwin, perhaps some Cygwin-related
>> advice could help:
>>
>> 1) Please try uninstalling the anti-virus software completely,
>> sometimes disabling it is not enough.
>> 2) The following page has some other software that is known to cause problems:
>>      http://cygwin.com/faq/faq.using.html#faq.using.bloda
>> 3) Try downloading rebase.exe from
>>      http://www.tishler.net/jason/software/rebase/
>>    Then close all MSYS programs and run from the Command Prompt:
>>      rebase -b 0x30000000 msys-1.0.dll
>
> Thanks for the suggestions. I tried both and still no luck.

Could you try installing Cygwin and see if it crashes as well?

Cesar

Cesar Strauss wrote, on 11/30/2008 4:57 PM:
>>>> The only thing I've noticed is disabling on-access virus scanning seems
>>>> to slightly reduce the frequency of crashes, but I'm still not able to
>>>> build anything.
>>> 1) Please try uninstalling the anti-virus software completely,
>>> sometimes disabling it is not enough.
>>> 2) The following page has some other software that is known to cause problems:
>>>      http://cygwin.com/faq/faq.using.html#faq.using.bloda
>> Thanks for the suggestions. I tried both and still no luck.
> Could you try installing Cygwin and see if it crashes as well?

I have been using cygwin as well. Nothing has ever crashed in Cygwin, 
but I can't build either of the packages (gnucash or songbird) from 
Cygwin, presumably because of idiosyncracies in the build processes.

I've tried troubleshooting the build process in cygwin but always get 
stuck somewhere along the way. For example, the gnucash makefile 
downloads msysdtk; the perl version in msysdtk fails mysteriously (with 
an error 53). Trying to build these applications under cygwin seems to 
be something of a rabbit-hole, unfortunately.

Adam Rosi-Kessel wrote:
> Cesar Strauss wrote, on 11/30/2008 4:57 PM:
>>>>> The only thing I've noticed is disabling on-access virus scanning seems
>>>>> to slightly reduce the frequency of crashes, but I'm still not able to
>>>>> build anything.
>>>> 1) Please try uninstalling the anti-virus software completely,
>>>> sometimes disabling it is not enough.
>>>> 2) The following page has some other software that is known to cause problems:
>>>>      http://cygwin.com/faq/faq.using.html#faq.using.bloda
>>> Thanks for the suggestions. I tried both and still no luck.
>> Could you try installing Cygwin and see if it crashes as well?
>
> I have been using cygwin as well. Nothing has ever crashed in Cygwin,

Interesting. If Cygwin is not affected, it might mean there is a fix
already available somewhere in the Cygwin sources. In the past, a
workaround for a Vista-related crash was successfully solved by code
derived from Cygwin.

> but I can't build either of the packages (gnucash or songbird) from
> Cygwin, presumably because of idiosyncracies in the build processes.
>

In this case, the build system (Cygwin) differs from the final host
system (MinGW), so you are actually cross-compiling. I see there are
instructions for cross-compiling in the build documentation of
gnucash. If all else fails, perhaps you could try this way.

Regards,
Cesar

Cesar Strauss wrote, on 11/30/2008 8:00 PM:
>>>> Thanks for the suggestions. I tried both and still no luck.
>>> Could you try installing Cygwin and see if it crashes as well?
>> I have been using cygwin as well. Nothing has ever crashed in Cygwin,
> Interesting. If Cygwin is not affected, it might mean there is a fix
> already available somewhere in the Cygwin sources. In the past, a
> workaround for a Vista-related crash was successfully solved by code
> derived from Cygwin.
>> but I can't build either of the packages (gnucash or songbird) from
>> Cygwin, presumably because of idiosyncracies in the build processes.
> In this case, the build system (Cygwin) differs from the final host
> system (MinGW), so you are actually cross-compiling. I see there are
> instructions for cross-compiling in the build documentation of
> gnucash. If all else fails, perhaps you could try this way.

Unfortunately the cross-compiling directions don't work as written. It 
tries to build MinGW and dies here:

gcc -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Werror -O2 
-fno-exceptions -s -o ar.exe arparse.o arlex.o ar.o not-ran
lib.o arsup.o rename.o binemul.o emul_vanilla.o bucomm.o version.o 
filemode.o  ../bfd/.libs/libbfd.a ../libiberty/libiberty.a
arlex.o:arlex.c:(.text+0x0): multiple definition of `_main'
arparse.o:arparse.c:(.text+0x0): first defined here
ar.o:ar.c:(.text+0xeb0): multiple definition of `_main'
arparse.o:arparse.c:(.text+0x0): first defined here
ar.o:ar.c:(.text+0x25): undefined reference to `_yyparse'
collect2: ld returned 1 exit status

I'll keep plugging away at it, but unfortunately it doesn't look easy.

(Incidentally, I'm not running Vista -- this is an XP SP3 box).

Adam

Adam Rosi-Kessel wrote:
> Cesar Strauss wrote, on 11/30/2008 8:00 PM:
>>> but I can't build either of the packages (gnucash or songbird) from
>>> Cygwin, presumably because of idiosyncracies in the build processes.
>> In this case, the build system (Cygwin) differs from the final host
>> system (MinGW), so you are actually cross-compiling. I see there are
>> instructions for cross-compiling in the build documentation of
>> gnucash. If all else fails, perhaps you could try this way.
>
> Unfortunately the cross-compiling directions don't work as written. It
> tries to build MinGW and dies here:
>

To build a MinGW cross-compiler, please try MinGW's own automated script:

Cross-Hosted MinGW Build Tool
http://sourceforge.net/project/showfiles.php?group_id=2435&package_id=12644

Regards,
Cesar

Cesar Strauss wrote, on 11/30/2008 9:42 PM:
>>> In this case, the build system (Cygwin) differs from the final host
>>> system (MinGW), so you are actually cross-compiling. I see there are
>>> instructions for cross-compiling in the build documentation of
>>> gnucash. If all else fails, perhaps you could try this way.
>> Unfortunately the cross-compiling directions don't work as written. It
>> tries to build MinGW and dies here:
> To build a MinGW cross-compiler, please try MinGW's own automated script:
> 
> Cross-Hosted MinGW Build Tool
> http://sourceforge.net/project/showfiles.php?group_id=2435&package_id=12644

Similar result with MinGW's script:

gcc -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Werror -O2 
-fno-exceptions -s -o ar.exe arparse.o arlex.o ar.o not-ranlib.o arsup.o 
rename.o binemul.o emul_vanilla.o bucomm.o version.o filemode.o 
../bfd/.libs/libbfd.a ../libiberty/libiberty.a
arlex.o:arlex.c:(.text+0x0): multiple definition of `_main'
arparse.o:arparse.c:(.text+0x0): first defined here
ar.o:ar.c:(.text+0xeb0): multiple definition of `_main'
arparse.o:arparse.c:(.text+0x0): first defined here
ar.o:ar.c:(.text+0x25): undefined reference to `_yyparse'
collect2: ld returned 1 exit status
make[4]: *** [ar.exe] Error 1
make[4]: Leaving directory 
`/cygdrive/c/soft/tmp/mingw-3.4.5/binutils-2.17.50-20060716-1-src/build/binutils'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory 
`/cygdrive/c/soft/tmp/mingw-3.4.5/binutils-2.17.50-20060716-1-src/build/binutils'
make[2]: *** [all] Error 2
make[2]: Leaving directory 
`/cygdrive/c/soft/tmp/mingw-3.4.5/binutils-2.17.50-20060716-1-src/build/binutils'
make[1]: *** [all-binutils] Error 2
make[1]: Leaving directory 
`/cygdrive/c/soft/tmp/mingw-3.4.5/binutils-2.17.50-20060716-1-src/build'
make: *** [all] Error 2
/tmp/x86-mingw32-build.sh-0.0-20061107-1/x86-mingw32-build.sh: 
unrecoverable error building binutils

Adam Rosi-Kessel wrote:
> Cesar Strauss wrote, on 11/30/2008 9:42 PM:
>>>> In this case, the build system (Cygwin) differs from the final host
>>>> system (MinGW), so you are actually cross-compiling. I see there are
>>>> instructions for cross-compiling in the build documentation of
>>>> gnucash. If all else fails, perhaps you could try this way.
>>> Unfortunately the cross-compiling directions don't work as written. It
>>> tries to build MinGW and dies here:
>> To build a MinGW cross-compiler, please try MinGW's own automated script:
>>
>> Cross-Hosted MinGW Build Tool
>> http://sourceforge.net/project/showfiles.php?group_id=2435&package_id=12644
>
> Similar result with MinGW's script:
>

What is in you PATH? Try to simplify it to the maximum, to something like:

On Cygwin:
PATH=/usr/bin:/bin:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem

On MSYS:
PATH=/mingw/bin:/bin:/c/WINDOWS/system32:/c/WINDOWS:/c/WINDOWS/System32/Wbem

Also, check for multiple versions of msys-1.0.dll in your PATH.

Cesar

Quoting Adam Rosi-Kessel <adam@...>:

>
> $ msysinfo

Please execute the msysinfo command with an all parameter (msysinfo all).

> msysinfo-1.3: Send this to the MSYS support list:
>
> MSYS 1.0.11(0.46/3/2) 2007-01-12 12:05 i686 unknown; targ=MINGW32
> GNU bash, version 2.04.0(1)-release (i686-pc-msys); ENV=.profile
> GNU Make 3.81.90This program built for i686-pc-msys32; MAKE_MODE=unix
>       0 [main] sh 2880 open_stackdumpfile: Dumping stack trace to
> sh.exe.stackdump
> gcc (GCC) 3.4.4 (cygming special, gdc 0.12, using dmd 0.125); targ=
> GNU ld (GNU Binutils) 2.18.50.20080625
>  2008-06-16 13:44:24.000000000 -0400 /bin/msys-1.0.dll
>  2008-06-16 13:44:24.000000000 -0400 /bin/msys-crypto-0.9.8.dll
>  2008-06-16 13:44:24.000000000 -0400 /bin/msys-minires.dll
>  2008-06-16 13:44:24.000000000 -0400 /bin/msys-ssl-0.9.8.dll
>  2008-06-16 13:44:24.000000000 -0400 /bin/msys-z.dll
>  2008-06-16 13:44:24.000000000 -0400 /bin/msysltdl-3.dll
>       0 [main] sh 1580 open_stackdumpfile: Dumping stack trace to
> sh.exe.stackdump

The contents of this sh.exe.stackdump would be good to have if you can 
grab it.

> 006-12-17 19:56:16.000000000 -0500 /c/cygwin/bin/gcc.exe
> 2008-07-08 18:14:40.000000000 -0400 /c/cygwin/bin/ld.exe

This indicates that Cygwin is in your PATH.  Not good.  Also make sure 
the CYGWIN environment variable is not set.

> HOME=/c/mozilla-build/msys/BOSNT01
> Sysname=MINGW32_NT-5.1  OSTYPE=msys  TERM=msys
> PATH=.:/usr/local/bin:/mingw/bin:/bin:/c/WINDOWS/system32:/c/WIN
> DOWS:/c/WINDOWS/system32/WBEM
> $ ls -tx /c/mozilla-build/msys/home
> sh.exe.stackdump
>

This stackdump is indicating an environment issue.

Earnie

Earnie Boyd wrote, on 12/1/2008 8:05 AM:
>> $ msysinfo
> Please execute the msysinfo command with an all parameter (msysinfo all).

msysinfo all from mozilla-build pasted below; a few redactions are noted 
that shouldn't matter to the issues here (just names of local drives and 
machines):

----SNIP---- [MOZILLA-BUILD]

msysinfo-1.3: Send this to the MSYS support list:

       0 [main] sh 5000 open_stackdumpfile: Dumping stack trace to 
sh.exe.stackdump
MSYS 1.0.11(0.46/3/2) 2007-01-12 12:05 i686 unknown; targ=
       0 [main] sh 2304 open_stackdumpfile: Dumping stack trace to 
sh.exe.stackdump
; ENV=.profile
GNU Make 3.81.90This program built for i686-pc-msys32; MAKE_MODE=unix
       0 [main] sh 5012 open_stackdumpfile: Dumping stack trace to 
sh.exe.stackdump
; targ=MINGW32
/bin/msysinfo: ld: command not found
  2008-06-16 13:44:24.000000000 -0400 /bin/msys-1.0.dll
  2008-06-16 13:44:24.000000000 -0400 /bin/msys-crypto-0.9.8.dll
  2008-06-16 13:44:24.000000000 -0400 /bin/msys-minires.dll
  2008-06-16 13:44:24.000000000 -0400 /bin/msys-ssl-0.9.8.dll
  2008-06-16 13:44:24.000000000 -0400 /bin/msys-z.dll
  2008-06-16 13:44:24.000000000 -0400 /bin/msysltdl-3.dll
2008-06-16 13:44:38.000000000 -0400 /local/bin/make.exe
ls: .exe: No such file or directory
ls: .exe: No such file or directory
HOME=/c/Documents and Settings/avk/[redacted]
Sysname=MINGW32_NT-5.1  OSTYPE=msys  TERM=dumb
PATH=/local/bin:/c/mozilla-build//wget:/c/mozilla-build//7zip:/c
/mozilla-build//blat261/full:/c/mozilla-build//python25:/c/mozil
la-build//svn-win32-1.4.2/bin:/c/mozilla-build//upx203w:/c/mozil
la-build//xemacs/XEmacs-21.4.19/i586-pc-win32:/c/mozilla-build//
info-zip:/c/mozilla-build//nsis-2.22:/c/mozilla-build//nsis-2.33
u:/c/mozilla-build//hg:/c/mozilla-build//python25/Scripts:.:/usr
/local/bin:/mingw/bin:/bin:/c/Program Files/Microsoft SDKs/Windo
ws/v6.0/bin:/c/Program Files/Microsoft Visual Studio 8/Common7/I
DE:/c/Program Files/Microsoft Visual Studio 8/VC/BIN:/c/Program
Files/Microsoft Visual Studio 8/Common7/Tools:/c/Program Files/M
icrosoft Visual Studio 8/SDK/v2.0/bin:/c/WINDOWS/Microsoft.NET/F
ramework/v2.0.50727:/c/Program Files/Microsoft Visual Studio 8/V
C/VCPackages:/c/WINDOWS/System32:/c/WINDOWS:/c/WINDOWS/System32/
Wbem:/c/mozilla-build/moztools/bin
$ ls -tx /c/Documents and Settings/avk/[redacted]
msysinfo.txt		  sh.exe.stackdump  .bash_history
change-svn-wc-format.py*

7cb0b6a3201cf0622a46f2ed21fd601b */bin/msys-1.0.dll
018281d51c8a3f080549e1bbe3291bb8 */bin/msys-crypto-0.9.8.dll
ab14ab3ccb01dcfadc2856f34feab7ca */bin/msys-minires.dll
3662f62813ee59f7bb8e9b55d71190c9 */bin/msys-ssl-0.9.8.dll
9d26a263af4ac168df419d0efd088b48 */bin/msys-z.dll
cc9d47a802aac283052cc17000afbe03 */bin/msysltdl-3.dll
f7800151a358d5ff4eba24a841c2e003 */local/bin/make.exe
md5sum: .exe: No such file or directory
md5sum: .exe: No such file or directory

In /etc/fstab:
cat: /etc/fstab: No such file or directory

In /etc/profile:
   export PATH=".:/usr/local/bin:/mingw/bin:/bin:$PATH"
   export PATH=".:/usr/local/bin:/bin:/mingw/bin:$PATH"
export HOME LOGNAME MSYSTEM HISTFILE
export MAKE_MODE=unix
export PS1='\[\033]0;$MSYSTEM:\w\007

/bin/msys-1.0.dll:%%% MSYS dll major: 1000
/bin/msys-1.0.dll:%%% MSYS dll minor: 11
/bin/msys-1.0.dll:%%% MSYS dll epoch: 19
/bin/msys-1.0.dll:%%% MSYS dll bad signal mask: 19005
/bin/msys-1.0.dll:%%% MSYS dll old termios: 5
/bin/msys-1.0.dll:%%% MSYS dll malloc env: 28
/bin/msys-1.0.dll:%%% MSYS api major: 0
/bin/msys-1.0.dll:%%% MSYS api minor: 46
/bin/msys-1.0.dll:%%% MSYS shared data: 3
/bin/msys-1.0.dll:%%% MSYS dll identifier: msys-1.0
/bin/msys-1.0.dll:%%% MSYS mount registry: 2
/bin/msys-1.0.dll:%%% MSYS cygnus registry name: msys
/bin/msys-1.0.dll:%%% MSYS cygwin registry name: 1.0
/bin/msys-1.0.dll:%%% MSYS program options name: Program Options
/bin/msys-1.0.dll:%%% MSYS cygwin mount registry name: mounts v2
/bin/msys-1.0.dll:%%% MSYS cygdrive flags: cygdrive flags
/bin/msys-1.0.dll:%%% MSYS cygdrive prefix: cygdrive prefix
/bin/msys-1.0.dll:%%% MSYS cygdrive default prefix:
/bin/msys-1.0.dll:%%% MSYS build date: Fri Jan 12 12:05:35 EST 2007
/bin/msys-1.0.dll:%%% MSYS CVS tag: MSYS-1_0_11
/bin/msys-1.0.dll:%%% MSYS shared id: msys-1.0S3

!C:='C:\Documents and Settings\avk'
!EXITCODE=00000001
ALLUSERSPROFILE='C:\Documents and Settings\All Users'
APPDATA='C:\Documents and Settings\avk\Application Data'
BASH=/bin/sh
BASH_VERSINFO=([0]="2" [1]="04" [2]="0" [3]="1" [4]="release"
[5]="i686-pc-msys")
BASH_VERSION='2.04.0(1)-release'
CLASSPATH='.;"C:\WINDOWS\System32\QTJava.zip";C:\Program
Files\Java\jre1.6.0_07\lib\ext\QTJava.zip'
CLIENTNAME=Console
COMMONPROGRAMFILES='C:\Program Files\Common Files'
COMPUTERNAME=[redacted]
COMSPEC='C:\WINDOWS\system32\cmd.exe'
CVS_RSH=ssh
DEVENVDIR='C:\Program Files\Microsoft Visual Studio
8\Common7\IDE'
DIRSTACK=()
EDITOR=xemacs.exe
EUID=500
FP_NO_HOST_CHECK=NO
FRAMEWORKDIR='C:\WINDOWS\Microsoft.NET\Framework'
FRAMEWORKSDKDIR='C:\Program Files\Microsoft Visual Studio
8\SDK\v2.0'
FRAMEWORKVERSION=v2.0.50727
GROUPS=()
HISTFILE='/c/Documents and Settings/avk/[redacted]/.bash_history'
HOME='/c/Documents and Settings/avk/[redacted]'
HOMEDIR=F:
HOMEDRIVE='\\'
HOMEPATH='[redacted]\avk$'
HOMESHARE='\\[redacted]\avk$'
HOSTNAME=[redacted]
HOSTTYPE=i686
IFS=' 	
'
INCLUDE='C:\Program Files\Microsoft
SDKs\Windows\v6.0\\include;\include\atl;\include;C:\Program
Files\Microsoft Visual Studio 8\VC\INCLUDE;'
INPUTRC=/etc/inputrc
LIB='C:\Program Files\Microsoft
SDKs\Windows\v6.0\\lib;C:\Program Files\Microsoft Visual Studio
8\VC\LIB;C:\Program Files\Microsoft Visual Studio
8\SDK\v2.0\lib;;C:\mozilla-build\atlthunk_compat'
LIBPATH='C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727'
LOGNAME=AVK
LOGONSERVER='\\[redacted]'
MACHTYPE=i686-pc-msys
MAKE_MODE=unix
MOZBUILDDIR='C:\mozilla-build\'
MOZILLABUILD='C:\mozilla-build\'
MOZ_MSVCVERSION=8
MOZ_TOOLS='C:\mozilla-build\moztools'
MSVC6KEY='HKLM\SOFTWARE\Microsoft\VisualStudio\6.0\Setup\Microso
ft Visual C++'
MSVC71KEY='HKLM\SOFTWARE\Microsoft\VisualStudio\7.1\Setup\VC'
MSVC8EXPRESSKEY='HKLM\SOFTWARE\Microsoft\VCExpress\8.0\Setup\VC'
MSVC8KEY='HKLM\SOFTWARE\Microsoft\VisualStudio\8.0\Setup\VC'
MSVC9EXPRESSKEY='HKLM\SOFTWARE\Microsoft\VCExpress\9.0\Setup\VC'
MSVC9KEY='HKLM\SOFTWARE\Microsoft\VisualStudio\9.0\Setup\VC'
MSVCROOTKEY='HKLM\SOFTWARE\Microsoft\VisualStudio'
MSYSTEM=MINGW32
NUMBER_OF_PROCESSORS=2
OPTERR=1
OPTIND=1
OS=Windows_NT
OSTYPE=msys
PATH='/local/bin:/c/mozilla-build//wget:/c/mozilla-build//7zip:/
c/mozilla-build//blat261/full:/c/mozilla-build//python25:/c/mozi
lla-build//svn-win32-1.4.2/bin:/c/mozilla-build//upx203w:/c/mozi
lla-build//xemacs/XEmacs-21.4.19/i586-pc-win32:/c/mozilla-build/
/info-zip:/c/mozilla-build//nsis-2.22:/c/mozilla-build//nsis-2.3
3u:/c/mozilla-build//hg:/c/mozilla-build//python25/Scripts:.:/us
r/local/bin:/mingw/bin:/bin:/c/Program Files/Microsoft
SDKs/Windows/v6.0/bin:/c/Program Files/Microsoft Visual Studio
8/Common7/IDE:/c/Program Files/Microsoft Visual Studio
8/VC/BIN:/c/Program Files/Microsoft Visual Studio
8/Common7/Tools:/c/Program Files/Microsoft Visual Studio
8/SDK/v2.0/bin:/c/WINDOWS/Microsoft.NET/Framework/v2.0.50727:/c/
Program Files/Microsoft Visual Studio
8/VC/VCPackages:/c/WINDOWS/System32:/c/WINDOWS:/c/WINDOWS/System
32/Wbem:/c/mozilla-build/moztools/bin'
PATHEXT='.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH'
PIPESTATUS=([0]="0")
PPID=6040
PROCESSOR_ARCHITECTURE=x86
PROCESSOR_IDENTIFIER='x86 Family 6 Model 15 Stepping 11,
GenuineIntel'
PROCESSOR_LEVEL=6
PROCESSOR_REVISION=0f0b
PROFILE='F:\PROFILE'
PROGRAMFILES='C:\Program Files'
PROMPT='$P$G'
PS4='+ '
PWD='/c/Documents and Settings/avk/[redacted]'
QTJAVA='C:\Program Files\Java\jre1.6.0_07\lib\ext\QTJava.zip'
SDK2003SP1KEY='HKLM\SOFTWARE\Microsoft\MicrosoftSDK\InstalledSDK
s\8F9E5EF3-A9A5-491B-A889-C58EFFECE8B3'
SDK2003SP2KEY='HKLM\SOFTWARE\Microsoft\MicrosoftSDK\InstalledSDK
s\D2FF9F89-8AA2-4373-8A31-C838BF4DBBE1'
SDK6KEY='HKLM\SOFTWARE\Microsoft\Microsoft
SDKs\Windows\v6.0\WinSDKBuild'
SDKDIR='C:\Program Files\Microsoft SDKs\Windows\v6.0\'
SDKMINORVER=0
SDKROOTKEY='HKLM\SOFTWARE\Microsoft\MicrosoftSDK\InstalledSDKs'
SDKVER=6
SESSIONNAME=Console
SHELL=/bin/sh
SHELLOPTS=braceexpand:hashall:interactive-comments
SHLVL=2
SYSTEMDRIVE=C:
SYSTEMROOT='C:\WINDOWS'
TEMP=/tmp
TERM=dumb
TMP=/tmp
UID=500
ULTRAMON_LANGDIR='C:\Program Files\UltraMon\Resources\en'
USEPSDKATL=1
USEPSDKIDL=1
USER=AVK
USERDNSDOMAIN= [redacted]
USERDOMAIN= [redacted]
USERNAME=AVK
USERPROFILE='C:\Documents and Settings\avk'
USESDK=1
VC8EXPRESSDIR='C:\program Files\Microsoft Visual Studio 8\VC'
VCINSTALLDIR='C:\Program Files\Microsoft Visual Studio 8\VC'
VIM='C:\program Files\vim'
VS80COMNTOOLS='C:\Program Files\Microsoft Visual Studio
8\Common7\Tools\'
VSINSTALLDIR='C:\Program Files\Microsoft Visual Studio 8'
WINDIR='C:\WINDOWS'
_=echo

$ msysinfo all >msysinfo.txt   will save this to a file

----SNIP----

 > The contents of this sh.exe.stackdump would be good to have if you can
 > grab it.

And here's the latest sh.exe.stackdump from the mozilla-build installation:

----SNIP---- [MOZILLA-BUILD]

MSYS-1.0.11 Build:2007-01-12 12:05
Exception: STATUS_ACCESS_VIOLATION at eip=60164D96
eax=7FFDF000 ebx=00000000 ecx=00000000 edx=0022F5F8 esi=00000000 
edi=0022F58C
ebp=0022F0FC esp=0022F0E4 program=C:\mozilla-build\msys\bin\sh.exe
cs=001B ds=0023 es=0023 fs=003B gs=0000 ss=0023
Stack trace:
Frame     Function  Args
0022F0FC  60164D96  (0022F5F8, 00000001, 00000758, 00000000)
0022F5A8  601272DE  (0022F728, 0022F72C, 0022F730, 0022F5D0)
0022F738  60127AF2  (0A016E30, FFFFFFFF, 0A0166CE, 0040D5FC)
0022F768  0041BDFE  (0A017058, 00000000, 0022F7E8, 004114C5)
0022F7E8  004114D5  (0A016E30, FFFFFFFF, 00000004, 00000000)
0022F848  0040E9C6  (0A016E18, 00000000, FFFFFFFF, 00000004)
0022F8A8  0040F8B8  (0A016F50, 00000000, FFFFFFFF, FFFFFFFF)
0022F8F8  0040FBC4  (0A016F50, 00000000, FFFFFFFF, FFFFFFFF)
0022F958  0040EBE2  (0A016F50, 00000000, FFFFFFFF, FFFFFFFF)
0022F9A8  004499BB  (0A0129A8, 00422DC6, 00000004, 00000000)
0022FA04  0042313C  (0A0129A8, 00000000, 0022FA44, 6012CFC4)
0022FA64  004267D1  (0A012958, 0022FAF8, 00000000, 0022FC80)
0022FC14  00426E27  (0A0169A0, 00000000, 00000000, 0022FC7C)
0022FC84  00428404  (0A016990, 0000001F, 0022FCE4, 004489EA)
0022FCC4  00428741  (0A0168E8, 0000001F, 0022FD54, 00000010)
0022FCE4  00429177  (0A0168E8, 00000000, 0022FD24, 6012CFC4)
End of stack trace (more stack frames may be present)

----SNIP----


And now msysinfo all from my free-standing msys installation:

----SNIP---- [MSYS]

msysinfo-1.3: Send this to the MSYS support list:

MSYS 1.0.10(0.46/3/2) 2004-03-15 07:17 i686 unknown; targ=MINGW32
; ENV=.profile
GNU Make version 3.79.1,Built for i686-pc-msys; MAKE_MODE=unix
; targ=MINGW32
    789320 Tue Mar 16 14:32:49 2004 /bin/msys-1.0.dll
     52064 Thu Jan 02 08:05:27 2003 /bin/msysltdl-3.dll
    135680 Tue Mar 16 14:32:48 2004 /bin/make.exe
HOME=/c/soft/msys/1.0/bin/[redacted]
Sysname=MINGW32_NT-5.1  OSTYPE=msys  TERM=msys
PATH=.:/usr/local/bin:/mingw/bin:/bin:/c/windows/system32:/c/win
dows:/c/windows/system32/wbem
$ ls -tx /c/soft/msys/1.0/bin/[redacted]
sh.exe.stackdump  .bash_history

bbfe534c85236d94683f3461829ef10b */bin/msys-1.0.dll
7c2d7d01f6a96b73aeea7738faaaa9c5 */bin/msysltdl-3.dll
0e7941487ca8156a25b46b0b8f9a8bd9 */bin/make.exe

In /etc/fstab:
c:/mingw /mingw

In /etc/profile:
   export PATH=".:/usr/local/bin:/mingw/bin:/bin:$PATH"
   export PATH=".:/usr/local/bin:/bin:/mingw/bin:$PATH"
export HOME LOGNAME MSYSTEM HISTFILE
export MAKE_MODE=unix
export PS1='\[\033]0;$MSYSTEM:\w\007

/bin/msys-1.0.dll:%%% MSYS dll major: 1000
/bin/msys-1.0.dll:%%% MSYS dll minor: 10
/bin/msys-1.0.dll:%%% MSYS dll epoch: 19
/bin/msys-1.0.dll:%%% MSYS dll bad signal mask: 19005
/bin/msys-1.0.dll:%%% MSYS dll old termios: 5
/bin/msys-1.0.dll:%%% MSYS dll malloc env: 28
/bin/msys-1.0.dll:%%% MSYS api major: 0
/bin/msys-1.0.dll:%%% MSYS api minor: 46
/bin/msys-1.0.dll:%%% MSYS shared data: 3
/bin/msys-1.0.dll:%%% MSYS dll identifier: cygwin1
/bin/msys-1.0.dll:%%% MSYS mount registry: 2
/bin/msys-1.0.dll:%%% MSYS cygnus registry name: msys
/bin/msys-1.0.dll:%%% MSYS cygwin registry name: 1.0
/bin/msys-1.0.dll:%%% MSYS program options name: Program Options
/bin/msys-1.0.dll:%%% MSYS cygwin mount registry name: mounts v2
/bin/msys-1.0.dll:%%% MSYS cygdrive flags: cygdrive flags
/bin/msys-1.0.dll:%%% MSYS cygdrive prefix: cygdrive prefix
/bin/msys-1.0.dll:%%% MSYS cygdrive default prefix:
/bin/msys-1.0.dll:%%% MSYS build date: Mon Mar 15 07:17:24 EST 2004
/bin/msys-1.0.dll:%%% MSYS shared id: cygwin1S3

!C:='C:\soft\msys\1.0\bin'
ALLUSERSPROFILE='C:\Documents and Settings\All Users'
APPDATA='C:\Documents and Settings\avk\Application Data'
BASH=/usr/bin/sh
BASH_VERSINFO=([0]="2" [1]="04" [2]="0" [3]="1" [4]="release"
[5]="i686-pc-msys")
BASH_VERSION='2.04.0(1)-release'
BGCOLOR=LightYellow
CLASSPATH='.;"C:\WINDOWS\System32\QTJava.zip";C:\Program
Files\Java\jre1.6.0_07\lib\ext\QTJava.zip'
CLIENTNAME=Console
COLORFGBG='default;default'
COLORTERM=rxvt
COMMONPROGRAMFILES='C:\Program Files\Common Files'
COMPUTERNAME=[redacted]
COMSPEC='C:\WINDOWS\system32\cmd.exe'
DIRSTACK=()
DISPLAY=:0
EUID=500
FGCOLOR=Navy
FP_NO_HOST_CHECK=NO
GROUPS=()
HISTFILE=/c/soft/msys/1.0/bin/[redacted]/.bash_history
HOME=/c/soft/msys/1.0/bin/[redacted]
HOMEDIR=F:
HOMEDRIVE='\\'
HOMEPATH='[redacted]\avk$'
HOMESHARE='\\[redacted]\avk$'
HOSTNAME=[redacted]
HOSTTYPE=i686
IFS=' 	
'
LOGNAME=AVK
LOGONSERVER='\\[redacted]'
MACHTYPE=i686-pc-msys
MAKE_MODE=unix
MINGW32BGCOLOR=LightYellow
MINGW32FGCOLOR=Navy
MSYSBGCOLOR=White
MSYSFGCOLOR=Black
MSYSTEM=MINGW32
NUMBER_OF_PROCESSORS=2
OPTERR=1
OPTIND=1
OS=Windows_NT
OSTYPE=msys
PATH=.:/usr/local/bin:/mingw/bin:/bin:/c/windows/system32:/c/win
dows:/c/windows/system32/wbem
PATHEXT='.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH'
PIPESTATUS=([0]="0")
PPID=2036
PROCESSOR_ARCHITECTURE=x86
PROCESSOR_IDENTIFIER='x86 Family 6 Model 15 Stepping 11,
GenuineIntel'
PROCESSOR_LEVEL=6
PROCESSOR_REVISION=0f0b
PROFILE='F:\PROFILE'
PROGRAMFILES='C:\Program Files'
PROMPT='$P$G'
PS4='+ '
PWD=/c/soft/msys/1.0/bin/[redacted]
QTJAVA='C:\Program Files\Java\jre1.6.0_07\lib\ext\QTJava.zip'
SESSIONNAME=Console
SHELL=/bin/sh
SHELLOPTS=braceexpand:hashall:interactive-comments
SHLVL=2
SYSTEMDRIVE=C:
SYSTEMROOT='C:\WINDOWS'
TEMP=/tmp
TERM=msys
TMP=/tmp
UID=500
ULTRAMON_LANGDIR='C:\Program Files\UltraMon\Resources\en'
USER=AVK
USERDNSDOMAIN=[redacted]
USERDOMAIN=[redacted]
USERNAME=AVK
USERPROFILE='C:\Documents and Settings\avk'
VC8EXPRESSDIR='C:\program Files\Microsoft Visual Studio 8\VC'
VIM='C:\program Files\vim'
VS80COMNTOOLS='C:\Program Files\Microsoft Visual Studio
8\Common7\Tools\'
WINDIR='C:\WINDOWS'
WINDOWID=167838912
_=echo

$ msysinfo all >msysinfo.txt   will save this to a file

----SNIP----

And here's the stack dump from the msys installation:

----SNIP---- [MSYS]

MSYS-1.0.10 Build:2004-03-15 07:17
Exception: STATUS_ACCESS_VIOLATION at eip=71070C43
eax=7FFDF000 ebx=00000000 ecx=00000000 edx=0022F228 esi=00000000 
edi=0022F048
ebp=0022EBEC esp=0022EBC8 program=C:\msys\1.0\bin\sh.exe
cs=001B ds=0023 es=0023 fs=003B gs=0000 ss=0023
Stack trace:
Frame     Function  Args
0022EBEC  71070C43  (00000000, 0000001C, 00000744, 00000000)
0022F0A8  7102AC7D  (0022F228, 0022F22C, 0022F230, 0022F0D0)
0022F238  7102B532  (0022F2B0, 00000000, 0A0153F8, 71047D94)
0022F268  0041BDFE  (00000000, 00000000, 0022F2B8, 00422E86)
0022F2B8  00422E92  (0A015410, 00000000, 0022F2F8, 71031450)
0022F318  004267D1  (0A015350, 0022F3AC, 00000000, 0022F534)
0022F4C8  00426E27  (0A015340, 00000000, 00000000, 0022F530)
0022F538  00428404  (0A015330, 0000001F, 0022F598, 004489EA)
0022F578  00428741  (0A015278, 0000001F, 0A014D98, 71031450)
0022F598  00429177  (0A015278, 00000000, 0022F5D8, 71031450)
0022F608  004115EE  (0A0151E8, FFFFFFFF, FFFFFFFF, 00000000)
0022F668  0040E9C6  (0A0151D0, 00000000, FFFFFFFF, FFFFFFFF)
0022F6B8  004499BB  (0A014D98, 00422DC6, 00000004, 00000000)
0022F714  0042313C  (0A014D98, 00000001, 0022F754, 71031450)
0022F774  004267D1  (0A014DC0, 0022F808, 00000001, 00000000)
0022F924  00426E27  (0A014B88, 00000001, 00000000, 0022F9BC)
End of stack trace (more stack frames may be present)

----SNIP----

>> 006-12-17 19:56:16.000000000 -0500 /c/cygwin/bin/gcc.exe
>> 2008-07-08 18:14:40.000000000 -0400 /c/cygwin/bin/ld.exe
> This indicates that Cygwin is in your PATH.  Not good.  Also make sure 
> the CYGWIN environment variable is not set.

I have taken cygwin out of my path and environment for both the 
free-standing msys and the mozilla-build msys. Still no luck.

>> HOME=/c/mozilla-build/msys/BOSNT01
>> Sysname=MINGW32_NT-5.1  OSTYPE=msys  TERM=msys
>> PATH=.:/usr/local/bin:/mingw/bin:/bin:/c/WINDOWS/system32:/c/WIN
>> DOWS:/c/WINDOWS/system32/WBEM
>> $ ls -tx /c/mozilla-build/msys/home
>> sh.exe.stackdump
> This stackdump is indicating an environment issue.

Thanks for any further suggestions!

Cesar Strauss wrote, on 12/1/2008 3:08 AM:
> Adam Rosi-Kessel wrote:
>> Cesar Strauss wrote, on 11/30/2008 9:42 PM:
>>>>> In this case, the build system (Cygwin) differs from the final host
>>>>> system (MinGW), so you are actually cross-compiling. I see there are
>>>>> instructions for cross-compiling in the build documentation of
>>>>> gnucash. If all else fails, perhaps you could try this way.
>>>> Unfortunately the cross-compiling directions don't work as written. It
>>>> tries to build MinGW and dies here:
>>> To build a MinGW cross-compiler, please try MinGW's own automated script:
>>>
>>> Cross-Hosted MinGW Build Tool
>>> http://sourceforge.net/project/showfiles.php?group_id=2435&package_id=12644
>> Similar result with MinGW's script:
> What is in you PATH? Try to simplify it to the maximum, to something like:
> 
> On Cygwin:
> PATH=/usr/bin:/bin:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem
> 
> On MSYS:
> PATH=/mingw/bin:/bin:/c/WINDOWS/system32:/c/WINDOWS:/c/WINDOWS/System32/Wbem
> 
> Also, check for multiple versions of msys-1.0.dll in your PATH.

I tried both of these suggestions; same result. Only one msys*dll in the 
PATH; no extra directories in the PATH.

Adam

Quoting Adam Rosi-Kessel <adam@...>:

> Earnie Boyd wrote, on 12/1/2008 8:05 AM:
>>> $ msysinfo
>> Please execute the msysinfo command with an all parameter (msysinfo all).
>
> msysinfo all from mozilla-build pasted below; a few redactions are noted
> that shouldn't matter to the issues here (just names of local drives and
> machines):
>

Spaces in your environment variables such as HOME and PATH are your 
likely source of issue.

> ----SNIP---- [MOZILLA-BUILD]
>
> msysinfo-1.3: Send this to the MSYS support list:
>
--8<--
> HOME=/c/Documents and Settings/avk/[redacted]
> Sysname=MINGW32_NT-5.1  OSTYPE=msys  TERM=dumb
> PATH=/local/bin:/c/mozilla-build//wget:/c/mozilla-build//7zip:/c
> /mozilla-build//blat261/full:/c/mozilla-build//python25:/c/mozil
> la-build//svn-win32-1.4.2/bin:/c/mozilla-build//upx203w:/c/mozil
> la-build//xemacs/XEmacs-21.4.19/i586-pc-win32:/c/mozilla-build//
> info-zip:/c/mozilla-build//nsis-2.22:/c/mozilla-build//nsis-2.33
> u:/c/mozilla-build//hg:/c/mozilla-build//python25/Scripts:.:/usr
> /local/bin:/mingw/bin:/bin:/c/Program Files/Microsoft SDKs/Windo
> ws/v6.0/bin:/c/Program Files/Microsoft Visual Studio 8/Common7/I
> DE:/c/Program Files/Microsoft Visual Studio 8/VC/BIN:/c/Program
> Files/Microsoft Visual Studio 8/Common7/Tools:/c/Program Files/M
> icrosoft Visual Studio 8/SDK/v2.0/bin:/c/WINDOWS/Microsoft.NET/F
> ramework/v2.0.50727:/c/Program Files/Microsoft Visual Studio 8/V
> C/VCPackages:/c/WINDOWS/System32:/c/WINDOWS:/c/WINDOWS/System32/
> Wbem:/c/mozilla-build/moztools/bin
--8<--

Another thing, what is with the double // in the paths of PATH; extra 
work has to be executed because of it.  Not an issue for your problem 
though.

Earnie

Earnie Boyd wrote, on 12/2/2008 7:49 AM:
>>>> $ msysinfo
>>> Please execute the msysinfo command with an all parameter (msysinfo all).
>> msysinfo all from mozilla-build pasted below; a few redactions are noted
>> that shouldn't matter to the issues here (just names of local drives and
>> machines):
> Spaces in your environment variables such as HOME and PATH are your 
> likely source of issue.

So I tried to fix this:

$ env | grep " "
$ set | grep " "
BASH_VERSINFO=([0]="2" [1]="04" [2]="0" [3]="1" [4]="release" 
[5]="i686-pc-msys")
PIPESTATUS=([0]="0" [1]="1")

(I also grepped for tabs, no different).

It doesn't seem possible to unset BASH_VERSINFO, and PIPESTATUS gets 
re-created automatically. Otherwise, I've unset or remove all 
environmental variables containing spaces.

It still crashes:

# make -f songbird.mk
Songbird Build System
svn up /home/trunk/dependencies/vendor/mozbrowser
At revision 10280.
mkdir -p /home/trunk/compiled /home/trunk/compiled/dist
cd /home/trunk/compiled && /home/trunk/configure
       0 [main] sh 3980 open_stackdumpfile: Dumping stack trace to 
sh.exe.stackdump
       0 [main] sh 5092 open_stackdumpfile: Dumping stack trace to 
sh.exe.stackdump
/home/trunk/configure: line 49:  5092 Segmentation fault      (core 
dumped) ( set +x; test -n "`(eval $as_var=C; export $as_var) 2>&1`" )

> Another thing, what is with the double // in the paths of PATH; extra 
> work has to be executed because of it.  Not an issue for your problem 
> though.

I fixed this too -- actually removed everything from my PATH but the 
essentials. Still no luck.

Adam

Quoting Adam Rosi-Kessel <adam@...>:

> Earnie Boyd wrote, on 12/2/2008 7:49 AM:
>>>>> $ msysinfo
>>>> Please execute the msysinfo command with an all parameter (msysinfo all).
>>> msysinfo all from mozilla-build pasted below; a few redactions are noted
>>> that shouldn't matter to the issues here (just names of local drives and
>>> machines):
>> Spaces in your environment variables such as HOME and PATH are your
>> likely source of issue.
>
> So I tried to fix this:
>
> $ env | grep " "
> $ set | grep " "
> BASH_VERSINFO=([0]="2" [1]="04" [2]="0" [3]="1" [4]="release"
> [5]="i686-pc-msys")
> PIPESTATUS=([0]="0" [1]="1")
>
> (I also grepped for tabs, no different).
>
> It doesn't seem possible to unset BASH_VERSINFO, and PIPESTATUS gets
> re-created automatically. Otherwise, I've unset or remove all
> environmental variables containing spaces.
>
> It still crashes:
>
> # make -f songbird.mk
> Songbird Build System
> svn up /home/trunk/dependencies/vendor/mozbrowser
> At revision 10280.
> mkdir -p /home/trunk/compiled /home/trunk/compiled/dist
> cd /home/trunk/compiled && /home/trunk/configure
>       0 [main] sh 3980 open_stackdumpfile: Dumping stack trace to
> sh.exe.stackdump
>       0 [main] sh 5092 open_stackdumpfile: Dumping stack trace to
> sh.exe.stackdump
> /home/trunk/configure: line 49:  5092 Segmentation fault      (core
> dumped) ( set +x; test -n "`(eval $as_var=C; export $as_var) 2>&1`" )
>
>> Another thing, what is with the double // in the paths of PATH; extra
>> work has to be executed because of it.  Not an issue for your problem
>> though.
>
> I fixed this too -- actually removed everything from my PATH but the
> essentials. Still no luck.
>

You did disable the camera software that Cesar pointed you to correct?  
So removing these variables, does ``cd $HOME; pwd -W'' have spaces?

Earnie

Earnie Boyd wrote, on 12/3/2008 10:50 PM:
>>       0 [main] sh 3980 open_stackdumpfile: Dumping stack trace to
>> sh.exe.stackdump
>>       0 [main] sh 5092 open_stackdumpfile: Dumping stack trace to
>> sh.exe.stackdump
>> /home/trunk/configure: line 49:  5092 Segmentation fault      (core
>> dumped) ( set +x; test -n "`(eval $as_var=C; export $as_var) 2>&1`" )
>>> Another thing, what is with the double // in the paths of PATH; extra
>>> work has to be executed because of it.  Not an issue for your problem
>>> though.
>> I fixed this too -- actually removed everything from my PATH but the
>> essentials. Still no luck.
> You did disable the camera software that Cesar pointed you to correct?  

That's right -- I never had that camera software. I searched for every
possible file/registry key/etc. that might relate to it and found no
sign of it. I've never had anything to do with a Logitech camera, on
this computer or the last one I used (which had the same problem).

 > So removing these variables, does ``cd $HOME; pwd -W'' have spaces?

$ cd $HOME ; pwd -W
c:/mozilla-build/msys/home

Adam Rosi-Kessel wrote, on 12/4/2008 9:24 AM:
> Earnie Boyd wrote, on 12/3/2008 10:50 PM:
>>>       0 [main] sh 3980 open_stackdumpfile: Dumping stack trace to
>>> sh.exe.stackdump
>>>       0 [main] sh 5092 open_stackdumpfile: Dumping stack trace to
>>> sh.exe.stackdump
>>> /home/trunk/configure: line 49:  5092 Segmentation fault      (core
>>> dumped) ( set +x; test -n "`(eval $as_var=C; export $as_var) 2>&1`" )

Incidentally, I should mention that just running

set +x; test -n "`(eval $as_var=C; export $as_var) 2>&1`"

at the shell prompt does not cause any problems.

Earnie Boyd wrote:
> Quoting Adam Rosi-Kessel <adam@...>:
> 
>> $ msysinfo
> 
> Please execute the msysinfo command with an all parameter (msysinfo all).
> 

Adam, could you repeat the above command with the latest MSYS 
development version?

Download msysCORE-1.0.11-20080826.tar.gz from :

Technology Preview: MSYS-1.0.11
https://sourceforge.net/project/showfiles.php?group_id=2435&package_id=24963&release_id=46827

Unpack it in a empty directory and run msys.bat.

Also, send the resulting stack dump if any.

Regards,
Cesar

Cesar Strauss wrote, on 12/6/2008 7:07 AM:
>>> $ msysinfo
>> Please execute the msysinfo command with an all parameter (msysinfo all).
> Adam, could you repeat the above command with the latest MSYS 
> development version?
> Download msysCORE-1.0.11-20080826.tar.gz from :
> Technology Preview: MSYS-1.0.11
> https://sourceforge.net/project/showfiles.php?group_id=2435&package_id=24963&release_id=46827
> Unpack it in a empty directory and run msys.bat.

No luck, same result. Note that the stackdumps when running msysinfo 
occur at different times in successive runs.

msysinfo-1.3: Send this to the MSYS support list:

MSYS 1.0.11(0.46/3/2) 2008-08-25 23:40 i686 unknown; targ=MINGW32
GNU bash, version 3.1.0(1)-release (i686-pc-msys); ENV=.profile
GNU Make 3.81This program built for i686-pc-msys; MAKE_MODE=unix
/bin/msysinfo: line 12: gcc: command not found
; targ=MINGW32
/bin/msysinfo: line 13: ld: command not found
2008-08-25 20:22:40.000000000 -0400 /bin/msys-1.0.dll
2008-08-25 20:22:40.000000000 -0400 /bin/msys-bz2-1.dll
2008-08-25 20:22:39.000000000 -0400 /bin/make.exe
       0 [main] sh 4688 open_stackdumpfile: Dumping stack trace to 
sh.exe.stackdump
       0 [main] sh 4324 open_stackdumpfile: Dumping stack trace to 
sh.exe.stackdump
HOME=/c/0/Downloads/msysCORE-1.0.11-20080826.tar/msysCORE-1.0.11-20080826/BOSNT01
Sysname=MINGW32_NT-5.1  OSTYPE=msys  TERM=msys
PATH=.:/usr/local/bin:/mingw/bin:/bin:/c/WINDOWS/system32:/c/WIN
DOWS:/c/WINDOWS/system32/WBEM
$ ls -tx 
/c/0/Downloads/msysCORE-1.0.11-20080826.tar/msysCORE-1.0.11-20080826/BOSNT01
sh.exe.stackdump  .bash_history  .subversion/  .inputrc

5387dd240f24207c647df9b023a75030 */bin/msys-1.0.dll
d919908ae36c4673a920d29c359603ba */bin/msys-bz2-1.dll
51988e39bcc4c5120248bfb7077e3a6f */bin/make.exe
md5sum: .exe: No such file or directory
md5sum: .exe: No such file or directory

In /etc/fstab:
cat: /etc/fstab: No such file or directory

In /etc/profile:
   export PATH=".:/usr/local/bin:/mingw/bin:/bin:$PATH"
   export PATH=".:/usr/local/bin:/bin:/mingw/bin:$PATH"
export HOME LOGNAME MSYSTEM HISTFILE
export MAKE_MODE=unix
export PS1='\[\033]0;$MSYSTEM:\w\007

/bin/msys-1.0.dll:%%% MSYS dll major: 1000
/bin/msys-1.0.dll:%%% MSYS dll minor: 11
/bin/msys-1.0.dll:%%% MSYS dll epoch: 19
/bin/msys-1.0.dll:%%% MSYS dll bad signal mask: 19005
/bin/msys-1.0.dll:%%% MSYS dll old termios: 5
/bin/msys-1.0.dll:%%% MSYS dll malloc env: 28
/bin/msys-1.0.dll:%%% MSYS api major: 0
/bin/msys-1.0.dll:%%% MSYS api minor: 46
/bin/msys-1.0.dll:%%% MSYS shared data: 3
/bin/msys-1.0.dll:%%% MSYS dll identifier: msys-1.0
/bin/msys-1.0.dll:%%% MSYS mount registry: 2
/bin/msys-1.0.dll:%%% MSYS cygnus registry name: msys
/bin/msys-1.0.dll:%%% MSYS cygwin registry name: 1.0
/bin/msys-1.0.dll:%%% MSYS program options name: Program Options
/bin/msys-1.0.dll:%%% MSYS cygwin mount registry name: mounts v2
/bin/msys-1.0.dll:%%% MSYS cygdrive flags: cygdrive flags
/bin/msys-1.0.dll:%%% MSYS cygdrive prefix: cygdrive prefix
/bin/msys-1.0.dll:%%% MSYS cygdrive default prefix:
/bin/msys-1.0.dll:%%% MSYS build date: Mon Aug 25 23:40:29 GMT 2008
/bin/msys-1.0.dll:%%% MSYS shared id: msys-1.0S3

!C:='C:\0\Downloads\msysCORE-1.0.11-20080826.tar\msysCORE-1.0.11
-20080826'
!F:='F:\'
!M:='M:\'
BASH=/bin/sh
BASH_ARGC=([0]="1")
BASH_ARGV=([0]="all")
BASH_LINENO=([0]="0")
BASH_SOURCE=([0]="/bin/msysinfo")
BASH_VERSINFO=([0]="3" [1]="1" [2]="0" [3]="1" [4]="release"
[5]="i686-pc-msys")
BASH_VERSION='3.1.0(1)-release'
BGCOLOR=LightYellow
COLORFGBG='default;default'
COLORTERM=rxvt-xpm
COMSPEC='C:\WINDOWS\system32\cmd.exe'
DIRSTACK=()
DISPLAY=:0
EUID=500
FGCOLOR=Navy
FP_NO_HOST_CHECK=NO
GROUPS=()
HISTFILE=/c/0/Downloads/msysCORE-1.0.11-20080826.tar/msysCORE-1.
0.11-20080826/BOSNT01/.bash_history
HOME=/c/0/Downloads/msysCORE-1.0.11-20080826.tar/msysCORE-1.0.11
-20080826/BOSNT01
HOSTNAME=BOSL10803
HOSTTYPE=i686
IFS=' 	
'
MACHTYPE=i686-pc-msys
MAKE_MODE=unix
MINGW32BGCOLOR=LightYellow
MINGW32FGCOLOR=Navy
MSYSBGCOLOR=White
MSYSCON=rxvt.exe
MSYSFGCOLOR=Black
MSYSTEM=MINGW32
NUMBER_OF_PROCESSORS=2
OPTERR=1
OPTIND=1
OS=Windows_NT
OSTYPE=msys
PATH=.:/usr/local/bin:/mingw/bin:/bin:/c/WINDOWS/system32:/c/WIN
DOWS:/c/WINDOWS/system32/WBEM
PATHEXT='.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH'
PIPESTATUS=([0]="0")
POSIXLY_CORRECT=y
PPID=3768
PROCESSOR_ARCHITECTURE=x86
PROCESSOR_LEVEL=6
PROCESSOR_REVISION=0f0b
PROMPT='$P$G'
PS4='+ '
PWD=/c/0/Downloads/msysCORE-1.0.11-20080826.tar/msysCORE-1.0.11-
20080826/BOSNT01
SESSIONNAME=Console
SHELL=/bin/sh
SHELLOPTS=braceexpand:hashall:interactive-comments:posix
SHLVL=2
SYSTEMDRIVE=C:
SYSTEMROOT='C:\WINDOWS'
TEMP=/tmp
TERM=msys
TMP=/tmp
UATDATA='C:\WINDOWS\system32\CCM\UATData\D9F8C395-CAB8-491d-B8AC
-179A1FE1BE77'
UID=500
WD='C:\0\Downloads\msysCORE-1.0.11-20080826.tar\msysCORE-1.0.11-
20080826\\bin\'
_=echo

$ msysinfo all >msysinfo.txt   will save this to a file


> Also, send the resulting stack dump if any.

MSYS-1.0.11 Build:2008-08-25 23:40
Exception: STATUS_ACCESS_VIOLATION at eip=71064BF6
eax=7FFDD000 ebx=00000000 ecx=00000000 edx=0022F978 esi=00000000 
edi=0022F90C
ebp=0022F47C esp=0022F464 program=C:\mozilla-build\msys\bin\sh.exe
cs=001B ds=0023 es=0023 fs=003B gs=0000 ss=0023
Stack trace:
Frame     Function  Args
0022F47C  71064BF6  (00000000, 00000000, 00000000, 00000000)
0022F928  71027362  (0022FAA8, 0022FAAC, 0022FAB0, 0022F950)
0022FAB8  71027B92  (00000000, 00000000, 0A015840, 00000000)
0022FAF8  00420CFD  (0A015688, 00000000, 00000000, 0022FB3C)
0022FB38  00415420  (0A015720, 00000000, 0A015840, FFFFFFFF)
0022FB98  00414585  (0A015220, FFFFFFFF, FFFFFFFF, 00000000)
0022FBF8  004110CE  (0A015208, 00000000, FFFFFFFF, FFFFFFFF)
0022FC48  00410A8B  (0A015208, 00000000, 00000000, 71081492)
0022FC88  00412307  (0A0152E8, 00000000, FFFFFFFF, FFFFFFFF)
0022FCE8  0041130F  (0A0152E8, 00000000, FFFFFFFF, FFFFFFFF)
0022FD38  00411DF8  (0A015310, 00000000, FFFFFFFF, FFFFFFFF)
0022FDA4  00410DD8  (0A015310, 00000000, FFFFFFFF, FFFFFFFF)
0022FDF4  00455CC4  (0A014C60, 00401183, 00000004, 0041B376)
0022FE24  00403939  (7111B19C, 00000003, 00000003, 00000000)
0022FEC4  00401944  (00000003, 71115704, 0A010278, 00000000)
0022FF20  71004B28  (9E7C1C4C, 00005420, 0022FF60, 0048CDE0)

Adam Rosi-Kessel wrote:
> Cesar Strauss wrote, on 12/6/2008 7:07 AM:
>>>> $ msysinfo
>>> Please execute the msysinfo command with an all parameter (msysinfo all).
>> Adam, could you repeat the above command with the latest MSYS 
>> development version?
>> Download msysCORE-1.0.11-20080826.tar.gz from :
>> Technology Preview: MSYS-1.0.11
>> https://sourceforge.net/project/showfiles.php?group_id=2435&package_id=24963&release_id=46827
>> Unpack it in a empty directory and run msys.bat.
> 
> No luck, same result. Note that the stackdumps when running msysinfo 
> occur at different times in successive runs.
> 
> msysinfo-1.3: Send this to the MSYS support list:
> 
> MSYS 1.0.11(0.46/3/2) 2008-08-25 23:40 i686 unknown; targ=MINGW32

^^
This seems fine. It's the latest development version.


> GNU bash, version 3.1.0(1)-release (i686-pc-msys); ENV=.profile
> GNU Make 3.81This program built for i686-pc-msys; MAKE_MODE=unix
> /bin/msysinfo: line 12: gcc: command not found
> ; targ=MINGW32
> /bin/msysinfo: line 13: ld: command not found

^^
No worries here.


> 2008-08-25 20:22:40.000000000 -0400 /bin/msys-1.0.dll
> 2008-08-25 20:22:40.000000000 -0400 /bin/msys-bz2-1.dll
> 2008-08-25 20:22:39.000000000 -0400 /bin/make.exe
>        0 [main] sh 4688 open_stackdumpfile: Dumping stack trace to 
> sh.exe.stackdump
>        0 [main] sh 4324 open_stackdumpfile: Dumping stack trace to 
> sh.exe.stackdump

^^
And here we have the crash...


> HOME=/c/0/Downloads/msysCORE-1.0.11-20080826.tar/msysCORE-1.0.11-20080826/BOSNT01

^^
That's suspicious. HOME=/home/<user> is expected here.


> Sysname=MINGW32_NT-5.1  OSTYPE=msys  TERM=msys
> PATH=.:/usr/local/bin:/mingw/bin:/bin:/c/WINDOWS/system32:/c/WIN
> DOWS:/c/WINDOWS/system32/WBEM
> $ ls -tx 
> /c/0/Downloads/msysCORE-1.0.11-20080826.tar/msysCORE-1.0.11-20080826/BOSNT01
> sh.exe.stackdump  .bash_history  .subversion/  .inputrc

^^
That's suspicious. I wonder where .subversion comes from?

> 
> 5387dd240f24207c647df9b023a75030 */bin/msys-1.0.dll
> d919908ae36c4673a920d29c359603ba */bin/msys-bz2-1.dll
> 51988e39bcc4c5120248bfb7077e3a6f */bin/make.exe
> md5sum: .exe: No such file or directory
> md5sum: .exe: No such file or directory
> 
> In /etc/fstab:
> cat: /etc/fstab: No such file or directory
> 

^^
No worries here.

> In /etc/profile:
>    export PATH=".:/usr/local/bin:/mingw/bin:/bin:$PATH"
>    export PATH=".:/usr/local/bin:/bin:/mingw/bin:$PATH"
> export HOME LOGNAME MSYSTEM HISTFILE
> export MAKE_MODE=unix
> export PS1='\[\033]0;$MSYSTEM:\w\007
> 
> /bin/msys-1.0.dll:%%% MSYS dll major: 1000
> /bin/msys-1.0.dll:%%% MSYS dll minor: 11
> /bin/msys-1.0.dll:%%% MSYS dll epoch: 19
> /bin/msys-1.0.dll:%%% MSYS dll bad signal mask: 19005
> /bin/msys-1.0.dll:%%% MSYS dll old termios: 5
> /bin/msys-1.0.dll:%%% MSYS dll malloc env: 28
> /bin/msys-1.0.dll:%%% MSYS api major: 0
> /bin/msys-1.0.dll:%%% MSYS api minor: 46
> /bin/msys-1.0.dll:%%% MSYS shared data: 3
> /bin/msys-1.0.dll:%%% MSYS dll identifier: msys-1.0
> /bin/msys-1.0.dll:%%% MSYS mount registry: 2
> /bin/msys-1.0.dll:%%% MSYS cygnus registry name: msys
> /bin/msys-1.0.dll:%%% MSYS cygwin registry name: 1.0
> /bin/msys-1.0.dll:%%% MSYS program options name: Program Options
> /bin/msys-1.0.dll:%%% MSYS cygwin mount registry name: mounts v2
> /bin/msys-1.0.dll:%%% MSYS cygdrive flags: cygdrive flags
> /bin/msys-1.0.dll:%%% MSYS cygdrive prefix: cygdrive prefix
> /bin/msys-1.0.dll:%%% MSYS cygdrive default prefix:
> /bin/msys-1.0.dll:%%% MSYS build date: Mon Aug 25 23:40:29 GMT 2008
> /bin/msys-1.0.dll:%%% MSYS shared id: msys-1.0S3

^^
Seems fine.

> !C:='C:\0\Downloads\msysCORE-1.0.11-20080826.tar\msysCORE-1.0.11
> -20080826'
> !F:='F:\'
> !M:='M:\'
> BASH=/bin/sh
> BASH_ARGC=([0]="1")
> BASH_ARGV=([0]="all")
> BASH_LINENO=([0]="0")
> BASH_SOURCE=([0]="/bin/msysinfo")
> BASH_VERSINFO=([0]="3" [1]="1" [2]="0" [3]="1" [4]="release"
> [5]="i686-pc-msys")
> BASH_VERSION='3.1.0(1)-release'
> BGCOLOR=LightYellow
> COLORFGBG='default;default'
> COLORTERM=rxvt-xpm
> COMSPEC='C:\WINDOWS\system32\cmd.exe'
> DIRSTACK=()
> DISPLAY=:0
> EUID=500
> FGCOLOR=Navy
> FP_NO_HOST_CHECK=NO
> GROUPS=()
> HISTFILE=/c/0/Downloads/msysCORE-1.0.11-20080826.tar/msysCORE-1.
> 0.11-20080826/BOSNT01/.bash_history
> HOME=/c/0/Downloads/msysCORE-1.0.11-20080826.tar/msysCORE-1.0.11
> -20080826/BOSNT01
> HOSTNAME=BOSL10803
> HOSTTYPE=i686
> IFS=' 	
> '
> MACHTYPE=i686-pc-msys
> MAKE_MODE=unix
> MINGW32BGCOLOR=LightYellow
> MINGW32FGCOLOR=Navy
> MSYSBGCOLOR=White
> MSYSCON=rxvt.exe
> MSYSFGCOLOR=Black
> MSYSTEM=MINGW32
> NUMBER_OF_PROCESSORS=2
> OPTERR=1
> OPTIND=1
> OS=Windows_NT
> OSTYPE=msys
> PATH=.:/usr/local/bin:/mingw/bin:/bin:/c/WINDOWS/system32:/c/WIN
> DOWS:/c/WINDOWS/system32/WBEM
> PATHEXT='.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH'
> PIPESTATUS=([0]="0")
> POSIXLY_CORRECT=y
> PPID=3768
> PROCESSOR_ARCHITECTURE=x86
> PROCESSOR_LEVEL=6
> PROCESSOR_REVISION=0f0b
> PROMPT='$P$G'
> PS4='+ '
> PWD=/c/0/Downloads/msysCORE-1.0.11-20080826.tar/msysCORE-1.0.11-
> 20080826/BOSNT01
> SESSIONNAME=Console
> SHELL=/bin/sh
> SHELLOPTS=braceexpand:hashall:interactive-comments:posix
> SHLVL=2
> SYSTEMDRIVE=C:
> SYSTEMROOT='C:\WINDOWS'
> TEMP=/tmp
> TERM=msys
> TMP=/tmp
> UATDATA='C:\WINDOWS\system32\CCM\UATData\D9F8C395-CAB8-491d-B8AC
> -179A1FE1BE77'
> UID=500
> WD='C:\0\Downloads\msysCORE-1.0.11-20080826.tar\msysCORE-1.0.11-
> 20080826\\bin\'
> _=echo
> 
> $ msysinfo all >msysinfo.txt   will save this to a file
> 

^^
Also fine.

> 
>> Also, send the resulting stack dump if any.
> 
> MSYS-1.0.11 Build:2008-08-25 23:40

^^
Fine.

> Exception: STATUS_ACCESS_VIOLATION at eip=71064BF6
> eax=7FFDD000 ebx=00000000 ecx=00000000 edx=0022F978 esi=00000000 
> edi=0022F90C
> ebp=0022F47C esp=0022F464 program=C:\mozilla-build\msys\bin\sh.exe

^^
Extremely suspicious. What is mozilla doing here? The running program 
should be <path to msysCORE>\bin\sh.exe.

> cs=001B ds=0023 es=0023 fs=003B gs=0000 ss=0023
> Stack trace:
> Frame     Function  Args
> 0022F47C  71064BF6  (00000000, 00000000, 00000000, 00000000)
> 0022F928  71027362  (0022FAA8, 0022FAAC, 0022FAB0, 0022F950)
> 0022FAB8  71027B92  (00000000, 00000000, 0A015840, 00000000)

^^
The crash seems to be from within the msys-1.0.dll (base adress 7100000).

> 0022FAF8  00420CFD  (0A015688, 00000000, 00000000, 0022FB3C)
> 0022FB38  00415420  (0A015720, 00000000, 0A015840, FFFFFFFF)
> 0022FB98  00414585  (0A015220, FFFFFFFF, FFFFFFFF, 00000000)
> 0022FBF8  004110CE  (0A015208, 00000000, FFFFFFFF, FFFFFFFF)
> 0022FC48  00410A8B  (0A015208, 00000000, 00000000, 71081492)
> 0022FC88  00412307  (0A0152E8, 00000000, FFFFFFFF, FFFFFFFF)
> 0022FCE8  0041130F  (0A0152E8, 00000000, FFFFFFFF, FFFFFFFF)
> 0022FD38  00411DF8  (0A015310, 00000000, FFFFFFFF, FFFFFFFF)
> 0022FDA4  00410DD8  (0A015310, 00000000, FFFFFFFF, FFFFFFFF)
> 0022FDF4  00455CC4  (0A014C60, 00401183, 00000004, 0041B376)
> 0022FE24  00403939  (7111B19C, 00000003, 00000003, 00000000)
> 0022FEC4  00401944  (00000003, 71115704, 0A010278, 00000000)
> 0022FF20  71004B28  (9E7C1C4C, 00005420, 0022FF60, 0048CDE0)
> 

Let's try first if we can avoid running the mozilla tools.

Please unpack msysCORE again in a new empty directory.

Then, open a Windows Command Prompt, and type:

set HOME=
set DISPLAY=
set PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem
<path to msysCORE>\bin\sh.exe --login -i

Then run 'msysinfo all'.
Please run the 'mount' command as well.

Regards,
Cesar

Cesar Strauss wrote, on 12/6/2008 6:02 PM:
>> HOME=/c/0/Downloads/msysCORE-1.0.11-20080826.tar/msysCORE-1.0.11-20080826/BOSNT01
> ^^
> That's suspicious. HOME=/home/<user> is expected here.

Running msys.bat, it just seems to set HOME to that directory. I created 
a /home/$USER within msys and exported HOME to that directory. No 
difference in results.

>> Sysname=MINGW32_NT-5.1  OSTYPE=msys  TERM=msys
>> PATH=.:/usr/local/bin:/mingw/bin:/bin:/c/WINDOWS/system32:/c/WIN
>> DOWS:/c/WINDOWS/system32/WBEM
>> $ ls -tx 
>> /c/0/Downloads/msysCORE-1.0.11-20080826.tar/msysCORE-1.0.11-20080826/BOSNT01
>> sh.exe.stackdump  .bash_history  .subversion/  .inputrc
> ^^
> That's suspicious. I wonder where .subversion comes from?

That's from trying to build songbird, which starts with a svn up. I'm 
not sure why it's showing up in home. In the example above, I started 
with a clean $HOME, same result.

>> Exception: STATUS_ACCESS_VIOLATION at eip=71064BF6
>> eax=7FFDD000 ebx=00000000 ecx=00000000 edx=0022F978 esi=00000000 
>> edi=0022F90C
>> ebp=0022F47C esp=0022F464 program=C:\mozilla-build\msys\bin\sh.exe
> ^^
> Extremely suspicious. What is mozilla doing here? The running program 
> should be <path to msysCORE>\bin\sh.exe.
...
> Let's try first if we can avoid running the mozilla tools.
> Please unpack msysCORE again in a new empty directory.

Right, sorry, I was actually providing a stack dump from a mozilla-build 
attempt started from the experimental msys core. Not sure why it was 
using mozilla-build sh.exe rather than the one in msys. In any case...

> Then, open a Windows Command Prompt, and type:
> set HOME=
> set DISPLAY=
> set PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem
> <path to msysCORE>\bin\sh.exe --login -i
> Then run 'msysinfo all'.
> Please run the 'mount' command as well.

Results:

msysinfo-1.3: Send this to the MSYS support list:

MSYS 1.0.11(0.46/3/2) 2008-08-25 23:40 i686 unknown; targ=MINGW32
GNU bash, version 3.1.0(1)-release (i686-pc-msys); ENV=.profile
GNU Make 3.81This program built for i686-pc-msys; MAKE_MODE=unix
/bin/msysinfo: line 12: gcc: command not found
; targ=MINGW32
/bin/msysinfo: line 13: ld: command not found
2008-08-25 20:22:40.000000000 -0400 /bin/msys-1.0.dll
2008-08-25 20:22:40.000000000 -0400 /bin/msys-bz2-1.dll
2008-08-25 20:22:39.000000000 -0400 /bin/make.exe
ls: .exe: No such file or directory
ls: .exe: No such file or directory
HOME=/home/AVK
Sysname=MINGW32_NT-5.1  OSTYPE=msys  TERM=cygwin
PATH=.:/usr/local/bin:/mingw/bin:/bin:/c/windows/system32:/c/windows:/c/windows/system32/wbem
$ ls -tx /home/AVK
sh.exe.stackdump  trunk/

5387dd240f24207c647df9b023a75030 */bin/msys-1.0.dll
d919908ae36c4673a920d29c359603ba */bin/msys-bz2-1.dll
51988e39bcc4c5120248bfb7077e3a6f */bin/make.exe
md5sum: .exe: No such file or directory
md5sum: .exe: No such file or directory

In /etc/fstab:
cat: /etc/fstab: No such file or directory

In /etc/profile:
   export PATH=".:/usr/local/bin:/mingw/bin:/bin:$PATH"
   export PATH=".:/usr/local/bin:/bin:/mingw/bin:$PATH"
export HOME LOGNAME MSYSTEM HISTFILE
export MAKE_MODE=unix
export PS1='\[\033]0;$MSYSTEM:\w\007

/bin/msys-1.0.dll:%%% MSYS dll major: 1000
/bin/msys-1.0.dll:%%% MSYS dll minor: 11
/bin/msys-1.0.dll:%%% MSYS dll epoch: 19
/bin/msys-1.0.dll:%%% MSYS dll bad signal mask: 19005
/bin/msys-1.0.dll:%%% MSYS dll old termios: 5
/bin/msys-1.0.dll:%%% MSYS dll malloc env: 28
/bin/msys-1.0.dll:%%% MSYS api major: 0
/bin/msys-1.0.dll:%%% MSYS api minor: 46
/bin/msys-1.0.dll:%%% MSYS shared data: 3
/bin/msys-1.0.dll:%%% MSYS dll identifier: msys-1.0
/bin/msys-1.0.dll:%%% MSYS mount registry: 2
/bin/msys-1.0.dll:%%% MSYS cygnus registry name: msys
/bin/msys-1.0.dll:%%% MSYS cygwin registry name: 1.0
/bin/msys-1.0.dll:%%% MSYS program options name: Program Options
/bin/msys-1.0.dll:%%% MSYS cygwin mount registry name: mounts v2
/bin/msys-1.0.dll:%%% MSYS cygdrive flags: cygdrive flags
/bin/msys-1.0.dll:%%% MSYS cygdrive prefix: cygdrive prefix
/bin/msys-1.0.dll:%%% MSYS cygdrive default prefix:
/bin/msys-1.0.dll:%%% MSYS build date: Mon Aug 25 23:40:29 GMT 2008
/bin/msys-1.0.dll:%%% MSYS shared id: msys-1.0S3

!C:='C:\Documents and Settings\avk\Desktop'
ALLUSERSPROFILE='C:\Documents and Settings\All Users'
APPDATA='C:\Documents and Settings\avk\Application Data'
BASH=/bin/sh
BASH_ARGC=([0]="1")
BASH_ARGV=([0]="all")
BASH_LINENO=([0]="0")
BASH_SOURCE=([0]="/bin/msysinfo")
BASH_VERSINFO=([0]="3" [1]="1" [2]="0" [3]="1" [4]="release"
[5]="i686-pc-msys")
BASH_VERSION='3.1.0(1)-release'
CLASSPATH='.;"C:\WINDOWS\System32\QTJava.zip";C:\Program
Files\Java\jre1.6.0_07\lib\ext\QTJava.zip'
COMMONPROGRAMFILES='C:\Program Files\Common Files'
COMSPEC='C:\WINDOWS\system32\cmd.exe'
DIRSTACK=()
EUID=500
FP_NO_HOST_CHECK=NO
GROUPS=()
HISTFILE=/home/AVK/.bash_history
HOME=/home/AVK
HOSTTYPE=i686
IFS=' 	
'
LOGNAME=AVK
MACHTYPE=i686-pc-msys
MAKE_MODE=unix
MSYSTEM=MINGW32
NUMBER_OF_PROCESSORS=2
OPTERR=1
OPTIND=1
OS=Windows_NT
OSTYPE=msys
PATH=.:/usr/local/bin:/mingw/bin:/bin:/c/windows/system32:/c/win
dows:/c/windows/system32/wbem
PATHEXT='.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH'
PIPESTATUS=([0]="0")
POSIXLY_CORRECT=y
PPID=1972
PROCESSOR_ARCHITECTURE=x86
PROCESSOR_IDENTIFIER='x86 Family 6 Model 15 Stepping 11,
GenuineIntel'
PROCESSOR_LEVEL=6
PROCESSOR_REVISION=0f0b
PROGRAMFILES='C:\Program Files'
PROMPT='$P$G'
PS4='+ '
PWD=/home/AVK
QTJAVA='C:\Program Files\Java\jre1.6.0_07\lib\ext\QTJava.zip'
SESSIONNAME=Console
SHELL=/bin/sh
SHELLOPTS=braceexpand:hashall:interactive-comments:posix
SHLVL=2
SYSTEMDRIVE=C:
SYSTEMROOT='C:\WINDOWS'
TEMP=/tmp
TERM=cygwin
TMP=/tmp
UATDATA='C:\WINDOWS\system32\CCM\UATData\D9F8C395-CAB8-491d-B8AC
-179A1FE1BE77'
UID=500
USERPROFILE='C:\Documents and Settings\avk'
VC8EXPRESSDIR='C:\program Files\Microsoft Visual Studio 8\VC'
VIM='C:\program Files\vim'
VS80COMNTOOLS='C:\Program Files\Microsoft Visual Studio
8\Common7\Tools\'
WINDIR='C:\WINDOWS'
_=echo

$ msysinfo all >msysinfo.txt   will save this to a file

Here's the mount info:

c:\0\Downloads\msysCORE-1.0.11-20080826.tar\msysCORE-1.0.11-20080826 on 
/usr type user (binmode,noumount)
c:\0\Downloads\msysCORE-1.0.11-20080826.tar\msysCORE-1.0.11-20080826 on 
/ type user (binmode,noumount)
C:\DOCUME~1\avk\LOCALS~1\Temp on /tmp type user (binmode,noumount)
c: on /c type user (binmode,noumount)
d: on /d type user (binmode,noumount)

Here's the stack dump from the msysinfo session above:

MSYS-1.0.11 Build:2008-08-25 23:40
Exception: STATUS_ACCESS_VIOLATION at eip=71064BF6
eax=7FFDD000 ebx=00000000 ecx=00000000 edx=0022F734 esi=00000000 
edi=0022F6C8 ebp=0022F238 esp=0022F220 
program=c:\0\Downloads\msysCORE-1.0.11-20080826.tar\msysCORE-1.0.11-20080826\bin\sh.exe 

cs=001B ds=0023 es=0023 fs=003B gs=0000 ss=0023
Stack trace:
Frame     Function  Args
0022F238  71064BF6  (00000000, 00000000, 00000000, 00000000)
0022F6E4  71027362  (0022F864, 0022F868, 0022F86C, 0022F70C)
0022F874  71027B92  (FFFFFFFF, 00000000, 00000000, 00000000)
0022F8B4  00420CFD  (0A014C38, 00000000, 0022F904, 00413F1A)
0022F904  00413F89  (0A015C50, FFFFFFFF, 00000004, 00000000)
0022F964  004110CE  (0A014E40, 00000000, FFFFFFFF, 00000004)
0022F9C4  00412012  (0A015D08, 00000000, FFFFFFFF, FFFFFFFF)
0022FA14  00412269  (0A015D08, 00000000, FFFFFFFF, FFFFFFFF)
0022FA74  0041130F  (0A015D08, 00000000, FFFFFFFF, FFFFFFFF)
0022FAC4  00455CC4  (0A0132B8, 00429662, 00000004, 00429842)
0022FB24  0042997D  (0A0132B8, 00000000, 0A014D88, 00000078)
0022FB94  0042DD60  (0A015010, 0022FC18, 00000000, 0022FC90)
0022FC34  0042E644  (0A014D88, 00000000, 00000000, 0022FC8C)
0022FC94  0042F8EC  (0A014C88, 0000001F, 0022FCC4, 0040ED5F)
0022FCC4  0042FCA1  (0A014F20, 0000001F, 00000000, 7102CFF1)
0022FCE4  00430924  (0A014F20, 00000000, 0022FD44, 00414043)
End of stack trace (more stack frames may be present)

Quoting Adam Rosi-Kessel <adam@...>:

>
>>> Exception: STATUS_ACCESS_VIOLATION at eip=71064BF6
>>> eax=7FFDD000 ebx=00000000 ecx=00000000 edx=0022F978 esi=00000000
>>> edi=0022F90C
>>> ebp=0022F47C esp=0022F464 program=C:\mozilla-build\msys\bin\sh.exe
>> ^^
>> Extremely suspicious. What is mozilla doing here? The running program
>> should be <path to msysCORE>\bin\sh.exe.
> ...
>> Let's try first if we can avoid running the mozilla tools.
>> Please unpack msysCORE again in a new empty directory.
>
> Right, sorry, I was actually providing a stack dump from a mozilla-build
> attempt started from the experimental msys core. Not sure why it was
> using mozilla-build sh.exe rather than the one in msys. In any case...
>

If you have two MSYS environments using bits of each other it will 
definitely cause you issues.

Earnie

Earnie Boyd wrote, on 12/7/2008 12:01 PM:
>>>> Exception: STATUS_ACCESS_VIOLATION at eip=71064BF6
>>>> eax=7FFDD000 ebx=00000000 ecx=00000000 edx=0022F978 esi=00000000
>>>> edi=0022F90C
>>>> ebp=0022F47C esp=0022F464 program=C:\mozilla-build\msys\bin\sh.exe
>>> ^^
>>> Extremely suspicious. What is mozilla doing here? The running program
>>> should be <path to msysCORE>\bin\sh.exe.
>> ...
>>> Let's try first if we can avoid running the mozilla tools.
>>> Please unpack msysCORE again in a new empty directory.
>> Right, sorry, I was actually providing a stack dump from a mozilla-build
>> attempt started from the experimental msys core. Not sure why it was
>> using mozilla-build sh.exe rather than the one in msys. In any case...
> If you have two MSYS environments using bits of each other it will 
> definitely cause you issues.

Just to be clear -- if I create a brand new msys environment in a 
separate directory tree, clear the PATH and all other environmental 
variables, disable all extraneous services (e.g. virus checking, Google 
Desktop, anything else that is not an essential service), then start the 
new msys environment and run msysinfo, I get stackdumps. The logs/stack 
dumps I sent in my last posting were all from within msys 1.0.11, with 
no attempt to build anything within the mozilla-build directory.

Adam

Quoting Adam Rosi-Kessel <adam@...>:

>
> msysinfo-1.3: Send this to the MSYS support list:
>
--8<--
> $ ls -tx /home/AVK
> sh.exe.stackdump  trunk/
>
--8<--
>
> $ msysinfo all >msysinfo.txt   will save this to a file
>
--8<--
>
> Here's the stack dump from the msysinfo session above:
>

There wasn't a stackdump with this msysinfo session.  It existed in the 
/home/AVK directory before the msysinfo session.

Earnie

Earnie Boyd wrote, on 12/7/2008 12:16 PM:
> Quoting Adam Rosi-Kessel <adam@...>:
> 
>> msysinfo-1.3: Send this to the MSYS support list:
>>
> --8<--
>> $ ls -tx /home/AVK
>> sh.exe.stackdump  trunk/
>>
> --8<--
>> $ msysinfo all >msysinfo.txt   will save this to a file
>>
> --8<--
>> Here's the stack dump from the msysinfo session above:
> There wasn't a stackdump with this msysinfo session.  It existed in the 
> /home/AVK directory before the msysinfo session.

I don't think so -- I just ran a new session, rm 
/home/avk/sh.exe.stackdump, then ran msysinfo all with the same result 
(i.e., sh.exe.stackdump listed in msysinfo.txt).

I've pasted the newest stackdump below, although I don't think it 
differs materially.

I should note that I'm actually running

msysinfo all > /c/msysinfo.txt 2>&1

so that the crash messages show up in /c/msysinfo.txt.

Isn't it possible that the stackdump is getting created before msysinfo 
all runs ls -tx /home/AVK? Actually, if you look at the msysinfo.txt 
I've pasted below the stack dump, it seems to be the case -- the crash 
is up top, before ls -tx /home/AVK.

Finally, before pasting below, I'll note that it doesn't crash 100% of 
the time when I run msysinfo. I had to execute the command twice, for 
example, to get a crash as pasted below.

MSYS-1.0.11 Build:2008-08-25 23:40
Exception: STATUS_ACCESS_VIOLATION at eip=71064BF6
eax=7FFDF000 ebx=00000000 ecx=00000000 edx=0022F734 esi=00000000 
edi=0022F6C8
ebp=0022F238 esp=0022F220 
program=c:\0\Downloads\msysCORE-1.0.11-20080826.tar\msysCORE-1.0.11-20080826\bin\sh.exe
cs=001B ds=0023 es=0023 fs=003B gs=0000 ss=0023
Stack trace:
Frame     Function  Args
0022F238  71064BF6  (00000000, 00000000, 00000000, 00000000)
0022F6E4  71027362  (0022F864, 0022F868, 0022F86C, 0022F70C)
0022F874  71027B92  (FFFFFFFF, 00000000, 00000000, 00000000)
0022F8B4  00420CFD  (0A014D50, 00000000, 0022F904, 00413F1A)
0022F904  00413F89  (0A015DE8, FFFFFFFF, 00000004, 00000000)
0022F964  004110CE  (0A015DD0, 00000000, FFFFFFFF, 00000004)
0022F9C4  00412012  (0A015FB0, 00000000, FFFFFFFF, FFFFFFFF)
0022FA14  00412269  (0A015FB0, 00000000, FFFFFFFF, FFFFFFFF)
0022FA74  0041130F  (0A015FB0, 00000000, FFFFFFFF, FFFFFFFF)
0022FAC4  00455CC4  (0A0154C0, 00429662, 00000004, 00429842)
0022FB24  0042997D  (0A0154C0, 00000000, 0A014FC0, 00000078)
0022FB94  0042DD60  (0A014F28, 0022FC18, 00000000, 0022FC90)
0022FC34  0042E644  (0A014FC0, 00000000, 00000000, 0022FC8C)
0022FC94  0042F8EC  (0A014FB0, 0000001F, 0022FCC4, 0040ED5F)
0022FCC4  0042FCA1  (0A014988, 0000001F, 00000000, 7102CFF1)
0022FCE4  00430924  (0A014988, 00000000, 0022FD44, 00414043)
End of stack trace (more stack frames may be present)

msysinfo-1.3: Send this to the MSYS support list:

MSYS 1.0.11(0.46/3/2) 2008-08-25 23:40 i686 unknown; targ=MINGW32
GNU bash, version 3.1.0(1)-release (i686-pc-msys); ENV=.profile
       0 [main] sh 4864 open_stackdumpfile: Dumping stack trace to 
sh.exe.stackdump
This program built for i686-pc-msys; MAKE_MODE=unix
/bin/msysinfo: line 12: gcc: command not found
; targ=MINGW32
/bin/msysinfo: line 13: ld: command not found
2008-08-25 20:22:40.000000000 -0400 /bin/msys-1.0.dll
2008-08-25 20:22:40.000000000 -0400 /bin/msys-bz2-1.dll
2008-08-25 20:22:39.000000000 -0400 /bin/make.exe
ls: .exe: No such file or directory
ls: .exe: No such file or directory
HOME=/home/AVK
Sysname=MINGW32_NT-5.1  OSTYPE=msys  TERM=cygwin
PATH=.:/usr/local/bin:/mingw/bin:/bin:/c/windows/system32:/c/windows:/c/windows/system32/wbem
$ ls -tx /home/AVK
sh.exe.stackdump  .bash_history  trunk/

5387dd240f24207c647df9b023a75030 */bin/msys-1.0.dll
d919908ae36c4673a920d29c359603ba */bin/msys-bz2-1.dll
51988e39bcc4c5120248bfb7077e3a6f */bin/make.exe
md5sum: .exe: No such file or directory
md5sum: .exe: No such file or directory

In /etc/fstab:
/tmp	/tmp

In /etc/profile:
   export PATH=".:/usr/local/bin:/mingw/bin:/bin:$PATH"
   export PATH=".:/usr/local/bin:/bin:/mingw/bin:$PATH"
export HOME LOGNAME MSYSTEM HISTFILE
export MAKE_MODE=unix
export PS1='\[\033]0;$MSYSTEM:\w\007

/bin/msys-1.0.dll:%%% MSYS dll major: 1000
/bin/msys-1.0.dll:%%% MSYS dll minor: 11
/bin/msys-1.0.dll:%%% MSYS dll epoch: 19
/bin/msys-1.0.dll:%%% MSYS dll bad signal mask: 19005
/bin/msys-1.0.dll:%%% MSYS dll old termios: 5
/bin/msys-1.0.dll:%%% MSYS dll malloc env: 28
/bin/msys-1.0.dll:%%% MSYS api major: 0
/bin/msys-1.0.dll:%%% MSYS api minor: 46
/bin/msys-1.0.dll:%%% MSYS shared data: 3
/bin/msys-1.0.dll:%%% MSYS dll identifier: msys-1.0
/bin/msys-1.0.dll:%%% MSYS mount registry: 2
/bin/msys-1.0.dll:%%% MSYS cygnus registry name: msys
/bin/msys-1.0.dll:%%% MSYS cygwin registry name: 1.0
/bin/msys-1.0.dll:%%% MSYS program options name: Program Options
/bin/msys-1.0.dll:%%% MSYS cygwin mount registry name: mounts v2
/bin/msys-1.0.dll:%%% MSYS cygdrive flags: cygdrive flags
/bin/msys-1.0.dll:%%% MSYS cygdrive prefix: cygdrive prefix
/bin/msys-1.0.dll:%%% MSYS cygdrive default prefix:
/bin/msys-1.0.dll:%%% MSYS build date: Mon Aug 25 23:40:29 GMT 2008
/bin/msys-1.0.dll:%%% MSYS shared id: msys-1.0S3

!C:='C:\Documents and Settings\avk\Desktop'
ALLUSERSPROFILE='C:\Documents and Settings\All Users'
APPDATA='C:\Documents and Settings\avk\Application Data'
BASH=/usr/bin/sh
BASH_ARGC=([0]="1")
BASH_ARGV=([0]="all")
BASH_LINENO=([0]="0")
BASH_SOURCE=([0]="/bin/msysinfo")
BASH_VERSINFO=([0]="3" [1]="1" [2]="0" [3]="1" [4]="release"
[5]="i686-pc-msys")
BASH_VERSION='3.1.0(1)-release'
CLASSPATH='.;"C:\WINDOWS\System32\QTJava.zip";C:\Program 
Files\Java\jre1.6.0_07\lib\ext\QTJava.zip'
COMMONPROGRAMFILES='C:\Program Files\Common Files'
COMSPEC='C:\WINDOWS\system32\cmd.exe'
DIRSTACK=()
EUID=500
FP_NO_HOST_CHECK=NO
GROUPS=()
HISTFILE=/home/AVK/.bash_history
HOME=/home/AVK
HOSTTYPE=i686
IFS=' 	
'
LOGNAME=AVK
MACHTYPE=i686-pc-msys
MAKE_MODE=unix
MSYSTEM=MINGW32
NUMBER_OF_PROCESSORS=2
OPTERR=1
OPTIND=1
OS=Windows_NT
OSTYPE=msys
PATH=.:/usr/local/bin:/mingw/bin:/bin:/c/windows/system32:/c/win
dows:/c/windows/system32/wbem
PATHEXT='.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH'
PIPESTATUS=([0]="0")
POSIXLY_CORRECT=y
PPID=4328
PROCESSOR_ARCHITECTURE=x86
PROCESSOR_IDENTIFIER='x86 Family 6 Model 15 Stepping 11, GenuineIntel'
PROCESSOR_LEVEL=6
PROCESSOR_REVISION=0f0b
PROGRAMFILES='C:\Program Files'
PROMPT='$P$G'
PS4='+ '
PWD=/home/AVK
QTJAVA='C:\Program Files\Java\jre1.6.0_07\lib\ext\QTJava.zip'
SESSIONNAME=Console
SHELL=/bin/sh
SHELLOPTS=braceexpand:hashall:interactive-comments:posix
SHLVL=2
SYSTEMDRIVE=C:
SYSTEMROOT='C:\WINDOWS'
TEMP=/tmp
TERM=cygwin
TMP=/tmp
UATDATA='C:\WINDOWS\system32\CCM\UATData\D9F8C395-CAB8-491d-B8AC-179A1FE1BE77'
UID=500
ULTRAMON_LANGDIR='C:\Program Files\UltraMon\Resources\en'
USER=AVK
USERNAME=AVK
USERPROFILE='C:\Documents and Settings\avk'
VC8EXPRESSDIR='C:\program Files\Microsoft Visual Studio 8\VC'
VIM='C:\program Files\vim'
VS80COMNTOOLS='C:\Program Files\Microsoft Visual Studio 8\Common7\Tools\'
WINDIR='C:\WINDOWS'
_=echo

$ msysinfo all >msysinfo.txt   will save this to a file

Quoting Adam Rosi-Kessel <adam@...>:

> Earnie Boyd wrote, on 12/7/2008 12:16 PM:
>> Quoting Adam Rosi-Kessel <adam@...>:
>>
>>> msysinfo-1.3: Send this to the MSYS support list:
>>>
>> --8<--
>>> $ ls -tx /home/AVK
>>> sh.exe.stackdump  trunk/
>>>
>> --8<--
>>> $ msysinfo all >msysinfo.txt   will save this to a file
>>>
>> --8<--
>>> Here's the stack dump from the msysinfo session above:
>> There wasn't a stackdump with this msysinfo session.  It existed in the
>> /home/AVK directory before the msysinfo session.
>
> I don't think so -- I just ran a new session, rm
> /home/avk/sh.exe.stackdump, then ran msysinfo all with the same result
> (i.e., sh.exe.stackdump listed in msysinfo.txt).
>
> I've pasted the newest stackdump below, although I don't think it
> differs materially.
>
> I should note that I'm actually running
>
> msysinfo all > /c/msysinfo.txt 2>&1
>
> so that the crash messages show up in /c/msysinfo.txt.
>
> Isn't it possible that the stackdump is getting created before msysinfo
> all runs ls -tx /home/AVK? Actually, if you look at the msysinfo.txt
> I've pasted below the stack dump, it seems to be the case -- the crash
> is up top, before ls -tx /home/AVK.
>
> Finally, before pasting below, I'll note that it doesn't crash 100% of
> the time when I run msysinfo. I had to execute the command twice, for
> example, to get a crash as pasted below.
>
> MSYS-1.0.11 Build:2008-08-25 23:40
> Exception: STATUS_ACCESS_VIOLATION at eip=71064BF6

I guess that leaves rebasing the msys-1.0.dll as Cesar pointed you to already.

Earnie

On Mon, Dec 08, 2008 at 07:44:44AM -0500, Earnie Boyd wrote:
 > > MSYS-1.0.11 Build:2008-08-25 23:40
 > > Exception: STATUS_ACCESS_VIOLATION at eip=71064BF6
 > I guess that leaves rebasing the msys-1.0.dll as Cesar pointed you to 
already.

I have tried  rebase -b 0x30000000 msys-1.0.dll before entering the 
shell along with all of the above (clearing the environment, shutting 
down services, running from a command shell window, disabling virus 
checking, running the experimental version, etc.), and the result is the 
same. Should I try other addresses?

Adam

Adam Rosi-Kessel wrote:
> Here's the stack dump from the msysinfo session above:
>
> MSYS-1.0.11 Build:2008-08-25 23:40
> Exception: STATUS_ACCESS_VIOLATION at eip=71064BF6
> eax=7FFDD000 ebx=00000000 ecx=00000000 edx=0022F734 esi=00000000
> edi=0022F6C8 ebp=0022F238 esp=0022F220
> program=c:\0\Downloads\msysCORE-1.0.11-20080826.tar\msysCORE-1.0.11-20080826\bin\sh.exe

Here is the stackdump annotated with function names:

> cs=001B ds=0023 es=0023 fs=003B gs=0000 ss=0023
> Stack trace:
> Frame     Function  Args
> 0022F238  71064BF6  (00000000, 00000000, 00000000, 00000000)
^^
_reent_clib in msys-1.0.dll (thread.cc)

> 0022F6E4  71027362  (0022F864, 0022F868, 0022F86C, 0022F70C)
^^
fork_parent in msys-1.0.dll (fork.cc)

> 0022F874  71027B92  (FFFFFFFF, 00000000, 00000000, 00000000)
^^
fork in msys-1.0.dll (fork.cc)

> 0022F8B4  00420CFD  (0A014C38, 00000000, 0022F904, 00413F1A)
^^
make_child in sh.exe (jobs.c)


The crash is in the _reent_clib function, which is very small:

---- begin thread.cc -----
137: #define MT_INTERFACE user_data->threadinterface
138:
139: struct _reent *
140: _reent_clib ()
141: {
142:   int tmp = GetLastError ();
143:   struct __reent_t *_r =
144:     (struct __reent_t *) TlsGetValue (MT_INTERFACE->reent_index);
145:
146: #ifdef _CYG_THREAD_FAILSAFE
147:   if (_r == 0)
148:     system_printf ("local thread storage not inited");
149: #endif
150:
151:   SetLastError (tmp);
152:   return _r->_clib;
153: }
---- end thread.cc ----

I could not obtain the exact line number of the crash, but I strongly
suspect line 152, where the '_r' pointer is dereferenced without first
checking it for NULL.

The TlsGetValue in line 144 must be returning NULL for some reason.
Unfortunately, I am not familiar with this part of the MSYS code. I
wonder what we could add to handle a NULL being returned here...

A plan is to take a look at Cygwin sources to see how they handle this.

Regards,
Cesar

Cesar Strauss wrote, on 12/8/2008 4:40 PM:
>> Here's the stack dump from the msysinfo session above:
>> MSYS-1.0.11 Build:2008-08-25 23:40
>> Exception: STATUS_ACCESS_VIOLATION at eip=71064BF6
>> eax=7FFDD000 ebx=00000000 ecx=00000000 edx=0022F734 esi=00000000
>> edi=0022F6C8 ebp=0022F238 esp=0022F220
>> program=c:\0\Downloads\msysCORE-1.0.11-20080826.tar\msysCORE-1.0.11-20080826\bin\sh.exe
> 
> Here is the stackdump annotated with function names:
> 
>> cs=001B ds=0023 es=0023 fs=003B gs=0000 ss=0023
>> Stack trace:
>> Frame     Function  Args
>> 0022F238  71064BF6  (00000000, 00000000, 00000000, 00000000)
> ^^
> _reent_clib in msys-1.0.dll (thread.cc)
> 
>> 0022F6E4  71027362  (0022F864, 0022F868, 0022F86C, 0022F70C)
> ^^
> fork_parent in msys-1.0.dll (fork.cc)
> 
>> 0022F874  71027B92  (FFFFFFFF, 00000000, 00000000, 00000000)
> ^^
> fork in msys-1.0.dll (fork.cc)
> 
>> 0022F8B4  00420CFD  (0A014C38, 00000000, 0022F904, 00413F1A)
> ^^
> make_child in sh.exe (jobs.c)
> 
> 
> The crash is in the _reent_clib function, which is very small:
> 
> ---- begin thread.cc -----
> 137: #define MT_INTERFACE user_data->threadinterface
> 138:
> 139: struct _reent *
> 140: _reent_clib ()
> 141: {
> 142:   int tmp = GetLastError ();
> 143:   struct __reent_t *_r =
> 144:     (struct __reent_t *) TlsGetValue (MT_INTERFACE->reent_index);
> 145:
> 146: #ifdef _CYG_THREAD_FAILSAFE
> 147:   if (_r == 0)
> 148:     system_printf ("local thread storage not inited");
> 149: #endif
> 150:
> 151:   SetLastError (tmp);
> 152:   return _r->_clib;
> 153: }
> ---- end thread.cc ----
> 
> I could not obtain the exact line number of the crash, but I strongly
> suspect line 152, where the '_r' pointer is dereferenced without first
> checking it for NULL.
> 
> The TlsGetValue in line 144 must be returning NULL for some reason.
> Unfortunately, I am not familiar with this part of the MSYS code. I
> wonder what we could add to handle a NULL being returned here...

If you could give me a version built with an assert call if _r is NULL, 
then I could tell you quickly if that's the problem. Should be a one 
line diff, right?

Adam

Adam Rosi-Kessel wrote:
> Cesar Strauss wrote, on 12/8/2008 4:40 PM:
>> I could not obtain the exact line number of the crash, but I strongly
>> suspect line 152, where the '_r' pointer is dereferenced without first
>> checking it for NULL.
>>
>> The TlsGetValue in line 144 must be returning NULL for some reason.
>> Unfortunately, I am not familiar with this part of the MSYS code. I
>> wonder what we could add to handle a NULL being returned here...
>
> If you could give me a version built with an assert call if _r is NULL,
> then I could tell you quickly if that's the problem. Should be a one
> line diff, right?
>

Good idea, try this one:

http://downloads.sourceforge.net/mingw/MSYS-1.0.11-20081209-dbg.tar.gz

--- a/thread.cc     Fri Jul 11 00:12:07 2008
+++ b/thread.cc Tue Dec  9 00:09:09 2008
@@ -143,6 +143,8 @@ _reent_clib ()
   struct __reent_t *_r =
     (struct __reent_t *) TlsGetValue (MT_INTERFACE->reent_index);

+    if (_r == NULL)
+      api_fatal ("Could not get reent entry on index
%d",MT_INTERFACE->reent_index);
 #ifdef _CYG_THREAD_FAILSAFE
   if (_r == 0)
     system_printf ("local thread storage not inited");

Regards,
Cesar

Cesar Strauss wrote, on 12/8/2008 7:46 PM:
>>> The TlsGetValue in line 144 must be returning NULL for some reason.
>>> Unfortunately, I am not familiar with this part of the MSYS code. I
>>> wonder what we could add to handle a NULL being returned here...
>> If you could give me a version built with an assert call if _r is NULL,
>> then I could tell you quickly if that's the problem. Should be a one
>> line diff, right?
> +    if (_r == NULL)
> +      api_fatal ("Could not get reent entry on index
> %d",MT_INTERFACE->reent_index);

Yup:

$ msysinfo all
msysinfo-1.3: Send this to the MSYS support list:

C:\0\Downloads\msys\bin\sh.exe: *** Could not get reent entry on index 8
MSYS 1.0.11(0.46/3/2) 2008-12-09 00:15 i686 unknown; targ=
GNU bash, version 3.1.0(1)-release (i686-pc-msys); ENV=.profile
C:\0\Downloads\msys\bin\sh.exe: *** Could not get reent entry on index 8
C:\0\Downloads\msys\bin\sh.exe: *** Could not get reent entry on index 8
; MAKE_MODE=unix
C:\0\Downloads\msys\bin\sh.exe: *** Could not get reent entry on index 8
C:\0\Downloads\msys\bin\sh.exe: *** Could not get reent entry on index 8
; targ=
GNU ld (GNU Binutils) 2.18.50.20080625
2008-12-08 19:28:38.000000000 -0500 /bin/msys-1.0.dll
2008-08-25 20:22:40.000000000 -0400 /bin/msys-bz2-1.dll
2008-08-25 20:22:39.000000000 -0400 /bin/make.exe
C:\0\Downloads\msys\bin\sh.exe: *** Could not get reent entry on index 8
C:\0\Downloads\msys\bin\sh.exe: *** Could not get reent entry on index 8


etc..

Quoting Adam Rosi-Kessel <adam@...>:

> On Mon, Dec 08, 2008 at 07:44:44AM -0500, Earnie Boyd wrote:
> > > MSYS-1.0.11 Build:2008-08-25 23:40
> > > Exception: STATUS_ACCESS_VIOLATION at eip=71064BF6
> > I guess that leaves rebasing the msys-1.0.dll as Cesar pointed you to
> already.
>
> I have tried  rebase -b 0x30000000 msys-1.0.dll before entering the
> shell along with all of the above (clearing the environment, shutting
> down services, running from a command shell window, disabling virus
> checking, running the experimental version, etc.), and the result is the
> same. Should I try other addresses?
>

The eip=71xxxxxx is telling me you're not using the rebased dll.  
Cesar's annotated stackdump tells me that as well.  Make sure that the 
dll is rebased.  You must have exited all sessions of MSYS before doing 
the rebase or the rebase cannot rewrite the dll file.

Earnie

Earnie Boyd wrote, on 12/9/2008 7:32 AM:
>>>> MSYS-1.0.11 Build:2008-08-25 23:40
>>>> Exception: STATUS_ACCESS_VIOLATION at eip=71064BF6
>>> I guess that leaves rebasing the msys-1.0.dll as Cesar pointed you to
>> already.
>> I have tried  rebase -b 0x30000000 msys-1.0.dll before entering the
>> shell along with all of the above (clearing the environment, shutting
>> down services, running from a command shell window, disabling virus
>> checking, running the experimental version, etc.), and the result is the
>> same. Should I try other addresses?
> The eip=71xxxxxx is telling me you're not using the rebased dll.  
> Cesar's annotated stackdump tells me that as well.  Make sure that the 
> dll is rebased.  You must have exited all sessions of MSYS before doing 
> the rebase or the rebase cannot rewrite the dll file.

Here is what I did:

(1) Closed all open applications/windows.

(2) Open a CMD.EXE window from the run prompt.

(3) cd [path to msys-dll]

(4) rebase 0x30000000 msys-1.0.dll

(5) sh.exe --login -i

I'm not sure what else I can do?

Adam

Quoting Adam Rosi-Kessel <adam@...>:

> Here is what I did:
>
> (1) Closed all open applications/windows.
>
> (2) Open a CMD.EXE window from the run prompt.
>
> (3) cd [path to msys-dll]
>
> (4) rebase 0x30000000 msys-1.0.dll
>

You can check the change with
objdump -s msys-1.0.dll > objdump.out

Check the top of the objdump.out file, the first column should begin 
with 30xxxxxx where the xxxxxx is replaced with the rest of the address.

> (5) sh.exe --login -i
>
> I'm not sure what else I can do?
>

If the msys-1.0.dll is showing you have correctly rebased the dll.  
Then the stackdump is showing that it is attempting to use a different 
version of the dll.

Earnie

Earnie Boyd wrote, on 12/10/2008 7:41 AM:
> You can check the change with
> objdump -s msys-1.0.dll > objdump.out
> Check the top of the objdump.out file, the first column should begin 
> with 30xxxxxx where the xxxxxx is replaced with the rest of the address.

OK, I think it's all checking out now -- not sure why it wasn't before.

$ objdump -s /bin/msys-1.0.dll | head -5

C:/0/Downloads/msysCORE-1.0.11-20080826.tar/msysCORE-1.0.11-20080826/bin/msys-1.0.dll: 
     file format pei-i386

Contents of section .text:
  30001000 4e554c4c 00002573 20257300 90909090  NULL..%s %s.....

That looks right, yes?

> If the msys-1.0.dll is showing you have correctly rebased the dll.  Then 
> the stackdump is showing that it is attempting to use a different 
> version of the dll.

Here's the stackdump generated while running msysinfo directly after the 
above command -- are we looking at the eip line?

$ cat sh.exe.stackdump
MSYS-1.0.11 Build:2008-08-25 23:40
Exception: STATUS_ACCESS_VIOLATION at eip=30064BF6
eax=7FFDF000 ebx=00000000 ecx=00000000 edx=0022F734 esi=00000000 
edi=0022F6C8 ebp=0022F238 esp=0022F220 
program=C:\0\Downloads\msysCORE-1.0.11-20080826.tar\msysCORE-1.0.11-20080826\bin\sh.exe
cs=001B ds=0023 es=0023 fs=003B gs=0000 ss=0023
Stack trace:
Frame     Function  Args
0022F238  30064BF6  (00000000, 00000000, 00000000, 00000000)
0022F6E4  30027362  (0022F864, 0022F868, 0022F86C, 0022F70C)
0022F874  30027B92  (FFFFFFFF, 00000000, 00000000, 00000000)
0022F8B4  00420CFD  (0A015100, 00000000, 0022F904, 00413F1A)
0022F904  00413F89  (0A015E90, FFFFFFFF, 00000004, 00000000)
0022F964  004110CE  (0A015E78, 00000000, FFFFFFFF, 00000004)
0022F9C4  00412012  (0A016058, 00000000, FFFFFFFF, FFFFFFFF)
0022FA14  00412269  (0A016058, 00000000, FFFFFFFF, FFFFFFFF)
0022FA74  0041130F  (0A016058, 00000000, FFFFFFFF, FFFFFFFF)
0022FAC4  00455CC4  (0A0151C8, 00429662, 00000004, 00429842)
0022FB24  0042997D  (0A0151C8, 00000000, 30098AD4, 00000078)
0022FB94  0042DD60  (0A015188, 0022FC18, 00000000, 0022FC90)
0022FC34  0042E644  (0A015020, 00000000, 00000000, 0022FC8C)
0022FC94  0042F8EC  (0A015010, 0000001F, 0022FCC4, 0040ED5F)
0022FCC4  0042FCA1  (0A0149E8, 0000001F, 00000000, 3002CFF1)
0022FCE4  00430924  (0A0149E8, 00000000, 0022FD44, 00414043)
End of stack trace (more stack frames may be present)

Quoting Adam Rosi-Kessel <adam@...>:

> Earnie Boyd wrote, on 12/10/2008 7:41 AM:
>> You can check the change with
>> objdump -s msys-1.0.dll > objdump.out
>> Check the top of the objdump.out file, the first column should begin
>> with 30xxxxxx where the xxxxxx is replaced with the rest of the address.
>
> OK, I think it's all checking out now -- not sure why it wasn't before.
>
> $ objdump -s /bin/msys-1.0.dll | head -5
>
> C:/0/Downloads/msysCORE-1.0.11-20080826.tar/msysCORE-1.0.11-20080826/bin/msys-1.0.dll:
>     file format pei-i386
>
> Contents of section .text:
>  30001000 4e554c4c 00002573 20257300 90909090  NULL..%s %s.....
>
> That looks right, yes?
>
>> If the msys-1.0.dll is showing you have correctly rebased the dll.  Then
>> the stackdump is showing that it is attempting to use a different
>> version of the dll.
>
> Here's the stackdump generated while running msysinfo directly after the
> above command -- are we looking at the eip line?
>
> $ cat sh.exe.stackdump
> MSYS-1.0.11 Build:2008-08-25 23:40
> Exception: STATUS_ACCESS_VIOLATION at eip=30064BF6

Have you run memory diagnostics?

Earnie

Earnie Boyd wrote, on 12/11/2008 8:07 AM:
>> $ cat sh.exe.stackdump
>> MSYS-1.0.11 Build:2008-08-25 23:40
>> Exception: STATUS_ACCESS_VIOLATION at eip=30064BF6
> Have you run memory diagnostics?

Do you mean hardware diagnostics? I am 99.99% sure this isn't a hardware 
problem, because I had the identical issue with msys on my last box, 
which had no parts in the common with the current box (and was a 
different Thinkpad model). I have run the POST RAM check with no 
problems; also no other software is behaving unusually.

The only other sort of debugging I've tried to do other than what's been 
reported to this list is run Dependency Walker, but I didn't see 
anything in there that I could understand to isolate the problem.

Adam

Adam Rosi-Kessel wrote, on 12/10/2008 8:14 AM:
> Earnie Boyd wrote, on 12/10/2008 7:41 AM:
>> You can check the change with
>> objdump -s msys-1.0.dll > objdump.out
>> Check the top of the objdump.out file, the first column should begin 
>> with 30xxxxxx where the xxxxxx is replaced with the rest of the address.
> 
> OK, I think it's all checking out now -- not sure why it wasn't before.
> 
> $ objdump -s /bin/msys-1.0.dll | head -5
> 
> C:/0/Downloads/msysCORE-1.0.11-20080826.tar/msysCORE-1.0.11-20080826/bin/msys-1.0.dll: 
>      file format pei-i386
> 
> Contents of section .text:
>   30001000 4e554c4c 00002573 20257300 90909090  NULL..%s %s.....

Are we at the end of the line on this issue? Should I file an official 
bug somewhere?

Adam

Adam Rosi-Kessel wrote:
> Adam Rosi-Kessel wrote, on 12/10/2008 8:14 AM:
>> Earnie Boyd wrote, on 12/10/2008 7:41 AM:
>>> You can check the change with
>>> objdump -s msys-1.0.dll > objdump.out
>>> Check the top of the objdump.out file, the first column should begin 
>>> with 30xxxxxx where the xxxxxx is replaced with the rest of the address.
>> OK, I think it's all checking out now -- not sure why it wasn't before.
>>
>> $ objdump -s /bin/msys-1.0.dll | head -5
>>
>> C:/0/Downloads/msysCORE-1.0.11-20080826.tar/msysCORE-1.0.11-20080826/bin/msys-1.0.dll: 
>>      file format pei-i386
>>
>> Contents of section .text:
>>   30001000 4e554c4c 00002573 20257300 90909090  NULL..%s %s.....
> 
> Are we at the end of the line on this issue?

I still have some ideas. You said Cygwin works for you, so maybe there 
is a clue in there. For instance, I seem to recall that Cygwin retries 5 
times whenever a fork call fails. It would be useful to implement that 
in MSYS, if it isn't already.

> Should I file an official bug somewhere?

Please do. The crash in MSYS is due to not properly checking for a NULL 
pointer, so there is definitively a bug in there.

You can create a bug report here:

MinGW Bugs
https://sourceforge.net/tracker/?group_id=2435&atid=102435

Choose "Add new artifact". Please make sure you are logged in first. You 
may have to create an SourceForge account if you don't already have one.

Thanks,

Cesar

On Monday 01 December 2008 03:01, Adam Rosi-Kessel wrote:
> > Cross-Hosted MinGW Build Tool
> > http://sourceforge.net/project/showfiles.php?group_id=2435&package_
> >id=12644
>
> Similar result with MinGW's script:
>
> gcc -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Werror -O2
> -fno-exceptions -s -o ar.exe arparse.o arlex.o ar.o not-ranlib.o
> arsup.o rename.o binemul.o emul_vanilla.o bucomm.o version.o
> filemode.o ../bfd/.libs/libbfd.a ../libiberty/libiberty.a
> arlex.o:arlex.c:(.text+0x0): multiple definition of `_main'
> arparse.o:arparse.c:(.text+0x0): first defined here
> ar.o:ar.c:(.text+0xeb0): multiple definition of `_main'
> arparse.o:arparse.c:(.text+0x0): first defined here
> ar.o:ar.c:(.text+0x25): undefined reference to `_yyparse'
> collect2: ld returned 1 exit status

Sorry for the late contribution to this thread.  This is reminiscent of 
the errors which may be seen, when building from a non-release quality 
tarball, without having flex or bison installed.

What version of binutils was this?

-- 

Regards,
Keith.

Keith Marshall wrote, on 1/3/2009 1:48 PM:
>>> Cross-Hosted MinGW Build Tool
>>> http://sourceforge.net/project/showfiles.php?group_id=2435&package_
>>> id=12644
>> Similar result with MinGW's script:
...
>> ar.o:ar.c:(.text+0x25): undefined reference to `_yyparse'
>> collect2: ld returned 1 exit status
> 
> Sorry for the late contribution to this thread.  This is reminiscent of 
> the errors which may be seen, when building from a non-release quality 
> tarball, without having flex or bison installed.
> 
> What version of binutils was this?

Are you talking about the tarball from which msys was built, or the 
tarball of the package I'm trying to build under msys? Neither flex nor 
bison is installed. I believe binutils is 2.18.50.20080625.

Adam Rosi-Kessel wrote:
> Keith Marshall wrote, on 1/3/2009 1:48 PM:
>>>> Cross-Hosted MinGW Build Tool
>>>> http://sourceforge.net/project/showfiles.php?group_id=2435&package_
>>>> id=12644
>>> Similar result with MinGW's script:
> ...
>>> ar.o:ar.c:(.text+0x25): undefined reference to `_yyparse'
>>> collect2: ld returned 1 exit status
>> Sorry for the late contribution to this thread.  This is reminiscent of 
>> the errors which may be seen, when building from a non-release quality 
>> tarball, without having flex or bison installed.
>>
>> What version of binutils was this?
> 
> Are you talking about the tarball from which msys was built, or the 
> tarball of the package I'm trying to build under msys? Neither flex nor 
> bison is installed. I believe binutils is 2.18.50.20080625.
> 

I believe this is the part were I suggested building a MinGW 
cross-compiler hosted on Cygwin, since MSYS was failing for you.

So, you should check which binutils version was used by the automated 
build script. It is probably stored in $HOME/packages/mingw-3.4.5 of 
your Cygwin installation.

Regards,
Cesar

Cesar Strauss wrote, on 1/3/2009 2:44 PM:
> Adam Rosi-Kessel wrote:
>> Keith Marshall wrote, on 1/3/2009 1:48 PM:
>>>>> Cross-Hosted MinGW Build Tool
>>>>> http://sourceforge.net/project/showfiles.php?group_id=2435&package_
>>>>> id=12644
>>>> Similar result with MinGW's script:
>> ...
>>>> ar.o:ar.c:(.text+0x25): undefined reference to `_yyparse'
>>>> collect2: ld returned 1 exit status
>>> Sorry for the late contribution to this thread.  This is reminiscent of 
>>> the errors which may be seen, when building from a non-release quality 
>>> tarball, without having flex or bison installed.
>>>
>>> What version of binutils was this?
>> Are you talking about the tarball from which msys was built, or the 
>> tarball of the package I'm trying to build under msys? Neither flex nor 
>> bison is installed. I believe binutils is 2.18.50.20080625.
>>
> 
> I believe this is the part were I suggested building a MinGW 
> cross-compiler hosted on Cygwin, since MSYS was failing for you.
> 
> So, you should check which binutils version was used by the automated 
> build script. It is probably stored in $HOME/packages/mingw-3.4.5 of 
> your Cygwin installation.

Installing flex and bison in cygwin does appear to fix the 
cross-compiling script. Unfortunately, the packages I'm trying to build 
don't cross-compile gracefully -- I've been working through issues one 
by one but may give up soon. I'm not getting any crashes or stack-dumps 
with cross-compiling; there are just lots of path and command-line 
switch issues that need to be fixed manually.

Adam

Cesar Strauss wrote:
> The crash is in the _reent_clib function  [...]

It turns out this particular function call in "fork_parent" is not doing 
anything useful, and was removed from the Cygwin sources a long time ago.

Please try the following:

http://downloads.sourceforge.net/sourceforge/mingw/MSYS-1.0.11-20090105-dll.tar.gz

Regards,
Cesar

Cesar Strauss wrote, on 1/5/2009 6:56 PM:
>> The crash is in the _reent_clib function  [...]
> It turns out this particular function call in "fork_parent" is not doing 
> anything useful, and was removed from the Cygwin sources a long time ago.
> Please try the following:
> http://downloads.sourceforge.net/sourceforge/mingw/MSYS-1.0.11-20090105-dll.tar.gz

Preliminary result is that this build (20090105) eliminates the problem 
entirely. I'll let you know if it recurs at all, but otherwise it seems 
to be solved. Thanks!

Adam

Adam Rosi-Kessel wrote:
> Cesar Strauss wrote, on 1/5/2009 6:56 PM:
>>> The crash is in the _reent_clib function  [...]
>> It turns out this particular function call in "fork_parent" is not doing 
>> anything useful, and was removed from the Cygwin sources a long time ago.
>> Please try the following:
>> http://downloads.sourceforge.net/sourceforge/mingw/MSYS-1.0.11-20090105-dll.tar.gz
> 
> Preliminary result is that this build (20090105) eliminates the problem 
> entirely. I'll let you know if it recurs at all, but otherwise it seems 
> to be solved. Thanks!
> 

Wonderful! Thanks for your patience, and welcome to MSYS.

Regards,
Cesar