RE: Problems with zsh 3.1.9 and cygwin

RE: Problems with zsh 3.1.9 and cygwin

[Andrej Borsenkow]

> >
> >       0 [main] zsh 18877 handle_exceptions: Exception:
> > STATUS_ACCESS_VIOLATION
> >     913 [main] zsh 18877 stackdump: Dumping stack trace to
> > zsh.exe.stackdump
> >
> > and the following stackdump:
>
> I understand, that it is of little help, but I can build and
> run current
> Zsh code (I do not remember, if I tried stock 3.1.9 - but it is very
> probable) in exactly the above configuration.

Sorry, I was wrong. It appeared, that I had outdated Cygwin already (I
have not seen any announcements so assumed there was nothing new).
Obviously, binutils have changed, so I get now exactly the same crash.
Damn ... I just downloaded Cygwin, downloaded updated ld.exe but no way.

-andrej

Problems under domain account on Win2k RE: Problems with zsh 3.1.9 and cygwin

[Andrej Borsenkow]

>
> > >
> > >       0 [main] zsh 18877 handle_exceptions: Exception:
> > > STATUS_ACCESS_VIOLATION
> > >     913 [main] zsh 18877 stackdump: Dumping stack trace to
> > > zsh.exe.stackdump
> > >
> > > and the following stackdump:
> >
> > I understand, that it is of little help, but I can build and
> > run current
> > Zsh code (I do not remember, if I tried stock 3.1.9 - but it is very
> > probable) in exactly the above configuration.
>
> Sorry, I was wrong. It appeared, that I had outdated Cygwin already (I
> have not seen any announcements so assumed there was nothing new).
> Obviously, binutils have changed, so I get now exactly the same crash.
> Damn ... I just downloaded Cygwin, downloaded updated ld.exe
> but no way.
>

This particular problem was due to tgetent() problem. Zsh tests, if
tgetent() accepts null pointer for buffer. Unfortunately, test always
succeeded, but running under gdb showed, that Zsh crashed in
tgetent(0,"cygwin").

But really weird was when I recompiled Zsh without TGETENT_ACCEPTS_NULL.
Now, Zsh correctly starts under local account but crashes under domain
account!!!

The problem is, that, as was already mentioned on cygwin list, gdb also
does not work under domain account. That means, that

- either I have working gdb and zsh and nothing to debug
- or both do not work and I have no way to debug

Usage of printf would be nice IF I had the slightest idea where it
crashes.

I'm running under Win2k professional with 128 bit security (hmm, may
this be a problem?). It is a member of NT4 domain; domain controller is
NT4SP6a.

-andrej

Re: Problems under domain account on Win2k RE: Problems with zsh 3.1.9 and cygwin

[Tomislav Goles]

/ "Andrej Borsenkow" <Andrej.Borsenkow@mow.siemens.ru> wrote:
> >
> > > >
> > > >       0 [main] zsh 18877 handle_exceptions: Exception:
> > > > STATUS_ACCESS_VIOLATION
> > > >     913 [main] zsh 18877 stackdump: Dumping stack trace to
> > > > zsh.exe.stackdump
> > > >
> > > > and the following stackdump:
> > >
> > > I understand, that it is of little help, but I can build and
> > > run current
> > > Zsh code (I do not remember, if I tried stock 3.1.9 - but it is very
> > > probable) in exactly the above configuration.
> >
> > Sorry, I was wrong. It appeared, that I had outdated Cygwin already (I
> > have not seen any announcements so assumed there was nothing new).
> > Obviously, binutils have changed, so I get now exactly the same crash.
> > Damn ... I just downloaded Cygwin, downloaded updated ld.exe
> > but no way.
> >
> 
> This particular problem was due to tgetent() problem. Zsh tests, if
> tgetent() accepts null pointer for buffer. Unfortunately, test always
> succeeded, but running under gdb showed, that Zsh crashed in
> tgetent(0,"cygwin").
> 
> But really weird was when I recompiled Zsh without TGETENT_ACCEPTS_NULL.
> Now, Zsh correctly starts under local account but crashes under domain
> account!!!
> 
> The problem is, that, as was already mentioned on cygwin list, gdb also
> does not work under domain account. That means, that
> 
> - either I have working gdb and zsh and nothing to debug
> - or both do not work and I have no way to debug
> 
> Usage of printf would be nice IF I had the slightest idea where it
> crashes.
> 
> I'm running under Win2k professional with 128 bit security (hmm, may
> this be a problem?). It is a member of NT4 domain; domain controller is
> NT4SP6a.
> 

I have been fighting with the same zsh error message since yesterday
(I yesterday installed cygwin on my W2K laptop so my guess is I have
up to date and clean installation since this was my first cygwin 
install on that machine).
My solution to the zsh problem was to install ncurses 5.1 and then
build zsh by making it link against libncurses library intstead 
of libtermcap. To do this I changed the order in zsh configure script
- search for ncurses in that script and move ncurses to first position
in the list "termcap curses ncurses". Then run configure and build.
After this zsh 3.0.8 seems to run fine. I don't have any idea whether
this has anything to do with the domain issue you are talking about
but figured it can't hurt to mention this.
Regards,
Tomislav

PATCH: configure.in: tgetent test does not work on Cygwin

[Andrej Borsenkow]

> >
> > This particular problem was due to tgetent() problem. Zsh tests, if
> > tgetent() accepts null pointer for buffer. Unfortunately, test always
> > succeeded, but running under gdb showed, that Zsh crashed in
> > tgetent(0,"cygwin").
> >


Test succeeded because after program crashes with STATUS_ACCESS_VIOLATION (as
our test program correctly did) we still get exit code 0. Here is the patch
that tries a workaround - it creates temporary file and tests for it after
program run. Any system without creat() ? I did not want to blindly check for
Cygwin because ncurses does not have this problem.

Tomislav, Mike - could you test it? It is O.K. here on both Unix and Cygwin
with the current unmodified CVS (I just got Sven's patch, so it is not current
anymore :-)

-andrej

Index: configure.in
===================================================================
RCS file: /cvsroot/zsh/zsh/configure.in,v
retrieving revision 1.13
diff -r1.13 configure.in
581a582,583
> dnl  Under Cygwin test program crashes but exit code is still 0. So,
> dnl  we test for a file that porgram should create
591a594
>       creat("conftest.tgetent", 0640);
596c599,603
<   zsh_cv_func_tgetent_accepts_null=yes,
---
>   if test -f conftest.tgetent; then
>      zsh_cv_func_tgetent_accepts_null=yes
>   else
>      zsh_cv_func_tgetent_accepts_null=no
>   fi,

Re: PATCH: configure.in: tgetent test does not work on Cygwin

[Peter Stephenson]

> > > This particular problem was due to tgetent() problem.
> 
> Test succeeded because after program crashes with STATUS_ACCESS_VIOLATION (as
> our test program correctly did) we still get exit code 0. Here is the patch
> that tries a workaround - it creates temporary file and tests for it after
> program run. Any system without creat() ? I did not want to blindly check for
> Cygwin because ncurses does not have this problem.

Here's a context diff.  I've moved the test for the file up, because
configure removes conftest* before the final test for the cache variable.
It seems to work on solaris, where the answer is `yes'.  The old version
was working on cygwin for Windows NT 4 sp 5, however, where the answer was
`no'.  How does Windows 2000 manage to arrange for a status 0?

Index: configure.in
===================================================================
RCS file: /cvsroot/zsh/zsh/configure.in,v
retrieving revision 1.13
diff -u -r1.13 configure.in
--- configure.in	2000/07/20 16:17:57	1.13
+++ configure.in	2000/07/26 09:03:23
@@ -579,6 +579,8 @@
 dnl  Check if tgetent accepts NULL (and will allocate its own termcap buffer)
 dnl  Some termcaps reportedly accept a zero buffer, but then dump core
 dnl  in tgetstr().
+dnl  Under Cygwin test program crashes but exit code is still 0. So,
+dnl  we test for a file that porgram should create
 AC_CACHE_CHECK(if tgetent accepts NULL,
 zsh_cv_func_tgetent_accepts_null,
 [AC_TRY_RUN([
@@ -589,11 +591,16 @@
 	char tbuf[1024], *u;
     	u = tbuf;
     	tgetstr("cl", &u);
+	creat("conftest.tgetent", 0640);
     }
     exit(!i || i == -1);
 }
 ],
-  zsh_cv_func_tgetent_accepts_null=yes,
+  if test -f conftest.tgetent; then
+    zsh_cv_func_tgetent_accepts_null=yes
+  else
+    zsh_cv_func_tgetent_accepts_null=no
+  fi,
   zsh_cv_func_tgetent_accepts_null=no,
   zsh_cv_func_tgetent_accepts_null=no)])
 if test $zsh_cv_func_tgetent_accepts_null = yes; then

-- 
Peter Stephenson <pws@cambridgesiliconradio.com>
Cambridge Silicon Radio, Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070

RE: PATCH: configure.in: tgetent test does not work on Cygwin

[Andrej Borsenkow]

>
> Here's a context diff.

Oops, sorry. I have yet to learn CVS. How can I set standard options for 'cvs
diff'?

> `no'.  How does Windows 2000 manage to arrange for a status 0?

I did compile and run zsh with Cygwin downloaded last month on Win2k; it
stopped to work just recently. So, it must be some recent change in run-time
support.

Have you tried on NT4 with the latest Cygwin?

-andrej

Re: PATCH: configure.in: tgetent test does not work on Cygwin

[Peter Stephenson]

Andrej:
> Have you tried on NT4 with the latest Cygwin?
I tried to upgrade and I'm now getting

E:\cygwin2\lib\gcc-lib\i686-pc-cygwin\2.95.2\cpp.exe: *** shared region is corrupted.  inited 15
      0 [main] ? 0 lock_pinfo_for_update: rc 0, pinfo_mutex 0xFFFFFFFF, Win32 error 6

with any non-trivial programme outside bash --- not just zsh, but cpp to.
Until I find out what's happening here, I can't do anything whatsoever with
cygwin.  This happens even with a re-install from scratch, but there are
probably some configuration files (or maybe registry entries?) I don't know
hiding somewhere.

-- 
Peter Stephenson <pws@cambridgesiliconradio.com>
Cambridge Silicon Radio, Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070

Re: PATCH: configure.in: tgetent test does not work on Cygwin

[Peter Stephenson]

> Andrej:
> > Have you tried on NT4 with the latest Cygwin?
> I tried to upgrade and I'm now getting
> 
> E:\cygwin2\lib\gcc-lib\i686-pc-cygwin\2.95.2\cpp.exe: *** shared region is co
> rrupted.  inited 15
>       0 [main] ? 0 lock_pinfo_for_update: rc 0, pinfo_mutex 0xFFFFFFFF, Win32
>  error 6
> 
> with any non-trivial programme outside bash --- not just zsh, but cpp to.

(that should be `too' again.  Ime geting to fenetik.)

That was an old cygwin1.dll I put in winnt/system32 to make it easier to
find --- there's a problem that if you start /usr/local/bin/zsh and
cygwin1.dll isn't in the path, it isn't found.  The easiest thing here was
to copy it to /usr/local/bin, where at least I'm likely to notice the
problem.

config.log doesn't report an error for the tgetent test programme, but the
test is correctly set to `no', so it looks like the same problem may be
here, too.  The shell recompiles from scratch and runs OK.

-- 
Peter Stephenson <pws@cambridgesiliconradio.com>
Cambridge Silicon Radio, Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070

RE: PATCH: configure.in: tgetent test does not work on Cygwin

[Andrej Borsenkow]

>
> That was an old cygwin1.dll I put in winnt/system32 to make it easier to
> find --- there's a problem that if you start /usr/local/bin/zsh and
> cygwin1.dll isn't in the path, it isn't found.

I noted, that current bash under Cygwin automatically prepends
/usr/bin:/usr/local/bin to PATH (BTW it also has cool default prompt as well
:-) May be, we could do the same for zsh. It looks, like Cygwin directory
structure has stabilized (at least, if you use setup, you do get /bin and
/usr/bin).

I start it via batch script that sets the same and tweaks CYGWIN variable.

-andrej

Re: PATCH: configure.in: tgetent test does not work on Cygwin

[Peter Stephenson]

> I noted, that current bash under Cygwin automatically prepends
> /usr/bin:/usr/local/bin to PATH (BTW it also has cool default prompt as well
> :-) May be, we could do the same for zsh. It looks, like Cygwin directory
> structure has stabilized (at least, if you use setup, you do get /bin and
> /usr/bin).

We can make $PATH more configurable, but I'm not sure I like the idea of
automatically adding something to an existing imported path, except in a
startup file.

Anyway, this doesn't fix the startup problem, of course, since the DLL is
searched for before we've touched the path.  I imagine bash works because
it's in the same directory.

-- 
Peter Stephenson <pws@cambridgesiliconradio.com>
Cambridge Silicon Radio, Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070

Re: PATCH: configure.in: tgetent test does not work on Cygwin

[Chmouel Boudjnah]

"Andrej Borsenkow" <Andrej.Borsenkow@mow.siemens.ru> writes:

> Oops, sorry. I have yet to learn CVS. How can I set standard options for 'cvs
> diff'?

-$ cat ~/.cvsrc 
cvs -q
diff -u
rdiff -u
-$

-- 
MandrakeSoft Inc                http://www.mandrakesoft.com
San-Francisco, CA USA                             --Chmouel