mingw-msys Mailing List for MinGW - Minimalist GNU for Windows

Keith Playford wrote:
> 
> I've just had a look at this. I don't suppose there's a similar
> pre-packaged odmp available for the make.exe in this release?
> 

No, unfortunately.  I'll see what I can do to get a debug version of 
make built, objdump needs the symbol data to put the source contents 
into the file.  You could do this yourself but that requires that you 
have an MSYS development environment including msysDVLPR and msysDTK 
available.

Earnie.

> > Well, the make is certainly running under control of a perl script and
> > the output of the build as a whole is redirected to a file for
> > capture. The crash points I've seen have not obviously been focused
> > around big links, though, just between compilations of
> > average-complexity C source files.

> That means you could put together some simple test scenario?

Unfortunately not, to date it has only happened in the context of an
overnight system build taking several hours. I think the only way
forward would be to start running regularly with an instrumented
version of make and hope to pick up more clues.

> [...]
>
> My opinions are the result of the numerious stack dumps I've analized
> pointing to the same code segments.  It's not heap corruption, it's more
> corruption of the pointer reference that is being freed.  The pointer
> value is zero which when freed gives a SIGSEGV error.

I guess the null pointer could be the direct or indirect result of an
earlier unchecked malloc failure, but it could equally be just about
anything.

> FWIW, I analyize the stackdumps using the .odmp file I upload with every
> release and the source code.

I've just had a look at this. I don't suppose there's a similar
pre-packaged odmp available for the make.exe in this release?

-- Keith

Keith Playford wrote:
> 
> Well, the make is certainly running under control of a perl script and
> the output of the build as a whole is redirected to a file for
> capture. The crash points I've seen have not obviously been focused
> around big links, though, just between compilations of
> average-complexity C source files.
> 

That means you could put together some simple test scenario?

> 
>>IMO, AFAICT, the bug is in the newlib malloc routines.  A call to
>>realloc that calls free and dies.
> 
> 
> Is the implication of the quote taken with the statement above that
> you think it may be symptomatic of a badly handled out-of-memory
> condition? Or just some other random heap corruption? OOM might tally
> with it's irregular appearance, but the build machine is pretty
> generously endowed with physical RAM.
> 

My opinions are the result of the numerious stack dumps I've analized 
pointing to the same code segments.  It's not heap corruption, it's more 
corruption of the pointer reference that is being freed.  The pointer 
value is zero which when freed gives a SIGSEGV error.

FWIW, I analyize the stackdumps using the .odmp file I upload with every 
release and the source code.

Earnie.

> [...]
>
> > I see there's already an intermittent make crash in the bug database:
> >
> >   685188: Msys 1.0.9 make crashes
> >
> > but it's not clear from comparing the stackdumps that they are
> > related.

> I think it's related.  Does your process do something similar to

> <quote>
> Date: 2003-05-26 12:04
> Sender: jwillemsen
> Logged In: YES
> user_id=585332

> We have investigated this further. The problem appears when
> linking large shared libraries (up to 70Mb in debug mode/6Mb
> release) from within a perl script. The perl script redirects
> stderr en stdout to a file and runs make. When running make
> directly from the command line it just works fine. We tested
> with multiple perl versions and with all versions the make
> gives the same problem.
> </quote>

Well, the make is certainly running under control of a perl script and
the output of the build as a whole is redirected to a file for
capture. The crash points I've seen have not obviously been focused
around big links, though, just between compilations of
average-complexity C source files.

> IMO, AFAICT, the bug is in the newlib malloc routines.  A call to
> realloc that calls free and dies.

Is the implication of the quote taken with the statement above that
you think it may be symptomatic of a badly handled out-of-memory
condition? Or just some other random heap corruption? OOM might tally
with it's irregular appearance, but the build machine is pretty
generously endowed with physical RAM.

Thanks,
Keith

Keith Playford wrote:
> Hi,
> 
> I've been experimenting with MSYS for building components that come
> out of the box with GNUmake-based build systems. I use MSYS standalone
> without a MinGW installation. For the most part this has been
> problem-free, except that we're beginning to see irregularly occurring
> access violations in make.exe in some builds. There seems to be no
> obvious pattern to the failures.
> 

I would like to know more privately about how you're using MSYS.

> Does anyone have any thoughts on this or can help decode the
> stackdump? Using MSYS-1.0.9-2003.04.18-1.exe, we get this in the build
> logs:
> 
>       0 [main] make 170 handle_exceptions: Exception: STATUS_ACCESS_VIOLATION
>     354 [main] make 170 open_stackdumpfile: Dumping stack trace to make.exe.stackdump
> 
> The stackdump is as follows:
> 
> Exception: STATUS_ACCESS_VIOLATION at eip=71098AED
> eax=00000000 ebx=00000000 ecx=00002EC8 edx=00000000 esi=0A034E08 edi=0A031F40
> ebp=0022ED14 esp=0022ECEC program=W:\j2me\tools\msys\bin\make.exe
> cs=001B ds=0023 es=0023 fs=0038 gs=0000 ss=0023
> Stack trace:
> Frame     Function  Args
> 0022ED14  71098AED  (710A5020, 0A031F48, 00000000, 00000000)
> 0022ED64  71098352  (710A5020, 0A031DB0, 00000190, 0041D88C)
> 0022ED94  71031183  (0A031DB0, 00000190, 0000002C, 00000008)
> 0022EDB4  00412A26  (0A031DB0, 00000190, 00000008, 71031310)
> 0022EE54  00403B6C  (00000000, 0A01CEE8, FFFFFFFF, 004129E6)
> 0022EE84  00404606  (0A01CEE8, 00000000, 0000003A, 71064F58)
> 0022EF24  00404041  (00000000, 0A01D0B8, FFFFFFFF, 710310CD)
> 0022EF54  00404606  (0A01D0B8, 00000000, 0000003A, 71031310)
> 0022EFF4  00404041  (00000000, 0A029398, FFFFFFFF, 004129E6)
> 0022F024  00404647  (0A029398, 0A0233B0, 0022F074, 0040C69F)
> 0022F074  0040C820  (0A0233B0, 00000000, 00000000, 004197BB)
> 0022F0A4  00402BE1  (0A0233B0, 00000000, 00000001, 00000000)
> 0022F0D4  00419367  (0A0233B0, 00000001, 0000786C, 000CD6D7)
> 0022F134  00418993  (0A0233B0, 00000005, 00000000, 00000000)
> 0022F174  0041774A  (0A0233B0, 00000004, 0022F1D4, 00419661)
> 0022F1C4  00418CDE  (0A0233B0, 00000003, 00000001, 00000000)
> End of stack trace (more stack frames may be present)
> 
> Output from uname -a on the machine where it failed:
> 
>   MINGW32_NT-4.0 BOB 1.0.9(0.46/3/2) 2003-04-18 10:51 i686 unknown
> 
> I see there's already an intermittent make crash in the bug database:
> 
>   685188: Msys 1.0.9 make crashes
> 
> but it's not clear from comparing the stackdumps that they are
> related.
> 

I think it's related.  Does your process do something similar to

<quote>
Date: 2003-05-26 12:04
Sender: jwillemsen
Logged In: YES
user_id=585332

We have investigated this further. The problem appears when
linking large shared libraries (up to 70Mb in debug mode/6Mb
release) from within a perl script. The perl script redirects
stderr en stdout to a file and runs make. When running make
directly from the command line it just works fine. We tested
with multiple perl versions and with all versions the make
gives the same problem.
</quote>

IMO, AFAICT, the bug is in the newlib malloc routines.  A call to 
realloc that calls free and dies.

Earnie.

Hi,

I've been experimenting with MSYS for building components that come
out of the box with GNUmake-based build systems. I use MSYS standalone
without a MinGW installation. For the most part this has been
problem-free, except that we're beginning to see irregularly occurring
access violations in make.exe in some builds. There seems to be no
obvious pattern to the failures.

Does anyone have any thoughts on this or can help decode the
stackdump? Using MSYS-1.0.9-2003.04.18-1.exe, we get this in the build
logs:

      0 [main] make 170 handle_exceptions: Exception: STATUS_ACCESS_VIOLATION
    354 [main] make 170 open_stackdumpfile: Dumping stack trace to make.exe.stackdump

The stackdump is as follows:

Exception: STATUS_ACCESS_VIOLATION at eip=71098AED
eax=00000000 ebx=00000000 ecx=00002EC8 edx=00000000 esi=0A034E08 edi=0A031F40
ebp=0022ED14 esp=0022ECEC program=W:\j2me\tools\msys\bin\make.exe
cs=001B ds=0023 es=0023 fs=0038 gs=0000 ss=0023
Stack trace:
Frame     Function  Args
0022ED14  71098AED  (710A5020, 0A031F48, 00000000, 00000000)
0022ED64  71098352  (710A5020, 0A031DB0, 00000190, 0041D88C)
0022ED94  71031183  (0A031DB0, 00000190, 0000002C, 00000008)
0022EDB4  00412A26  (0A031DB0, 00000190, 00000008, 71031310)
0022EE54  00403B6C  (00000000, 0A01CEE8, FFFFFFFF, 004129E6)
0022EE84  00404606  (0A01CEE8, 00000000, 0000003A, 71064F58)
0022EF24  00404041  (00000000, 0A01D0B8, FFFFFFFF, 710310CD)
0022EF54  00404606  (0A01D0B8, 00000000, 0000003A, 71031310)
0022EFF4  00404041  (00000000, 0A029398, FFFFFFFF, 004129E6)
0022F024  00404647  (0A029398, 0A0233B0, 0022F074, 0040C69F)
0022F074  0040C820  (0A0233B0, 00000000, 00000000, 004197BB)
0022F0A4  00402BE1  (0A0233B0, 00000000, 00000001, 00000000)
0022F0D4  00419367  (0A0233B0, 00000001, 0000786C, 000CD6D7)
0022F134  00418993  (0A0233B0, 00000005, 00000000, 00000000)
0022F174  0041774A  (0A0233B0, 00000004, 0022F1D4, 00419661)
0022F1C4  00418CDE  (0A0233B0, 00000003, 00000001, 00000000)
End of stack trace (more stack frames may be present)

Output from uname -a on the machine where it failed:

  MINGW32_NT-4.0 BOB 1.0.9(0.46/3/2) 2003-04-18 10:51 i686 unknown

I see there's already an intermittent make crash in the bug database:

  685188: Msys 1.0.9 make crashes

but it's not clear from comparing the stackdumps that they are
related.

-- Keith

In the developer's package,
vi /lib/gcc-lib/i686-pc-msys/2.95.3-1/include/sys/termios.h +48

The line
  #define CTRL(c'h')        ((ch)&0x1F)
gives
  ... /termios.h:48: badly punctuated parameter list in `#define'

Shouldn't it be
  #define CTRL(ch)        ((ch)&0x1F)

(Also, somehow my config scripts don't find <termio.h>/<termios.h>.
Is the #include search path nonstandard?)

--
 "They outlaw smoking and we fall back, they outlaw fast food, and we
 fall back, now they threaten our coffee; the line must be drawn here!"

Earnie Boyd wrote:
> -Fo/path/to/file isn't a rule that MSYS understands, yet.  Unfortunately
> you must also butt the file against the switch for it to find the
> argument.  I'll see what I can manage, probably something like -
> followed by F then start path transalation at char [3].
> 
> Yuck, yuck, yuck!!!!

Wouldn't that have the potential to break other programs that
have a -F<somepath>??  Or is the path translation a function
of the executable name??  I don't necessarily want this problem
"fixed" if it isn't the "right" thing to do.  Mo DeJong
sent a script that will work for my purposes.  I just wanted
to bring the problem to the attention of the community.  Perhaps
Mo's little script should be distributed with msys with a note 
in the readme file saying to use that script for these ugly
corner cases?


> 
> >
> > PS - you might ask why I don't just use the h:/dgl/tmp/hello.obj
> > syntax.  The answer is, I'm using the $(CURDIR) variable in make
> > and it returns /h/dgl/tmp for the current directory.
> >
> 
> What happens for you if you ``make --win32''?
It doesn't seem to help.  The following makefile seems to
output the same unix-like path with or without
the --win32 flag:

.PHONY: echodir

echodir:
	@echo $(CURDIR)


Thanks for the feedback!  When somebody decides upon an
official msys/mingw way to handle this issue, please
post it to the list.


Cheers...

                   Dave


PS - Here are the cl options:

                          C/C++ COMPILER OPTIONS

                              -OPTIMIZATION-

/O1 minimize space                       /Op[-] improve floating-pt
consistency
/O2 maximize speed                       /Os favor code space
/Oa assume no aliasing                   /Ot favor code speed
/Ob<n> inline expansion (default n=0)    /Ow assume cross-function
aliasing
/Od disable optimizations (default)      /Ox maximum opts. (/Ogityb1
/Gs)
/Og enable global optimization           /Oy[-] enable frame pointer
omission
/Oi enable intrinsic functions

                             -CODE GENERATION-

/G3 optimize for 80386                   /Gy separate functions for
linker
/G4 optimize for 80486                   /Ge force stack checking for
all funcs
/G5 optimize for Pentium                 /Gs[num] disable stack checking
calls
/G6 optimize for Pentium Pro             /Gh enable hook function call
/GB optimize for blended model (default) /GR[-] enable C++ RTTI
/Gd __cdecl calling convention           /GX[-] enable C++ EH (same as
/EHsc)
/Gr __fastcall calling convention        /Gi[-] enable incremental
compilation
/Gz __stdcall calling convention         /Gm[-] enable minimal rebuild
/GA optimize for Windows Application     /EHs enable synchronous C++ EH
/GD optimize for Windows DLL             /EHa enable asynchronous C++ EH
/Gf enable string pooling                /EHc extern "C" defaults to
nothrow
/GF enable read-only string pooling      /QIfdiv[-] enable Pentium FDIV
fix 
/GZ enable runtime debug checks          /QI0f[-] enable Pentium 0x0f
fix

                              -OUTPUT FILES-

/Fa[file] name assembly listing file     /Fo<file> name object file
/FA[sc] configure assembly listing       /Fp<file> name precompiled
header file
/Fd[file] name .PDB file                 /Fr[file] name source browser
file
/Fe<file> name executable file           /FR[file] name extended .SBR
file
/Fm[file] name map file

                              -PREPROCESSOR-

/C don't strip comments                  /FI<file> name forced include
file
/D<name>{=|#}<text> define macro         /U<name> remove predefined
macro
/E preprocess to stdout                  /u remove all predefined macros
/EP preprocess to stdout, no #line       /I<dir> add to include search
path
/P preprocess to file                    /X ignore "standard places"

                                -LANGUAGE-

/Zi enable debugging information         /Zl omit default library name
in .OBJ
/ZI enable Edit and Continue debug info  /Zg generate function
prototypes
/Z7 enable old-style debug info          /Zs syntax check only
/Zd line number debugging info only      /vd{0|1} disable/enable
vtordisp
/Zp[n] pack structs on n-byte boundary   /vm<x> type of pointers to
members
/Za disable extensions (implies /Op)     /noBool disable "bool" keyword
/Ze enable extensions (default)

                              -MISCELLANEOUS-

/?, /help print this help message        /V<string> set version string
/c compile only, no link                 /w disable all warnings
/H<num> max external name length         /W<n> set warning level
(default n=1)
/J default char type is unsigned         /WX treat warnings as errors
/nologo suppress copyright message       /Yc[file] create .PCH file
/Tc<source file> compile file as .c      /Yd put debug info in every
.OBJ
/Tp<source file> compile file as .cpp    /Yu[file] use .PCH file
/TC compile all files as .c              /YX[file] automatic .PCH
/TP compile all files as .cpp            /Zm<n> max memory alloc (% of
default)

                                 -LINKING-

/MD link with MSVCRT.LIB                 /MDd link with MSVCRTD.LIB
debug lib
/ML link with LIBC.LIB                   /MLd link with LIBCD.LIB debug
lib
/MT link with LIBCMT.LIB                 /MTd link with LIBCMTD.LIB
debug lib
/LD Create .DLL                          /F<num> set stack size
/LDd Create .DLL debug libary            /link [linker options and
libraries]

Dave Lawrence wrote:
> The visual c++ compiler has a flag -Fo<file> to name the object file.
> When I use msys/mingw to compile, it doesn't work for certain
> filenames.  For example:
> 
> $ cd /h/dgl/tmp
> $ cl -c -Fohello.obj hello.c
> works
> 

Great!

> $ cl -c -Fo../tmp/hello.obj hello.c
> works
> 

Great!

> $ cl -c -Fo/h/dgl/tmp/hello.obj hello.c
> fails with this error:
> fatal error C1083: Cannot open compiler generated file:
> '/h/dgl/tmp/hello.obj': No s
> uch file or directory
> 

-Fo/path/to/file isn't a rule that MSYS understands, yet.  Unfortunately 
you must also butt the file against the switch for it to find the 
argument.  I'll see what I can manage, probably something like - 
followed by F then start path transalation at char [3].

Yuck, yuck, yuck!!!!

> 
> PS - you might ask why I don't just use the h:/dgl/tmp/hello.obj
> syntax.  The answer is, I'm using the $(CURDIR) variable in make
> and it returns /h/dgl/tmp for the current directory.
> 

What happens for you if you ``make --win32''?

Earnie.

On Fri, 23 May 2003 15:26:53 -0400
Greg Chicares <chi...@mi...> wrote:

> 'cl' would be the msvc compiler. Looks like it doesn't
> understand posix pathnames. I've used some borland tools
> with gnu make by writing an auxiliary program that accepts
> gcc-like arguments and invokes the tool with the kind of
> arguments it requires--like filenames with backslashes.

I ran into problems like this under Msys+Mingw also. Cygwin
has a nice little util named cygpath that does the conversion,
but this feature is lacking in Msys.

The solution I came up with was the following little sh script
to do unix to win path name conversion.

# This script will convert a UNIX path to a Win32 native path
UPATH=$1
if test "$UPATH" = ""; then
    echo EMPTY
    exit 1
fi
#echo "INPUT IS \"$UPATH\"" >&2
if test -d $UPATH ; then
    cd $UPATH
    WPATH=`pwd -W`
else
    cd `dirname $UPATH`
    WPATH=`pwd -W`/`basename $UPATH`
fi
#echo "OUTPUT IS \"$WPATH\"" >&2
echo $WPATH
exit 0


cheers
Mo DeJong

Dave Lawrence wrote:
> 
> The visual c++ compiler has a flag -Fo<file> to name the object file.
> When I use msys/mingw to compile, it doesn't work for certain
> filenames.  For example:

If you're using mingw gcc, try '-o filename' instead of
'-Fo filename'. But these examples don't seem to use gcc.

> $ cl -c -Fo/h/dgl/tmp/hello.obj hello.c
> fails with this error:
> fatal error C1083: Cannot open compiler generated file:
> '/h/dgl/tmp/hello.obj': No s
> uch file or directory

'cl' would be the msvc compiler. Looks like it doesn't
understand posix pathnames. I've used some borland tools
with gnu make by writing an auxiliary program that accepts
gcc-like arguments and invokes the tool with the kind of
arguments it requires--like filenames with backslashes.

The visual c++ compiler has a flag -Fo<file> to name the object file.
When I use msys/mingw to compile, it doesn't work for certain
filenames.  For example:

$ cd /h/dgl/tmp
$ cl -c -Fohello.obj hello.c
works

$ cl -c -Fo../tmp/hello.obj hello.c
works

$ cl -c -Fo/h/dgl/tmp/hello.obj hello.c
fails with this error:
fatal error C1083: Cannot open compiler generated file:
'/h/dgl/tmp/hello.obj': No s
uch file or directory

$ cl -c -Fo../../../h/dgl/tmp/hello.obj hello.c
also fails.

$ cl -c -Fo/tmp/hello.obj hello.c
also fails.

$ cl -c -Fo/bin/hello.obj hello.c
also fails.

$ cl -c -Foh:/dgl/tmp/hello.obj hello.c
works

I'm using:
MSYS-1.0.8
MinGW-2.0.0-3

Thanks in advance for any help.

                                     Dave

PS - you might ask why I don't just use the h:/dgl/tmp/hello.obj
syntax.  The answer is, I'm using the $(CURDIR) variable in make
and it returns /h/dgl/tmp for the current directory.

When using msysDTk-1.0.1 / msysDVLPR-1.0.0-alpha-1, the
gcc 2.95.3-1 2002-05-17 is our own MSYS-specific build?

It's a little hard to verify, just from the --version;
whatever the standard format is, we ought to adopt it...



   66048 Fri May 17 10:34:06 2002 /bin/gcc.exe
  515584 Fri May 17 10:34:07 2002 /bin/ld.exe

d5409f3e4ca4087b1648a8d0e71c3d18 */bin/gcc.exe
7c47123e51d8b36aee9422e4c53c2cc6 */bin/ld.exe

2.95.3-1
GNU ld 2.11.90


The Developer's kit reports its status a little strangely:
$ gcc --version
2.95.3-1               <--  no "GNU gcc", no build date
$ gcc -dumpmachine
i686-pc-msys           <--  processor-maker-operatingsystem

compared with a conventional Win32-target gcc:
$ gcc --version
gcc.exe (GCC) 3.2 (mingw special 20020817-1)  <-- says "gcc", has build info
Copyright (C) 2002 Free Software Foundation, Inc.
$ gcc -dumpmachine
mingw32           <--  bare operating system ID


Which output is the preferred form?



-rwxr-xr-x      515584 May 17  2002 /bin/ld*
GNU ld 2.11.90     <-- Developer version is built differently
ld: supported targets: pe-i386 pei-i386 elf32-i386 elf32-little
elf32-big srec symbolsrec tekhex binary ihex
ld: supported emulations: i386pe
ld: emulation specific options:
i386pe:

-rwxr-xr-x      559104 Oct  8  2002 /mingw/bin/ld.exe
GNU ld version 2.13.90 20021005   <-- has "version" and date
c:\Dev-Cpp\bin\ld.exe: supported targets: pe-i386 pei-i386 elf32-i386
elf32-little elf32-big srec symbolsrec tekhex binary ihex
c:\Dev-Cpp\bin\ld.exe: supported emulations: i386pe
c:\Dev-Cpp\bin\ld.exe: emulation specific options:
i386pe:

(It shows the MinGW/MSYS status more clearly)



#!/bin/sh
echo 'msysinfo-1.2: Send this to the MSYS support list:'
echo '        (msysinfo-1.26-unstable)'
echo ; echo 'MSYS '$(uname -rvmp)"; targ="$(uname -s|cut -d_ -f1)
echo $(sh --version | grep -i '[0-9]\.[0-9]')"; ENV=$ENV"
echo -n $(make --version | grep -i '[0-9]\.[0-9]' | cut -db -f1) ''
echo $(make --version | grep -i 'Built')"; MAKE_MODE=$MAKE_MODE"
echo $(gcc --version | grep -i '[0-9]\.[0-9]')"; targ="$(uname -s|cut -d_ -f1)
ld --version | grep -i '[0-9]\.[0-9]'
ls -o --full-time /bin/msys*.dll | cut -b 25-
ls -o --full-time $(type -p make).exe | cut -b 25-
ls -o --full-time $(type -p gcc).exe | cut -b 25-
ls -o --full-time $(type -p ld).exe | cut -b 25-
echo "HOME=$HOME"
echo "Sysname=$(uname --sysname)  OSTYPE=$OSTYPE  TERM=$TERM"
echo "PATH=$PATH" | fold -w 64 ; echo "$ ls -t $PWD" ; ls -tFx
if [ "$1" = "all" ] || [ "$1" = "long" ] ; then
  echo;md5sum -b /bin/msys*.dll ; md5sum -b $(type -p make).exe
  md5sum -b $(type -p gcc).exe  ; md5sum -b $(type -p ld).exe
  echo ; cat /etc/fstab | grep '/'
  echo ; grep -a '%%%' /bin/msys*.dll
  echo ; set | fold -sw 64
  echo ; echo '$ msysinfo all >msysinfo.txt   will save this to a file'
fi

Thanx for the suggestion!  I've added 'cvs -z3' to my .cvsrc and
everything is working fine now.

Cheers!

Chris

> -----Original Message-----
> From: min...@li... [mailto:mingw-msys-
> ad...@li...] On Behalf Of Luke Dunstan
> Sent: Tuesday, May 13, 2003 10:29 PM
> To: ironhead; min...@li...
> Subject: Re: [Mingw-msys] problems with cvs.exe
> 
> 
> This is a know problem. Try using the "-z" compression option to work
> around
> the problem, e.g.:
> 
> cvs -z5 diff
> 
> Luke
> 
> ----- Original Message -----
> From: "ironhead" <iro...@ro...>
> To: <min...@li...>
> Sent: Wednesday, May 14, 2003 7:24 AM
> Subject: [Mingw-msys] problems with cvs.exe
> 
> 
> > Hey All,
> >
> > Currently I have the following defined CVSROOT and CVS_RSH defined
in my
> > .profile:
> >
> > CVS_RSH=ssh
> > CVSROOT=:ext:<userid>@<server>:<cvsroot>
> >
> > if I do a 'cvs diff', the cvs command runs, but never returns to the
> > command prompt.  If I do a 'cvs -d:ext:<userid>@<server>:<cvsroot>
diff'
> > the cvs command runs, and it returns to the command prompt fine.
> >
> > Anybody have any ideas?
> >
> > Thanx!
> >
> > Chris
> 
> 
> -------------------------------------------------------
> Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
> The only event dedicated to issues related to Linux enterprise
solutions
> www.enterpriselinuxforum.com
> 
> _______________________________________________
> Mingw-msys mailing list
> Min...@li...
> https://lists.sourceforge.net/lists/listinfo/mingw-msys

"x86Info: display x86 CPU diagnostics ...x86info probes the CPU
registers ... It can discover the contents of model-specific registers"

   http://gnuwin32.sourceforge.net/packages/x86info.htm
   http://sourceforge.net/project/showfiles.php?group_id=23617
   Feedback to  Dave Jones  davej AT suse.de


Sounds like this could be spliced into uname, or ported as a
'contrib' into MSYS/MinGW.  Can anyone suggest a roadmap?

--
 "You're only as original as the obscurity of your sources." - Picasso

This is a know problem. Try using the "-z" compression option to work around
the problem, e.g.:

cvs -z5 diff

Luke

----- Original Message ----- 
From: "ironhead" <iro...@ro...>
To: <min...@li...>
Sent: Wednesday, May 14, 2003 7:24 AM
Subject: [Mingw-msys] problems with cvs.exe


> Hey All,
>
> Currently I have the following defined CVSROOT and CVS_RSH defined in my
> .profile:
>
> CVS_RSH=ssh
> CVSROOT=:ext:<userid>@<server>:<cvsroot>
>
> if I do a 'cvs diff', the cvs command runs, but never returns to the
> command prompt.  If I do a 'cvs -d:ext:<userid>@<server>:<cvsroot> diff'
> the cvs command runs, and it returns to the command prompt fine.
>
> Anybody have any ideas?
>
> Thanx!
>
> Chris

ironhead wrote:


> Hey All,
> 
> Currently I have the following defined CVSROOT and CVS_RSH defined in my
> .profile:
> 
> CVS_RSH=ssh
> CVSROOT=:ext:<userid>@<server>:<cvsroot>
> 
> if I do a 'cvs diff', the cvs command runs, but never returns to the
> command prompt.  If I do a 'cvs -d:ext:<userid>@<server>:<cvsroot> diff'
> the cvs command runs, and it returns to the command prompt fine.
> 
> Anybody have any ideas?

I suspect that you run W*n9x. I have the same problem with any cvs commands,
like "cvs update", the operation completes, but cvs/ssh hangs.

If I use compression, -z3, for example, cvs hangs only once and then works fine.

I found that cvs hangs in src/client.c, in get_responses_and_close():
int
get_responses_and_close ()
{
    int errs = get_server_responses ();
[...]
    /* First we shut down TO_SERVER.  That tells the server that its input is
     * finished.  It then shuts down the buffer it is sending to us, at which
     * point our shut down of FROM_SERVER will complete.
     */

    status = buf_shutdown (to_server);
                                       ^^^^^^^^^ < no problem here.
[..]
    printf("get_responces_and_close: buf_shutdown(in)\n");
    status = buf_shutdown (from_server);
                                        ^^^^^^^^^   < hangs there.
    printf("get_responces_and_close: buf_shutdown(out)\n");
[...]
    return errs;
}

ssh hangs in clientloop.c:

/*
 * Implements the interactive session with the server.  This is called after
 * the user has been authenticated, and a command has been started on the
 * remote host.  If escape_char != SSH_ESCAPECHAR_NONE, it is the character
 * used as an escape character for terminating or suspending the session.
 */

int
client_loop(int have_pty, int escape_char_arg, int ssh2_chan_id)
{
[...]

 /* Main loop of the client for the interactive session mode. */
 while (!quit_pending) {
 ^^^^^^^^^^^^^^^^
ssh enters in this loop, but never returns.

[...]
}

 /* Return the exit status of the program. */
 debug("Exit status %d", exit_status);
 return exit_status;
}

I tried with cvs-1.11.5 and openssh-3.6.1p2, same behavior.
For me, only an old native w*n32 cvs/ssh works fine, unfortunately,
that ssh doesn't work within MSYS. It works only from a DOS
box, with CRLF authoritative conversion :(

Manu.

Quick update... it does it with specifying -d as well, just less often.

Chris

> -----Original Message-----
> From: ironhead [mailto:iro...@ro...]
> Sent: Tuesday, May 13, 2003 7:25 PM
> To: min...@li...
> Subject: problems with cvs.exe
> 
> Hey All,
> 
> Currently I have the following defined CVSROOT and CVS_RSH defined in
my
> .profile:
> 
> CVS_RSH=ssh
> CVSROOT=:ext:<userid>@<server>:<cvsroot>
> 
> if I do a 'cvs diff', the cvs command runs, but never returns to the
> command prompt.  If I do a 'cvs -d:ext:<userid>@<server>:<cvsroot>
diff'
> the cvs command runs, and it returns to the command prompt fine.
> 
> Anybody have any ideas?
> 
> Thanx!
> 
> Chris

Hey All,

Currently I have the following defined CVSROOT and CVS_RSH defined in my
.profile:

CVS_RSH=ssh
CVSROOT=:ext:<userid>@<server>:<cvsroot>

if I do a 'cvs diff', the cvs command runs, but never returns to the
command prompt.  If I do a 'cvs -d:ext:<userid>@<server>:<cvsroot> diff'
the cvs command runs, and it returns to the command prompt fine.

Anybody have any ideas?

Thanx!

Chris

msy...@sp... wrote:
>   eb>  The MAKE_MODE variable is special
> 
> Ah. Right.  I'll move some of the vars to consolidate things...
> Does this let you distinguish between most sane and broken configs?
> 

Most, yes.  One other problem that occurs are executables in the /bin 
directory that are not msys-1.0.dll dependent.  I have a function in the 
MSYS winsup/cygwin directory stored in ismsys.cc that identifies an 
msys-1.0.dll dependent binary from the PE headers.  If you wish, you may 
use that to create a simple program to report non-dependent PE binaries 
in the /bin directory and include it's use in this script.  Adding it to 
the MSYS winsup/utils directory will be a good thing.  Thank-you much 
for this work.

See question below.

> 
> 
> #!/bin/sh
> # This 'msysinfo' script belongs in the standard /bin directory.
> #
> echo 'msysinfo-1.2: Send this to the MSYS support list:'
> echo '        (msysinfo-1.23-unstable)'
> echo ; echo -n 'MSYS ' ; uname -rvmp
> echo $(sh --version | grep -i 'version')"; ENV=$ENV"
> echo -n $(make --version | grep -i 'version' | cut -db -f1) ''
> echo $(make --version | grep -i 'Built')"; MAKE_MODE=$MAKE_MODE"
> gcc --version | grep -i 'gcc'
> ld --version | grep -i 'version'
> ls -o --full-time /bin/msys*.dll | cut -b 25-
> ls -o --full-time $(type -p make).exe | cut -b 25-
> ls -o --full-time $(type -p gcc).exe | cut -b 25-
> ls -o --full-time $(type -p ld).exe | cut -b 25-
> echo "HOME=$HOME"
> echo "Sysname=$(uname --sysname)  OSTYPE=$OSTYPE  TERM=$TERM"
> echo "PATH=$PATH" | fold -w 62
> echo "$ ls -t $PWD" ; ls -tFx
> if [ "$1" = "all" ] || [ "$1" = "long" ] ; then
>   echo
>   md5sum -b /bin/msys*.dll
>   md5sum -b $(type -p make).exe
>   md5sum -b $(type -p gcc).exe
>   md5sum -b $(type -p ld).exe
>   echo ; cat /etc/fstab | grep '/'
>   echo ; grep -a '%%%' /bin/msys*.dll
>   echo ; set | fold -w 62

Should this be ``set | fold -sw 62'' so that we know the wrap is always 
at a whitespace boundary?

>   echo ; echo '$ msysinfo all >msysinfo.txt   will save this to a file'
> fi
> 

Earnie.

  eb>  The MAKE_MODE variable is special

Ah. Right.  I'll move some of the vars to consolidate things...
Does this let you distinguish between most sane and broken configs?



#!/bin/sh
# This 'msysinfo' script belongs in the standard /bin directory.
#
echo 'msysinfo-1.2: Send this to the MSYS support list:'
echo '        (msysinfo-1.23-unstable)'
echo ; echo -n 'MSYS ' ; uname -rvmp
echo $(sh --version | grep -i 'version')"; ENV=$ENV"
echo -n $(make --version | grep -i 'version' | cut -db -f1) ''
echo $(make --version | grep -i 'Built')"; MAKE_MODE=$MAKE_MODE"
gcc --version | grep -i 'gcc'
ld --version | grep -i 'version'
ls -o --full-time /bin/msys*.dll | cut -b 25-
ls -o --full-time $(type -p make).exe | cut -b 25-
ls -o --full-time $(type -p gcc).exe | cut -b 25-
ls -o --full-time $(type -p ld).exe | cut -b 25-
echo "HOME=$HOME"
echo "Sysname=$(uname --sysname)  OSTYPE=$OSTYPE  TERM=$TERM"
echo "PATH=$PATH" | fold -w 62
echo "$ ls -t $PWD" ; ls -tFx
if [ "$1" = "all" ] || [ "$1" = "long" ] ; then
  echo
  md5sum -b /bin/msys*.dll
  md5sum -b $(type -p make).exe
  md5sum -b $(type -p gcc).exe
  md5sum -b $(type -p ld).exe
  echo ; cat /etc/fstab | grep '/'
  echo ; grep -a '%%%' /bin/msys*.dll
  echo ; set | fold -w 62
  echo ; echo '$ msysinfo all >msysinfo.txt   will save this to a file'
fi

msy...@sp... wrote:
>   eb>  How about:
>   eb>  cat /etc/fstab
>   eb>  grep -a '%%%' /bin/msys-1.0.dll
> 
> 
> Okey-dokey.  Are there any other critical environment strings?
> 

Perhaps the output of ``set'' should be sufficient?  But, any that 
control GCC, binutils or make.  The MAKE_MODE variable is special 
purpose to the MSYS version of make.

Earnie.

> 
> 
> #!/bin/sh
> # This 'msysinfo' script belongs in the standard /bin directory.
> #
> echo 'msysinfo-1.2: Send this to the MSYS support list:'
> echo '        (msysinfo-1.22-unstable)'
> echo ; echo -n 'MSYS ' ; uname -rvmp
> sh --version | grep -i 'version'
> gcc --version | grep -i 'gcc'
> ld --version | grep -i 'version'
> echo -n $(make --version | grep -i 'version' | cut -db -f1) ''
> make --version | grep -i 'Built'
> ls -o --full-time /bin/msys*.dll | cut -b 26-
> md5sum -b /bin/msys*.dll
> ls -o --full-time $(type -p gcc).exe | cut -b 26-
> ls -o --full-time $(type -p ld).exe | cut -b 26-
> ls -o --full-time $(type -p make).exe | cut -b 26-
> echo "HOME=$HOME"
> echo -n "TERM=$TERM  ENV=$ENV  VIM=$VIM  OSTYPE=$OSTYPE  Sysname="
> uname --sysname
> #echo "PROCESSOR_IDENTIFIER=$PROCESSOR_IDENTIFIER"
> echo "PATH=$PATH" | fold -w 64
> echo "$ ls -t $PWD" ; ls -tF
> if [ "$1" = "all" ] || [ "$1" = "long" ] ; then
>   echo
>   cat /etc/fstab | grep '/'
>   echo 
>   grep -a '%%%' /bin/msys-1.0.dll
> fi
> 
> 
> -------------------------------------------------------
> Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
> The only event dedicated to issues related to Linux enterprise solutions
> www.enterpriselinuxforum.com
> 
> _______________________________________________
> Mingw-msys mailing list
> Min...@li...
> https://lists.sourceforge.net/lists/listinfo/mingw-msys
> 

  eb>  How about:
  eb>  cat /etc/fstab
  eb>  grep -a '%%%' /bin/msys-1.0.dll


Okey-dokey.  Are there any other critical environment strings?



#!/bin/sh
# This 'msysinfo' script belongs in the standard /bin directory.
#
echo 'msysinfo-1.2: Send this to the MSYS support list:'
echo '        (msysinfo-1.22-unstable)'
echo ; echo -n 'MSYS ' ; uname -rvmp
sh --version | grep -i 'version'
gcc --version | grep -i 'gcc'
ld --version | grep -i 'version'
echo -n $(make --version | grep -i 'version' | cut -db -f1) ''
make --version | grep -i 'Built'
ls -o --full-time /bin/msys*.dll | cut -b 26-
md5sum -b /bin/msys*.dll
ls -o --full-time $(type -p gcc).exe | cut -b 26-
ls -o --full-time $(type -p ld).exe | cut -b 26-
ls -o --full-time $(type -p make).exe | cut -b 26-
echo "HOME=$HOME"
echo -n "TERM=$TERM  ENV=$ENV  VIM=$VIM  OSTYPE=$OSTYPE  Sysname="
uname --sysname
#echo "PROCESSOR_IDENTIFIER=$PROCESSOR_IDENTIFIER"
echo "PATH=$PATH" | fold -w 64
echo "$ ls -t $PWD" ; ls -tF
if [ "$1" = "all" ] || [ "$1" = "long" ] ; then
  echo
  cat /etc/fstab | grep '/'
  echo 
  grep -a '%%%' /bin/msys-1.0.dll
fi

msy...@sp... wrote:
> Any other kitchen-sink stuff that ought to be put in here?
> 

Thanks, I like this.

How about:

cat /etc/fstab
grep -a '%%%' /bin/msys-1.0.dll

Earnie.

> 
> #!/bin/sh
> # This 'msysinfo' script belongs in the standard /bin directory.
> #
> echo 'msysinfo-1.2: Send this to the MSYS support list:'
> echo
> sh --version | grep -i 'version'
> gcc --version | grep -i 'gcc'
> ld --version | grep -i 'version'
> make --version | grep -i 'version'
> make --version | grep -i 'Built'
> md5sum -b /bin/msys*.dll
> ls -o --full-time /bin/msys*.dll | cut -b 26-
> ls -o --full-time $(type -p gcc).exe | cut -b 26-
> ls -o --full-time $(type -p ld).exe | cut -b 26-
> ls -o --full-time $(type -p make).exe | cut -b 26-
> echo
> echo HOME=$HOME
> echo "OS=$OS  OSTYPE=$OSTYPE  TERM=$TERM  ENV=$ENV  VIM=$VIM"
> echo PROCESSOR_IDENTIFIER=$PROCESSOR_IDENTIFIER
> echo PATH=$PATH | fold -w 64
> echo "$ ls -t $PWD"
> ls -tF
>