Picon
Favicon

cygstart patch

I found a small bug and added a feature to the cygstart utility, which is part of the cygutils package.  The
feature that I added removes the limit on the length of the command line arguments passed to the target
application, which was previously limited to MAX_PATH.  The bug I fixed was in regard to freeing the
variable "args" instead of tyring to free "workDir" twice.  A patch and change log follow below.  As this is
my first contribution, please correct me if I did something incorrectly.

-Anthony

Change Log

2005-03-02  Anthony DeRosa  <Anthony dot DeRosa dot 1 at navy dot mil>

* cygstart.c (main): removed limit on the length of command line arguments passed to the target application

* cygstart.c (main): fixed typo that freed the variable "workDir" twice instead of freeing "args"

Patch

--- ../cygutils-1.2.6/src/cygstart/cygstart.c	2002-03-16 00:49:44.000000000 -0500
+++ src/cygstart/cygstart.c	2005-03-02 09:16:00.383625000 -0500
 <at>  <at>  -340,14 +340,18  <at>  <at>  int main(int argc, const char **argv)

     /* Retrieve any arguments */
     if (rest && *rest) {
-        if ((args = (char *) malloc(MAX_PATH+1)) == NULL) {
+        if ((args = (char *) malloc(strlen(*rest)+1)) == NULL) {
             fprintf(stderr, "%s: memory allocation error\n", argv[0]);
             exit(1);
-        }
-        strncpy(args, *rest, MAX_PATH);
(Continue reading)

Christopher Faylor | 2 Mar 2005 16:56
Favicon

Re: cygstart patch

On Wed, Mar 02, 2005 at 10:47:40AM -0500, Derosa, Anthony  CIV NAVAIR 2035, 2, 205/214 wrote:
>I found a small bug and added a feature to the cygstart utility, which
>is part of the cygutils package.  The feature that I added removes the
>limit on the length of the command line arguments passed to the target
>application, which was previously limited to MAX_PATH.  The bug I fixed
>was in regard to freeing the variable "args" instead of tyring to free
>"workDir" twice.  A patch and change log follow below.  As this is my
>first contribution, please correct me if I did something incorrectly.

AFAICT, the patch looks fine but this mailing list is for patches to the
cygwin DLL.

Please send your patch to the cygwin mailing list.

cgf

Pierre A. Humblet | 4 Mar 2005 05:36
Picon

[Patch]: fhandler_socket::ioctl

This patch avoids the unnecessary creation of the win thread in window.cc
It fails to create the invisible window (error 5) when running exim
as a service under a privileged non SYSTEM account (XP home, SP 2).

Pierre

2005-03-04  Pierre Humblet <pierre.humblet <at> ieee.org>

	* fhandler_socket.cc (fhandler_socket::ioctl): Only cancel 
 	 WSAAsyncSelect when async mode is on.

Index: fhandler_socket.cc
===================================================================
RCS file: /cvs/src/src/winsup/cygwin/fhandler_socket.cc,v
retrieving revision 1.150
diff -u -p -r1.150 fhandler_socket.cc
--- fhandler_socket.cc  28 Feb 2005 13:11:49 -0000      1.150
+++ fhandler_socket.cc  4 Mar 2005 00:32:57 -0000
 <at>  <at>  -1594,7 +1594,7  <at>  <at>  fhandler_socket::ioctl (unsigned int cmd
       /* We must cancel WSAAsyncSelect (if any) before setting socket to
        * blocking mode
        */
-      if (cmd == FIONBIO && *(int *) p == 0)
+      if (cmd == FIONBIO && async_io () && *(int *) p == 0)
        WSAAsyncSelect (get_socket (), winmsg, 0, 0);
       res = ioctlsocket (get_socket (), cmd, (unsigned long *) p);
       if (res == SOCKET_ERROR)

Pierre A. Humblet | 4 Mar 2005 05:45
Picon

[Patch]: Timer functions

The attached patch implements the alarm, ualarm, setitimer and
getitimer with the timer_xxx calls created by Chris last year.

It has two objectives, both motivated by exim.
- The current implementation of alarm() opens a hidden window.
Thus, on Win9X, services calling alarm do not survive user logouts.
- When running exim as a service under a privileged (non system)
account on XP (trying out what's necessary on Win2003), I have hit
api_fatal ("couldn't create window, %E") with error 5.

The implementation of getitimer has necessitated the development
of timer_gettime (not yet exported) and some changes to the logic
of the timer_thread. I have also fixed a FIXME about race condition
and two bugs: 
- the initial code was not reusing the cygthreads (see attachment).
The fix involves using "auto_release" in the timer thread instead of 
"detach" in the calling function.
- the mu_to was not reinitialized on forks (non-inheritable event).

Pierre

2005-03-05  Pierre Humblet <pierre.humblet <at> ieee.org>

	* window.cc (getitimer): Delete.
	(setitimer): Ditto.
	(ualarm): Ditto.
	(alarm): Ditto.
	* timer.cc (struct timetracker): Delete it, flags and a creator.
	Add it_interval, interval_us, sleepto_us, running, init_muto(),
	and gettime().
(Continue reading)

Christopher Faylor | 4 Mar 2005 06:13
Favicon

Re: [Patch]: Timer functions

On Thu, Mar 03, 2005 at 11:45:45PM -0500, Pierre A. Humblet wrote:
>- the mu_to was not reinitialized on forks (non-inheritable event).

I just spent at least ten minutes looking for a "mu_to" in cygwin,
trying to figure out what you were referring to.  I'm not sure why
you're putting an underscore in the middle there.  Maybe you're thinking
that the "mu" and "to" have separate meanings but they really don't.

Did you actually see mutos not getting created?  Looking at the code
now, it seems like there would be a new muto created every time
there is a new instance of timer_tracker, which was certainly wrong but
it is different from mutos not being created after a fork.

cgf

Corinna Vinschen | 4 Mar 2005 09:36
Picon
Favicon

Re: [Patch]: fhandler_socket::ioctl

On Mar  3 23:36, Pierre A. Humblet wrote:
> 2005-03-04  Pierre Humblet <pierre.humblet <at> ieee.org>
> 
> 	* fhandler_socket.cc (fhandler_socket::ioctl): Only cancel 
>  	 WSAAsyncSelect when async mode is on.

Applied.

Thanks,
Corinna

--

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          mailto:cygwin <at> cygwin.com
Red Hat, Inc.

Pierre A. Humblet | 4 Mar 2005 14:27
Picon

Re: [Patch]: Timer functions

At 12:13 AM 3/4/2005 -0500, Christopher Faylor wrote:
>On Thu, Mar 03, 2005 at 11:45:45PM -0500, Pierre A. Humblet wrote:
>>- the mu_to was not reinitialized on forks (non-inheritable event).
>
>I just spent at least ten minutes looking for a "mu_to" in cygwin,
>trying to figure out what you were referring to.  I'm not sure why
>you're putting an underscore in the middle there.  Maybe you're thinking
>that the "mu" and "to" have separate meanings but they really don't.

Good question. Perhaps because it was late and there is an _ before
the muto in new_muto.

>Did you actually see mutos not getting created?  Looking at the code
>now, it seems like there would be a new muto created every time
>there is a new instance of timer_tracker, which was certainly wrong but
>it is different from mutos not being created after a fork.

As far as I could see, the muto was only created by the constructor of
ttstart and not recreated after a fork. But perhaps you are right and it
was created every time. At any rate it should be OK now.

Pierre

Pavel Tsekov | 6 Mar 2005 21:51
Picon

[PATCH]: Use the user supplied cygdrive prefix

Hello,

with the latest release (1.5.13-1) I have trouble accessing drives via a
prefix other than /cygdrive. It seems that this was introduced by the
following change:

2004-10-28  Pierre Humblet <pierre.humblet <at> ieee.org>

        * path.cc (mount_info::from_registry): Deimpersonate while
        accessing HKLM.
        (mount_info::read_cygdrive_info_from_registry): Ditto.
        * cygheap.h: Define NO_IMPERSONATION.
        (cygheap_user::issetuid): Replace INVALID_HANDLE_VALUE by
        NO_IMPERSONATION.
        (cygheap_user::has_impersonation_tokens): Ditto.
        (cygheap_user::close_impersonation_tokens): Ditto.
        * uinfo.cc (uinfo_init): Ditto.
        * syscalls.cc (seteuid32): Ditto.
        * security.cc (set_impersonation_token): Ditto.

Here is how the system behaves without the patch:

Administrator <at> mordor ~
$ mount
C:\cygwin\usr\X11R6\lib\X11\fonts on /usr/X11R6/lib/X11/fonts type system
(binmode)
C:\cygwin\usr\share\mc\extfs on /usr/share/mc/extfs type system
(binmode,cygexec)
C:\cygwin\bin on /usr/bin type system (binmode)
C:\cygwin\lib on /usr/lib type system (binmode)
(Continue reading)

Christopher Faylor | 6 Mar 2005 22:30
Favicon

Re: [PATCH]: Use the user supplied cygdrive prefix

On Sun, Mar 06, 2005 at 10:51:56PM +0200, Pavel Tsekov wrote:
>2005-03-06  Pavel Tsekov  <ptsekov <at> gmx.net>
>
>	* path.cc (mount_info::read_cygdrive_info_from_registry):
>	Use the user prefix if it exists.

>Index: path.cc
>===================================================================
>RCS file: /cvs/src/src/winsup/cygwin/path.cc,v
>retrieving revision 1.351
>diff -u -p -r1.351 path.cc
>--- path.cc	6 Mar 2005 20:15:07 -0000	1.351
>+++ path.cc	6 Mar 2005 20:51:24 -0000
> <at>  <at>  -1956,6 +1956,7  <at>  <at>  mount_info::read_cygdrive_info_from_regi
> 	cygdrive_flags |= MOUNT_SYSTEM;
>       slashify (cygdrive, cygdrive, 1);
>       cygdrive_len = strlen (cygdrive);
>+      break;
>     }
> }

Applied.  Thanks.

cgf

Christopher Faylor | 7 Mar 2005 05:00
Favicon

Re: [Patch]: Timer functions

On Thu, Mar 03, 2005 at 11:45:45PM -0500, Pierre A. Humblet wrote:
>The attached patch implements the alarm, ualarm, setitimer and
>getitimer with the timer_xxx calls created by Chris last year.
>
>It has two objectives, both motivated by exim.
>- The current implementation of alarm() opens a hidden window.
>Thus, on Win9X, services calling alarm do not survive user logouts.
>- When running exim as a service under a privileged (non system)
>account on XP (trying out what's necessary on Win2003), I have hit
>api_fatal ("couldn't create window, %E") with error 5.
>
>The implementation of getitimer has necessitated the development
>of timer_gettime (not yet exported) and some changes to the logic
>of the timer_thread. I have also fixed a FIXME about race condition
>and two bugs: 
>- the initial code was not reusing the cygthreads (see attachment).
>The fix involves using "auto_release" in the timer thread instead of 
>"detach" in the calling function.
>- the mu_to was not reinitialized on forks (non-inheritable event).

I've fixed the above two problems in the current code and am going
through your patch trying to separate what looks like bug fixes from
what looks like enhanced functionality.

I am puzzled by a couple of things.

Why did you decide to forego using th->detach in favor of (apparently)
a:

      while (running)
(Continue reading)


Gmane