The road to 1.3.11 -- please try the latest snapshot

The road to 1.3.11 -- please try the latest snapshot

[Christopher Faylor]

I'm close to releasing cygwin 1.3.11 but I need feedback on the current
state of cygwin.  So, please try a snapshot at:

  http://cygwin.com/snapshots/

To install a snapshot:

  1) Download the latest cygwin-20020???.dll.bz2 file from the above
     web page into a temporary directory.

  2) bunzip2 cygwin-20020???.dll.bz2

  3) copy c:\cygwin\bin\cygwin1.dll c:\cygwin\bin\cygwin1.dll.saf

  4) copy cygwin-20020???.dll c:\cygwin\bin\cygwin1.dll

Obviously, you have to replace the 'c:\cygwin\bin' with the ms-dos path
name of your /bin directory.  You also *must* use Windows tools (e.g.,
"copy" or GUI "drag and drop") to copy the DLL to its new home since you
can't easily overwrite a busy DLL.

Reports of success or failure to the list, please.

AFAIK, there are still two things left to do prior to release 1) fix the
gettimeofday problem and 2) complete the review and possible
incorporation of some outstanding pthreads patches.

If there are other outstanding patches that need review please report
them here.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: The road to 1.3.11 -- please try the latest snapshot

[Pavel Tsekov]

CF> Reports of success or failure to the list, please.

First of all I decided to try the new /proc filesystem - here are some
things I have noticed and haven't seen them reported to the list so
far (or I missed them):

1. Under /proc and /proc/registry you can "cd" to unexisting directories.

paveltz@MORDOR ~
$ cd /proc/not_existing_dir

paveltz@MORDOR /proc/not_existing_dir
$ ls -l
ls: .: Not a directory

paveltz@MORDOR /proc/not_existing_dir

Now if tou type "cd .." you get:

paveltz@MORDOR /proc/non_existing_dir
$ cd ..

paveltz@MORDOR /proc/non_existing_dir/..
$ ls
104   140   1796  loadavg  registry  uptime
1144  1428  328   meminfo  stat      version

paveltz@MORDOR /proc/non_existing_dir/..
$ cd ..

paveltz@MORDOR /proc/non_existing_dir/../..
$ ls
bin         cygwin.ico  home  sbin  test_mds_7.bpr  usr
cygwin.bat  etc         lib   sys   tmp             var

2. Deleting a directory under /proc/registry/ takes
enormous time if this directory has subdirectories. I tried to
trace with strace since first I thought that some kind of infinite
loop causes this behaviour, but then it turned out that "rm" is actually
working - it just takes too much time to complete ... Most of the time
is spent in the cygwin internal path conversion routines, trying to
convert the POSIX path representation of the registry key/data into
Win32 path name.

Yes, I know this is read-only file system :)


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

The road to 1.3.11 -- please try the latest snapshot

[David Starks-Browning]

On Wednesday 29 May 02, Christopher Faylor writes:
> I'm close to releasing cygwin 1.3.11 but I need feedback on the current
> state of cygwin.  So, please try a snapshot at:
> 
>   http://cygwin.com/snapshots/
> 
> To install a snapshot:
> 
>   1) Download the latest cygwin-20020???.dll.bz2 file from the above
>      web page into a temporary directory.
> 
>   2) bunzip2 cygwin-20020???.dll.bz2
> 
>   3) copy c:\cygwin\bin\cygwin1.dll c:\cygwin\bin\cygwin1.dll.saf
> 
>   4) copy cygwin-20020???.dll c:\cygwin\bin\cygwin1.dll

On NT4 with CYGWIN=ntsec, I found it necessary to right-click on
c:\cygwin\bin\cygwin1.dll in explorer, properties, permissions,
and grant read-access to everyone.  Before I did that, I got
"application failed to initialize" error pop-up whenever I tried to
invoke any Cygwin application.

It might not happen to everyone, and it has come up on the list
before.  But I thought it worth mentioning, in case others encounter
this and would otherwise be quite confused.

Beyond that, with this snapshot, I have no trouble doing the things I
normally do on NT4.  (inetd, sshd, xemacs, rsync)

Thanks,
David


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: The road to 1.3.11 -- please try the latest snapshot

[Gerrit P. Haase]

Hallo Christopher,

Am Donnerstag, 30. Mai 2002 um 05:22 schriebst du:

> I'm close to releasing cygwin 1.3.11 but I need feedback on the current
> state of cygwin.  So, please try a snapshot at:

>   http://cygwin.com/snapshots/

I just finished a build of the upcoming perl-5.8 release candidate.
AFAICT no problems with the snapshot dll (importlib & headers also installed).

Gerrit
-- 
=^..^=


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: The road to 1.3.11 -- please try the latest snapshot

[Alan Dobkin]

[-- Attachment #1: Type: text/plain, Size: 417 bytes --]

With this snapshot, if I cd to a /proc/{PID} and run 
less * or more *, I get "Segmentation fault (core dumped)".  
The two stackdump files are attached.

Alan

--On Wednesday, May 29, 2002 11:22 PM -0400 Christopher Faylor 
<cgf-cygwig@cygwin.com> wrote:

> I'm close to releasing cygwin 1.3.11 but I need feedback on 
> the current state of cygwin.  So, please try a snapshot at:
> 
>   http://cygwin.com/snapshots/

[-- Attachment #2: less.exe.stackdump --]
[-- Type: application/octet-stream, Size: 1323 bytes --]

Exception: STATUS_ACCESS_VIOLATION at eip=61060F99
eax=20240000 ebx=00000001 ecx=610AB9D0 edx=00000000 esi=615F2F44 edi=615F2F44
ebp=0022FC54 esp=0022FC54 program=D:\cygwin\bin\less.exe
cs=001B ds=0023 es=0023 fs=0038 gs=0000 ss=0023
Stack trace:
Frame     Function  Args
0022FC54  61060F99  (00000001, 00000000, 615F2F44, 0022FCB4)
0022FC74  6101F3D4  (615F2F44, 00000001, 0022FCC4, 6106BE79)
0022FCA4  6102CF0A  (615F2F44, 00000001, 00000000, 00000000)
0022FD04  61069F93  (00000004, 00000001, 00000000, 00000000)
0022FD24  6106A06B  (00000004, 00000001, 00000000, 00000000)
0022FD44  610941C6  (00000004, 00000001, 00000000, 00409261)
0022FD64  0040332A  (00000004, 00000000, 00000000, 00000000)
0022FDD4  004088CD  (00000004, 00000000, 0022FE20, 00407712)
0022FE24  00407941  (10020FF0, 10021308, 0000000D, 004082B7)
0022FE54  00407C7E  (00000000, 00000001, 00000001, 00414749)
0022FE74  00407CCA  (00000001, 004082A1, 0022FEB4, 0040134F)
0022FE94  00407C02  (00000004, 610A93F0, 0000000D, 00000001)
0022FEB4  00401405  (FFFFFFFF, 615F0F44, 10020278, 00000000)
0022FF10  61005426  (00000000, 00000000, 0A0176E0, 8144FC88)
0022FF40  6100571A  (00401108, 0A0176E0, 811023E0, 8046CB60)
0022FF60  61005759  (00000000, 00000000, 81102570, 00000005)
End of stack trace (more stack frames may be present)

[-- Attachment #3: more.exe.stackdump --]
[-- Type: application/octet-stream, Size: 1323 bytes --]

Exception: STATUS_ACCESS_VIOLATION at eip=61060F99
eax=20270000 ebx=00000000 ecx=610AB9D0 edx=00000000 esi=615F12F4 edi=615F12F4
ebp=0022FBC4 esp=0022FBC4 program=D:\cygwin\bin\more.exe
cs=001B ds=0023 es=0023 fs=0038 gs=0000 ss=0023
Stack trace:
Frame     Function  Args
0022FBC4  61060F99  (00000000, 00000000, 615F12F4, 610685A5)
0022FBE4  6101F3D4  (615F12F4, 00000001, 0000000D, 3710F5FB)
0022FC14  6102CF0A  (615F12F4, 00000000, 00000000, 00000001)
0022FC74  61069F93  (00000003, 00000000, 00000000, 00000001)
0022FC94  6106A06B  (00000003, 00000000, 00000001, 3710F5FB)
0022FCB4  610A0CB0  (610A9028, 00000003, 00000000, 00000001)
0022FCE4  610A0060  (1005D0BC, 00000000, 00000001, 615F13D8)
0022FD64  61093AB0  (1005D0BC, 00000000, 00000000, 610934D0)
0022FD94  00401EE6  (1005D0BC, 615F1C24, 0022FDD4, 6102B97F)
0022FE14  00401E32  (615F1C24, 0022FE90, 0040760C, 004012A0)
0022FEB4  004016D1  (0000000D, 615F0F44, 10050278, 00000000)
0022FF10  61005426  (00000000, 00000000, 0A0176E0, 804A2615)
0022FF40  6100571A  (004011DC, 0A0176E0, 811EB020, 00000246)
0022FF60  61005759  (00000000, 00000000, 811EB1B0, 00000005)
0022FF90  00405A47  (004011DC, FFFFFFFF, 80430D77, 00000000)
0022FFC0  0040103D  (0A0176E0, 0A0132B0, 7FFDF000, 00000000)
End of stack trace (more stack frames may be present)

[-- Attachment #4: Type: text/plain, Size: 214 bytes --]

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: The road to 1.3.11 -- please try the latest snapshot

[Conrad Scott]

Generally, the latest releases have been fine for me (CVS HEAD on a w2k
box). I'm running the latest beta of XEmacs compiled under cygwin as well as
various other tools for daily use.

The only strangeness I've noticed has been in opening /proc with dired in
XEmacs. In the current (as this email) CVS HEAD version of cygwin, XEmacs
shows all the entries in /proc but gives me the error "No file on this line"
if I try to open any of them. If I explicitly visit (via C-x C-f) one of the
files in /proc, /proc/uptime for example, it opens but I get an empty file.
Also the /proc/registry part can be navigated by trying to explicitly visit
files in it but again these are always empty.

All these things work fine for me using standard utilities from within the
shell.

I could try and do some tracing if that would help.

// Conrad




--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: The road to 1.3.11 -- please try the latest snapshot

[Conrad Scott]

"Conrad Scott" <Conrad.Scott@dsl.pipex.com> wrote
> The only strangeness I've noticed has been in opening /proc with dired in
> XEmacs. In the current (as this email) CVS HEAD version of cygwin,
> XEmacs shows all the entries in /proc but gives me the error "No file on
> this line" if I try to open any of them.

Okay: red face time: dired is broken in xemacs 21.5-b6 for *everything*, and
so it's *nothing* to do with /proc. The other problem about all the files
opening
as empty might be an issue but I'm busy building a more stable version of
XEmacs to test it.

Sorry for the false alert.

// Conrad



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: The road to 1.3.11 -- please try the latest snapshot

[Christopher Faylor]

On Sun, Jun 02, 2002 at 01:09:37AM +0100, Conrad Scott wrote:
>"Conrad Scott" <Conrad.Scott@dsl.pipex.com> wrote
>> The only strangeness I've noticed has been in opening /proc with dired in
>> XEmacs. In the current (as this email) CVS HEAD version of cygwin,
>> XEmacs shows all the entries in /proc but gives me the error "No file on
>> this line" if I try to open any of them.
>
>Okay: red face time: dired is broken in xemacs 21.5-b6 for *everything*, and
>so it's *nothing* to do with /proc. The other problem about all the files
>opening
>as empty might be an issue but I'm busy building a more stable version of
>XEmacs to test it.
>
>Sorry for the false alert.

Don't worry about it.  I looked into this and found some problems with
the stat() code for virtual devices (cygdrive, proc), so, even if this
doesn't pan out, there was benefit.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: The road to 1.3.11 -- please try the latest snapshot

[Conrad Scott]

"Christopher Faylor" <cgf@redhat.com> wrote:
> >"Conrad Scott" <Conrad.Scott@dsl.pipex.com> wrote
> >Okay: red face time: dired is broken in xemacs 21.5-b6 for *everything*,
> >and so it's *nothing* to do with /proc. The other problem about all the
files
> >opening as empty might be an issue but I'm busy building a more stable
> >version of XEmacs to test it.
> >
> >Sorry for the false alert.
>
> Don't worry about it.  I looked into this and found some problems with
> the stat() code for virtual devices (cygdrive, proc), so, even if this
> doesn't pan out, there was benefit.

I'm glad that I didn't waste your time.

I've now got a copy of XEmacs 21.4.8 (a reasonably stable version) compiled
under cygwin and I'm getting strange results in /proc that are confusing me
(it must be time for bed).

One thing that seems reasonably clear (and maybe you've just fixed this), is
that XEmacs seems to think that any non-existent file inside the /proc/<pid>
directories is itself a directory. (How it can think that of a non-existent
file I don't know.) So opening /proc/<pid>/foo gives dired error messages
from XEmacs, i.e. it thinks that foo is a directory.

Anyhow, definitely time for bed, so goodnight everyone (wherever the sun may
be for you).

// Conrad



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: The road to 1.3.11 -- please try the latest snapshot

[Christopher Faylor]

On Sun, Jun 02, 2002 at 03:33:02AM +0100, Conrad Scott wrote:
>One thing that seems reasonably clear (and maybe you've just fixed this), is
>that XEmacs seems to think that any non-existent file inside the /proc/<pid>
>directories is itself a directory. (How it can think that of a non-existent
>file I don't know.) So opening /proc/<pid>/foo gives dired error messages
>from XEmacs, i.e. it thinks that foo is a directory.

Nope, I didn't fix this.  You can see the same behavior with ls -l
/proc/<pid>/foo .  I'll look into it.

(Unless ChrisJ beats me to it)

Thanks,
cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: The road to 1.3.11 -- please try the latest snapshot

[Chris January]

> >One thing that seems reasonably clear (and maybe you've just fixed this),
is
> >that XEmacs seems to think that any non-existent file inside the
/proc/<pid>
> >directories is itself a directory. (How it can think that of a
non-existent
> >file I don't know.) So opening /proc/<pid>/foo gives dired error messages
> >from XEmacs, i.e. it thinks that foo is a directory.
>
> Nope, I didn't fix this.  You can see the same behavior with ls -l
> /proc/<pid>/foo .  I'll look into it.
>
> (Unless ChrisJ beats me to it)
There's a line that went missing in fhandler_process.cc that causes the
empty file problem.

Chris



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: The road to 1.3.11 -- please try the latest snapshot

[Pavel Tsekov]

While trying to debug the slowdown which happens when doing a "rm -rf"
on a directory under /proc/registry/ I noticed the following thing..

My working directory is a directory under the proc hierarchy - in this
case it was /proc/registry/HKEY_CLASSES_ROOT. If I start gdb in this
directory and start debugging, the debug session thinks that the
current directory is the last directory I was in, before I've changed
the cwd to /proc/something. The same for strace.


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re[2]: The road to 1.3.11 -- please try the latest snapshot

[Pavel Tsekov]

Hello Christopher,

Saturday, June 01, 2002, 4:48:19 AM, you wrote:

[snip]

>>2. Deleting a directory under /proc/registry/ takes
>>enormous time if this directory has subdirectories. I tried to
>>trace with strace since first I thought that some kind of infinite
>>loop causes this behaviour, but then it turned out that "rm" is actually
>>working - it just takes too much time to complete ... Most of the time
>>is spent in the cygwin internal path conversion routines, trying to
>>convert the POSIX path representation of the registry key/data into
>>Win32 path name.
>>
>>Yes, I know this is read-only file system :)

CF> I didn't look at this one.  Maybe Chris J will have some insight.

Here is something else I want to share - it may be connected to the
above problem, though I think its not (or not entirely).

Anyone who wants to experience it can try this:
ls -l /proc/registry/HKEY_CLASSES_ROOT

The point is to select a key (directory) with many entries under it.

This takes an enormous time to complete - I've debugged the problem
and I think I've found the culprit though I'm not sure about the
solution. The problem lies in fhandler_registry::exists - this is
called by fhandler_registry::fstat, which is called by stat_worker.
ls -l uses lstat call to gather various information about the directory
components it processes - this is why the problem would show only if one
passes the -l option and not otherwise.

So, fhandler_registry::exists() will call RegEnumKeyEx until it exausts
all entries in a given directory, hits an error or it finds the entry it is
looking for... The whole search is done for every single entry from the
beginning... So consider that you have 3000+ entries in HKEY_CLASSES_ROOT
(as on my machine)...

Ok now - there is this comment in at the start
fhandler_registry::exists().. Could someone sched more light (Chris J
maybe :) ) why is this necessary ? Any links pointers would be
appreciated... I havent searched too hard the MSDN but there doesnt
seem to be too much info on the securiy of the registry :(

Here is the comment I refer to:

/* Returns 0 if path doesn't exist, >0 if path is a directory,
 * <0 if path is a file.
 *
 * We open the last key but one and then enum it's sub-keys and values to see if
 the
 * final component is there. This gets round the problem of not having security
access
 * to the final key in the path.
 */


So if we could avoid the RegEnumEntryEx thing i.e. just use
RegOpenKeyEx this would speed up the process very much.


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Re[2]: The road to 1.3.11 -- please try the latest snapshot

[Chris January]

> Ok now - there is this comment in at the start
> fhandler_registry::exists().. Could someone sched more light (Chris J
> maybe :) ) why is this necessary ? Any links pointers would be
> appreciated... I havent searched too hard the MSDN but there doesnt
> seem to be too much info on the securiy of the registry :(
>
> Here is the comment I refer to:
>
> /* Returns 0 if path doesn't exist, >0 if path is a directory,
>  * <0 if path is a file.
>  *
>  * We open the last key but one and then enum it's sub-keys and values to
see if
>  the
>  * final component is there. This gets round the problem of not having
security
> access
>  * to the final key in the path.
>  */
>
>
> So if we could avoid the RegEnumEntryEx thing i.e. just use
> RegOpenKeyEx this would speed up the process very much.
You're right, it would speed things up considerably.
The reason I did things that way is because a key, for which you have enum
permissions, may have a subkey for which you have no permissions at all (and
so would fail on RegOpenKeyEx).
In retrospect, the correct implementation is to try RegOpenKeyEx first, then
try the enum method if and only if RegOpenKeyEx fails with
ERROR_ACCESS_DENIED. I will try to make a patch for this as soon as a I have
a free minute (not easy at present). Alternatively feel free to submit your
own patch once your copyright assignment has been received by Red Hat.
Please note I haven't looked at your patch for unlink or rmdir and won't do
so until your assignment has been received. That way I can generate my own
patch with the same functionality if need be.

Regards
Chris



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/