Re: grep and exact matches help..

[Peter Rehley]

On Apr 3, 2007, at 11:00 AM, Kevin Markle wrote:


In this search I want to get winops only not winops and winops-hq

[EMAIL PROTECTED] /cygdrive/e/wsus/group_1a_DEV
$ ls -al | grep winops
-rwx--+ 1 Administrators  1079474 Apr  2 19:32 winops- 
hq_WINDOWSUpdate.log
-rwx--+ 1 Administrators    18993 Apr  3 13:02 winops- 
hq_asr.log
-rwx--+ 1 Administrators  1242842 Apr  3 06:01  
winops_WINDOWSUpdate.log
-rwx--+ 1 Administrators    18580 Apr  3 13:02  
winops_asr.log




Here is one possible solution

ls -1a | grep winops | grep -v winops-hp

or maybe this

ls -1a | sed -e '/winops-hq/d'


Peter

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: hang when using pthread and fork in 1.5.23-1 and snapshot 20070118, and now 1.5.24-1.

[Peter Rehley]

On Jan 31, 2007, at 6:46 AM, Brian Ford wrote:


On Fri, 26 Jan 2007, Peter Rehley wrote:


Hello,

I tried the latest release of cygwin1.dll (1.5.24-1) and it still is
hanging in the same way.  I've tried to debug further with gdb, but
so far I haven't got any useful information out of gdb.

I'll keep trying to get some debug information, but if any one else
can reproduce the problem I would be most appreciative.


I can reproduce a problem.  Your descriptions of it are a bit hard to
follow, so I'm not sure if it is your problem or not.   
Unfortunately, I
don't have time to debug it right now.  I do have a few comments,  
though.
hmmm, rereading those descriptions I see what you mean.  I'll try to  
clarify.
1) happens when the pthread_create fails.  Resources used up  
basically.  It's a normal error condition.


2) happens when the fork doesn't return.  The last message that is  
seen is "forking".  No messages following it are seen, and no  
messages from the main program are seen.


3) happens when the fork returns but has failed.  The last message  
that is seen is "done here" after the "Unable to fork".


   I've tracked what happens after the "done here" message and the  
thread is exiting.  So that would seem the hang is in the main program.




Why are you creating a thread just to fork/exec another process?
Our main application handles requests from a named socket.  Some of  
the requests call shell scripts.  Most of these shell scripts can  
send more requests to the application (I didn't write this, I just  
have to maintain it ).  So for those requests that call shell scripts  
the application has to create a thread and within the thread fork and  
then exec.


Pedantically, I believe you are supposed to call _exit, not exit,  
if fork

fails as stated here in the Solaris man page for fork:

 An applications should call _exit() rather than exit(3C)  if
 it  cannot execve(), since exit() will flush and close stan-
 dard I/O channels and thereby corrupt the  parent  process's
 standard I/O data structures. Using exit(3C) will flush buf-
 fered data twice. See exit(2).


This is good to know because the same application also runs on  
solaris.  Although, it seems to run fine there.


I don't know, however, if this is really true in Cygwin, but it might
explain some misdiagnosed hangs on your part.

Also, the execve call appears to be suspect.  Again, the Solaris  
man page

for execve states:

 The value in
 argv[0] should point to a filename that is  associated  with
 the process being started by one of the exec functions.
[snip]
 As indicated, argc is at least one and the
 first member of the array points to a string containing  the
 name of the file.

Attached is a modified test case that fixes a few of these issues, but
still hangs (or stutters; it does appear to proceed after long  
periods of

time).
I've modified my test case to make sure that execve has valid  
arguments, but I still get the hang.  FWIW, execve is being used  
because of the shell scripts being called.


Peter

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: hang when using pthread and fork in 1.5.23-1 and snapshot 20070118, and now 1.5.24-1.

[Peter Rehley]

Hello,

I tried the latest release of cygwin1.dll (1.5.24-1) and it still is  
hanging in the same way.  I've tried to debug further with gdb, but  
so far I haven't got any useful information out of gdb.


I'll keep trying to get some debug information, but if any one else  
can reproduce the problem I would be most appreciative.


Thanks,
Peter

p.s. my machines spec's are
windows xp, sp2, 2.93 GHz, 760MB ram.
windows xp, sp1 2.39 GHz, 508MB ram.
both are single processor units.

On Jan 19, 2007, at 6:03 PM, Peter Rehley wrote:


Hello,

One of the applications I've been working with has hanging issues.   
It will sometimes work properly, and sometimes it will hang and  
never continue through the rest of the program.


I've created a simple test case that does some of what the  
application does, and it will hang too. The test case has a loop  
that continually creates a pthread.  The pthread calls a function  
that forks and execve's to another program.  Eventually the main  
program will be unable to fork, and it will hang inside of the  
pthread after the thread's function has completed.   However, I can  
also get two other different results depending on how the program  
is compiled and run.


1) pthread_create failed : rc 11 - valid error.
  build with "g++ -DPRFAIL main.cc"
  and run without redirecting output.  Adds additional printf  
statements to output

2) fork called but never returns.  one hang situation.
   build with g++ main.cc
   and run with redirecting output to a file.
3) Unable to create fork, but program doesn't appear to leave  
thread and program hangs.

   build with g++ main.cc
   and run without redirecting output.

I suspect, maybe incorrectly, that the hangs are race conditions.   
I'm hoping that someone will be able to take the test case and be  
able to reproduce what I'm seeing.


The machine is a fresh install of windows xp only.  No webcam  
drivers or other known programs that interact badly with cygwin.  I  
have AVG antivirus installed but even with it uninstalled the  
program can still hang.


I've attached the cygcheck output and the simple test case.

Thanks,
Peter



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Unable to Run Latest Cygwin in Win2k

[Peter Rehley]

On May 4, 2006, at 7:00 PM, Loh Kok Jeng wrote:


Yes, I have checked cygwin.bat and the path is correct.   I have also
checked /etc/passwd, group, profile, which are all OK.  I did
encountered the problem that the files get corrupted and bash refused
to start, but not this time round.

On 5/4/06, Tim Prince <[EMAIL PROTECTED]> wrote:

Loh Kok Jeng wrote:
> Hi,
>
> I'm facing problem running the latest Cygwin on Win2K.
>
> I can install Cygwin from the Internet using an account  
belonging to
> the Administrators group.  The installation can be completed  
without

> any error.
>
> However, when I try to run cygwin.bat, it simple quits without any
> message.  All executable under cygwin\bin exits without any  
message.

> Same for:
> cygcheck -s -v -r
>
> I have tried uninstalling and installing Cygwin a number of  
times and
> the problem still persists.  Any hint would be greatly  
appreciated. Thanks.

>
Did you examine cygwin.bat to see whether it changes into the proper
directory?
Another thing to check is the registry settings.  Are all of the  
mount points there?  I something like this a few weeks ago, but  
haven't seen it with the newer snapshots.





--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/




--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/





--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: 20060301 snapshot and later. sh hangs with very long command line

[Peter Rehley]

On Apr 4, 2006, at 11:56 AM, Peter Rehley wrote:



On Apr 3, 2006, at 4:25 PM, Christopher Faylor wrote:


On Wed, Mar 29, 2006 at 03:14:54PM -0800, Brian Dessent wrote:

Christopher Faylor wrote:
I was building binutils using the cygwin 20060308 snapshot, and  
when it
did the check for "finding the maximum length of command line"  
a sh
shell goes to 99% cpu usage and doesn't return until I end the  
process

using task manager.

I isolated the portion of the script that was hanging and was  
able to
repeat the problem.  The script hangs when it checks for a  
command line
of length 16384.  This happens every time I run the script, and  
it is

reproducible for me on at least windows 2000 and windows XP.  I've
attached a test script.

The problem doesn't happen with the 20060227 snapshot, but  
appeared in
20060301 and later versions.  It is present in the 20060309  
snapshot.


Thanks for the test case.  This should be fixed in the next  
snapshot.


This looks like it has regressed.  I am using CVS HEAD as of  
yesterday

and have run into the "finding the maximum length of command line
arguments" hang in configure scripts.  Peter's testcase fails  
too.  As

a workaround I've set cygexec on my mounts which seems to workaround
the issue (and allows larger commandlines anyway.)


Out of curiousity, does this go away if you mount your /bin  
directory with

the -X option?  If so, the latest snapshot should fix it.
In the test case I used this seems to fix the problem, but when it  
is running the real script, it still hangs.  I'll try the snapshot  
to see if the behavior is the same.



The 20060403 snapshot fixes the issue.

Peter

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: 20060301 snapshot and later. sh hangs with very long command line

[Peter Rehley]

On Apr 3, 2006, at 4:25 PM, Christopher Faylor wrote:


On Wed, Mar 29, 2006 at 03:14:54PM -0800, Brian Dessent wrote:

Christopher Faylor wrote:
I was building binutils using the cygwin 20060308 snapshot, and  
when it

did the check for "finding the maximum length of command line" a sh
shell goes to 99% cpu usage and doesn't return until I end the  
process

using task manager.

I isolated the portion of the script that was hanging and was  
able to
repeat the problem.  The script hangs when it checks for a  
command line
of length 16384.  This happens every time I run the script, and  
it is

reproducible for me on at least windows 2000 and windows XP.  I've
attached a test script.

The problem doesn't happen with the 20060227 snapshot, but  
appeared in
20060301 and later versions.  It is present in the 20060309  
snapshot.


Thanks for the test case.  This should be fixed in the next  
snapshot.


This looks like it has regressed.  I am using CVS HEAD as of  
yesterday

and have run into the "finding the maximum length of command line
arguments" hang in configure scripts.  Peter's testcase fails  
too.  As

a workaround I've set cygexec on my mounts which seems to workaround
the issue (and allows larger commandlines anyway.)


Out of curiousity, does this go away if you mount your /bin  
directory with

the -X option?  If so, the latest snapshot should fix it.
In the test case I used this seems to fix the problem, but when it is  
running the real script, it still hangs.  I'll try the snapshot to  
see if the behavior is the same.


Peter

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Hanging at GetModuleFileName in inside_kernel function

[Peter Rehley]

On Feb 23, 2006, at 6:27 PM, Christopher Faylor wrote:


On Thu, Feb 23, 2006 at 03:43:25PM -0800, Peter Rehley wrote:

On Feb 23, 2006, at 10:13 AM, Dave Korn wrote:


On 23 February 2006 16:20, Peter Rehley wrote:

Yeah, I saw that change, and I tried yesterdays snapshot but it  
still
hung.  I also did some more googling and found that someone  
submitted

a patch a few years ago.  The patch checked to see if it was inside
the ntdll.dll by looking at the handle.
http://www.cygwin.com/ml/cygwin-patches/2003-q2/msg4.html

I found this google too.
http://blogs.msdn.com/oldnewthing/archive/2004/01/28/63880.aspx

I'm going to try that patch today and see what happens.   
Christopher

didn't apply it because it was a bandage and didn't really fix the
bigger problem.


I tried putting the patch in place, and it stopped hanging at the
place I reported.  I had print statements to verify that it went
through the section.  However, the program still hung at some point.
I tracked down a couple of other GMFN calls that used non-null
handles and tried using the technique that the patch had.


Does the latest snapshot behave any differently?  It has a temporary
patch which stops cygwin from suspending (for long) when the  
current IP

is in the cygwin DLL itself.


It seems like an improvement.  It didn't hang, but after about 4000  
iterations of the test script it got a segmentation fault.  It ran  
for 12 hours with another configure script in a separate window or  
about 11 hours and 45 minutes longer than before.  This is with the  
20060227 snapshot.


Attached is the stackdump.

Peter



sh.exe.stackdump
Description: Binary data



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Hanging at GetModuleFileName in inside_kernel function

[Peter Rehley]

On Feb 23, 2006, at 10:13 AM, Dave Korn wrote:


On 23 February 2006 16:20, Peter Rehley wrote:


Yeah, I saw that change, and I tried yesterdays snapshot but it still
hung.  I also did some more googling and found that someone submitted
a patch a few years ago.  The patch checked to see if it was inside
the ntdll.dll by looking at the handle.
http://www.cygwin.com/ml/cygwin-patches/2003-q2/msg4.html

I found this google too.
http://blogs.msdn.com/oldnewthing/archive/2004/01/28/63880.aspx

I'm going to try that patch today and see what happens.  Christopher
didn't apply it because it was a bandage and didn't really fix the
bigger problem.


I tried putting the patch in place, and it stopped hanging at the  
place I reported.  I had print statements to verify that it went  
through the section.  However, the program still hung at some point.   
I tracked down a couple of other GMFN calls that used non-null  
handles and tried using the technique that the patch had.


The one at dll_list::alloc caused nothing to run..died with no error  
message.  The second at format_process_maps seemed to work better in  
that the script when running by it self didn't hang.  But when I ran  
another configure script in a different window it did hang pretty  
quickly.  I'm going to look into this more.




  That all fits right in with your diagnosis of the problem; a  
deadlock of
some kind I guess is the only thing that could make  
GetModuleFileName hang.


  Have you got a stack backtrace showing the call chain when this  
problem

arises?

Here is all of the bt's for all of the threads in the program.  If  
you need more information let me know.  But I probably won't be able  
to get it until next week.  My company is moving and things have to  
be turned off for a bit.


[EMAIL PROTECTED] ~/tmp/debug/build/i686-pc-cygwin/winsup/cygwin
$ gdb /usr/bin/sh.exe -x try.cmd
GNU gdb 6.3.50_2004-12-28-cvs (cygwin-special)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and  
you are
welcome to change it and/or distribute copies of it under certain  
conditions.

Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for  
details.

This GDB was configured as "i686-pc-cygwin"...
add symbol table from file "cygwin1.dbg" at
warning: no loadable sections found in added symbol-file /home/ 
Administrator/tmp

/debug/build/i686-pc-cygwin/winsup/cygwin/cygwin1.dbg
Breakpoint 1 at 0x610164f7: file ../../../../cygwin- 
snapshot-20060222-1/winsup/cygwin/exceptions.cc, line 312.

(gdb) attach 1056
Attaching to program `/usr/bin/sh.exe', process 1056
[Switching to thread 1056.0x3ac]
(gdb) info threads
* 5 thread 1056.0x3ac  0x77fa144c in ntdll!DbgUiConnectToDbg ()
   from /cygdrive/c/WINNT/system32/NTDLL.DLL
  4 thread 1056.0x53c  0x77f94091 in ntdll!ZwWaitForSingleObject ()
   from /cygdrive/c/WINNT/system32/NTDLL.DLL
  3 thread 1056.0x538  0x77f94091 in ntdll!ZwWaitForSingleObject ()
   from /cygdrive/c/WINNT/system32/NTDLL.DLL
  2 thread 1056.0x4fc  0x77f95aae in ntdll!ZwQueryVirtualMemory ()
   from /cygdrive/c/WINNT/system32/NTDLL.DLL
  1 thread 1056.0x3ec  0x610011ad in gotit ()
at ../../../../cygwin-snapshot-20060222-1/winsup/cygwin/ 
autoload.cc:203

Current language:  auto; currently c++
(gdb) thread 1
[Switching to thread 1 (thread 1056.0x3ec)]#0  0x610011ad in gotit ()
at ../../../../cygwin-snapshot-20060222-1/winsup/cygwin/ 
autoload.cc:203

203 std_dll_init ()
(gdb) bt
#0  0x610011ad in gotit ()
at ../../../../cygwin-snapshot-20060222-1/winsup/cygwin/ 
autoload.cc:203

#1  0x6107b540 in fill_rusage (r=0x22e6e0, h=0x3c4)
at ../../../../cygwin-snapshot-20060222-1/winsup/cygwin/ 
resource.cc:79

#2  0x6106e923 in pinfo::exit (this=0x22e648, n=0)
at ../../../../cygwin-snapshot-20060222-1/winsup/cygwin/pinfo.cc: 
156

#3  0x610048e7 in do_exit (status=0)
at ../../../../cygwin-snapshot-20060222-1/winsup/cygwin/dcrt0.cc: 
1118

#4  0x61004cf2 in _exit (n=0)
at ../../../../cygwin-snapshot-20060222-1/winsup/cygwin/dcrt0.cc: 
1146

#5  0x610d in exit (code=0)
at ../../../../../cygwin-snapshot-20060222-1/newlib/libc/stdlib/ 
exit.c:65

#6  0x61004cc1 in cygwin_exit (n=0)
at ../../../../cygwin-snapshot-20060222-1/winsup/cygwin/dcrt0.cc: 
1140
#7  0x004104d8 in execute_command_internal (command=0x555f08,  
asynchronous=0,

pipe_in=-1, pipe_out=-1, fds_to_close=0x556240)
at /home/Administrator/tmp/bash/SOURCES/tmp/bash-3.0/ 
execute_cmd.c:3693

#8  0x00412530 in execute_command (command=0x555f08)
at /home/Administrator/tmp/bash/SOURCES/tmp/bash-3.0/ 
execute_cmd.c:347
#9  0x00410345 in execute_command_internal (command=0x556080,  
asynchronous=0,

pipe_in=-1, pipe_out=-1, fds_to_close=0x556280)
at /home/Administrator/tmp/bash/SOURCES/tmp/bash-3.0/ 
execute_cmd.c:2370

#10 0x00

Re: Hanging at GetModuleFileName in inside_kernel function

[Peter Rehley]

Hi,
On Feb 23, 2006, at 3:20 AM, Corinna Vinschen wrote:


On Feb 21 13:56, Peter Rehley wrote:

On Feb 21, 2006, at 11:31 AM, Dave Korn wrote:


On 21 February 2006 19:06, Peter Rehley wrote:


Hi,

Well, for my particular hang issue cygwin is hanging inside the
inside_kernel function on the GetModuleFileName call.  I tracked  
this

down by adding debug statements (strace.prntf) until I got to the
point where the debug print before GetModuleFileName would  
appear and
the ones after it didn't. This is consistent.  Each hang is  
happening

at this spot.

However, this doesn't explain what is happening, but only where.

I also observed that the times it hung were the only times
inside_kernel was actually called.

I'm still trying to get more information.
Peter

p.s. using cygwin snapshot 1.5.19-20060205.


Due to your problem report and some googling, I had some vague idea
yesterday, what the problem could be.  But it's not clear if the very
simple patch I applied yesterday does really change anything with
respect to your problem.

Please test the 2006-02-22 snapshot from http://cygwin.com/snapshots/
and report if you see a change, to the good or to the bad.


Yeah, I saw that change, and I tried yesterdays snapshot but it still  
hung.  I also did some more googling and found that someone submitted  
a patch a few years ago.  The patch checked to see if it was inside  
the ntdll.dll by looking at the handle.

http://www.cygwin.com/ml/cygwin-patches/2003-q2/msg4.html

I found this google too.
http://blogs.msdn.com/oldnewthing/archive/2004/01/28/63880.aspx

I'm going to try that patch today and see what happens.  Christopher  
didn't apply it because it was a bandage and didn't really fix the  
bigger problem.


Peter


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Hanging at GetModuleFileName in inside_kernel function

[Peter Rehley]

On Feb 21, 2006, at 11:31 AM, Dave Korn wrote:


On 21 February 2006 19:06, Peter Rehley wrote:


Hi,

Well, for my particular hang issue cygwin is hanging inside the
inside_kernel function on the GetModuleFileName call.  I tracked this
down by adding debug statements (strace.prntf) until I got to the
point where the debug print before GetModuleFileName would appear and
the ones after it didn't. This is consistent.  Each hang is happening
at this spot.

However, this doesn't explain what is happening, but only where.

I also observed that the times it hung were the only times
inside_kernel was actually called.

I'm still trying to get more information.
Peter

p.s. using cygwin snapshot 1.5.19-20060205.



  http://cygwin.com/acronyms#PPAST.

  Seriously.  Nobody can debug your code by ESP or remote control.   
We can't

even be sure that what you report is correct if we can't reproduce it.
Dang it.  I forgot to include the reference.  This is in reference to  
the hanging issue I mentioned earlier. http://cygwin.com/ml/cygwin/ 
2006-01/msg00549.html


Basically, when I use a configure script in a loop, at some point one  
of the subshells launched will hang and never return.  Usually it  
takes several hours for the script to hang, but when I run another  
configure script in a different bash window I can get the first  
script to hang within a few minutes.


When the script hangs it can't be stopped by using ctrl-c, and can't  
be killed using the cygwin kill.  It can be killed using task  
manager, and it can be resumed using the process program from http://  
www.beyondlogic.org/solutions/processutil/processutil.htm.


And this only happens on our dual pentium windows 2000 with sp4  
machines.  The other windows machines we use never hang.  These are  
windows xp pro sp1, windows xp pro sp2, and windows 2000 sp4 machines.



If you
don't show us your code, we don't even know if you've literally  
bracketed the
GetModuleFileName call with debug prints or if you've just placed  
one before

and one after the if...else if .. ladder, in which case maybe it's
strncasematch going wrong.
Here is my modified inside_kernel function.  I did have to rearrange  
the conditional so I could add additional debugging information.


static bool
inside_kernel (CONTEXT *cx)
{
  int res;
  MEMORY_BASIC_INFORMATION m;

  strace.prntf (_STRACE_SYSTEM, NULL, "\tChecking virtual");
  memset (&m, 0, sizeof m);
  if (!VirtualQuery ((LPCVOID) cx->Eip, &m, sizeof m))
sigproc_printf ("couldn't get memory info, pc %p, %E", cx->Eip);
  strace.prntf (_STRACE_SYSTEM, NULL, "\tDone virtual check");

  char *checkdir = (char *) alloca (windows_system_directory_length  
+ 4);

  memset (checkdir, 0, sizeof (checkdir));
  strace.prntf (_STRACE_SYSTEM, NULL, "\tDone alloca");

# define h ((HMODULE) m.AllocationBase)
  /* Apparently Windows 95 can sometimes return bogus addresses from
 GetThreadContext.  These resolve to a strange allocation base.
 These should *never* be treated as interruptible. */
  if (!h || m.State != MEM_COMMIT)
{
strace.prntf (_STRACE_SYSTEM, NULL, "\tno h or not MEM_COMMIT");
res = false;
}
  else
{
strace.prntf (_STRACE_SYSTEM, NULL, "\tchecking module");
if (h == user_data->hmodule)
  {
  strace.prntf (_STRACE_SYSTEM, NULL, "\th == user_date->hmodule");
  res = true;
  }
else
  {
  strace.prntf (_STRACE_SYSTEM, NULL, "\tchecking getmodulename");
  if (!GetModuleFileName (h, checkdir,  
windows_system_directory_length + 2))

{
strace.prntf (_STRACE_SYSTEM, NULL, "\tGetModuleFileName % 
d",res);

res = true;
}
  else
{
strace.prntf (_STRACE_SYSTEM, NULL, "\tnone of the above");
res = !strncasematch (windows_system_directory, checkdir,
  windows_system_directory_length);
}
  }
}

  sigproc_printf ("pc %p, h %p, interruptible %d", cx->Eip, h, res);
  strace.prntf (_STRACE_SYSTEM, NULL, "\tDone inside_kernel");
# undef h
  return res;
}



How do you know it hung in the function, rather
than returning from the function and then going wrong, just as a  
for-instance?
How do you know it's really hung, rather than taking a long time to  
time-out

querying a no-longer-present network drive or something like that?
It's sortof hung.  It won't return even after a few days, but using  
the process program to resume will let the hung program continue.   
However, when it resumes it won't print the next debug line.  I don't  
know what happens after that point, but the script continues with no  
errors.



How do we
know whether something earlier in your code hasn't trashed the  
contents of

memory so that GetModuleFil

Hanging at GetModuleFileName in inside_kernel function

[Peter Rehley]

Hi,

Well, for my particular hang issue cygwin is hanging inside the  
inside_kernel function on the GetModuleFileName call.  I tracked this  
down by adding debug statements (strace.prntf) until I got to the  
point where the debug print before GetModuleFileName would appear and  
the ones after it didn't. This is consistent.  Each hang is happening  
at this spot.


However, this doesn't explain what is happening, but only where.

I also observed that the times it hung were the only times  
inside_kernel was actually called.


I'm still trying to get more information.
Peter

p.s. using cygwin snapshot 1.5.19-20060205.

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: once more unto the breech - still hanging, but I have a little more info.

[Peter Rehley]

On Feb 9, 2006, at 4:32 AM, Dave Korn wrote:


On 09 February 2006 00:49, Peter Rehley wrote:


On Jan 11, 2006, at 2:19 PM, Peter Rehley wrote:



  You just dumped 5 meg of useless spam into the inboxes of several  
thousand people.  You just ate up dozens of gigabytes of
sourceware.org's bandwidth, which are a scarce resource, paid for  
out of hard-earned donations and sponsorship.


  You're not the only person here and this isn't your own personal  
in-tray.  Please think more carefully before you do anything so

reckless in future.


I'm sorry.  I messed up.  I apologize for the wasted bandwidth and to  
everyone who's email boxes I've cluttered.  I will be more careful in  
the future.


Peter

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: mismatched dll

[Peter Rehley]

On Feb 2, 2006, at 5:52 PM, Brian Dessent wrote:


Bob Rossi wrote:

Here's another question I have (sorry). Why wouldn't it be  
acceptable to

have to (different version) cygwin1.dll's running on a single system?
That is, 2 completely different Cygwin environments? So, all programs
that link against the same cygwin1.dll are in one Cygwin  
environment. If
there is another version of the cygwin1.dll, and programs link  
against
it, they would be in another Cygwin environment, completely  
independent.







If you are writing an installer of a third party application the basic
logic should thus be:

Is a cygwin1.dll already on the system somewhere?
  Yes:
 Is it newer than mine?
Yes: Install my .exe, but do not install my cygwin1.dll,
 use the existing one.
No:  Prompt user of the situation, and either bail or
 overwrite older DLL with newer DLL.
  No:
 Install my DLL.

Essentially, you must ensure that if a Cygwin DLL already exists you
either use it as-is or replace it with a newer one.  Never install a
second copy, and never overwrite a newer one with an older verison.


Can we get this added to the faq?  It sounds like there are several  
companies out there that install the cygwin1.dll without caring that  
it can cause problems.  This would at least provide some information  
for those that read the faq.


Peter


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: csh script hangs only on cygwin

[Peter Rehley]

On Jan 27, 2006, at 10:55 AM, Stewart Midwinter wrote:


I've been able to isolate a problem with csh on cygwin running on
Windows Server 2003 on a Xeon.  The following script hangs after a
certain period of time ranging from a few minutes to a few hours.

---
#!/bin/csh

while (1)
set year = `date +%y`
set month = `date +%m`
set day = `date +%d`
set hour = `date +%H`
set minute = `date +%M`
set second = `date +%S`
set stamp = "$year$month$day $hour : $minute : $second"
echo $stamp
sleep 2
end


The equivalent script in bash doesn't hang even after a day or more.

-
#!/bin/bash

while [ 1 ]; do
echo $(date +%Y%m%d.%H%M%S)
sleep 2
done
-


This isn't the equivalent script.  It's similar and the output is the  
same, but you only call date once here, while in the other you call  
it 6 times.  Maybe that is way it seems to work for bash and not csh.




Has anyone else had problems with csh scripts on cygwin? Yes, I know
that some people don't recommend using csh (see "Csh programming
considered harmful",
http://www.faqs.org/faqs/unix-faq/shell/csh-whynot/), but I'm stuck
with a whole lot of csh scripts and don't have time to port them all
at the moment.

I have problems with bash/sh script hanging, but I haven't tried csh.

http://cygwin.com/ml/cygwin/2006-01/msg00549.html

Which I'm getting in 1.5.19-4 too, but I haven't tried the latest  
snapshot.  Which reminds me.  Could  you read http://cygwin.com/ 
problems.html and provide the information that it says to provide?


Also were in the script does it hang.  It you type ps -ef what do you  
see.  What information does the /proc directory tell you.  Can you  
ctrl-c out of the script?


Basically, provide as much information as possible.

Peter


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: once more unto the breech - please try a snapshot so I can release this thing

[Peter Rehley]

On Jan 10, 2006, at 6:23 PM, Christopher Faylor wrote:


I hope that I've nailed down the last of the problems due to trying to
hide the console, aka ssh doesn't work, aka emacs doesn't work, aka
rxvt doesn't work, aka setsid something doesn't work.


So, please try a snapshot and report problems.  Please indicate  
whether
the problem is a regression from 1.5.18 or previous snapshots and  
please

respond to this message when reporting a problem.  Don't start a new
thread.  Please always provide cygcheck output even if you think  
you've

already done it recently.  Please provide exact details to duplicate a
problem - a simple program indicating the problem is ideal.



It's a rather difficult bug to reproduce, but I'm still seeing the  
hang up with the test_configure script.  I seem to be getting it  
about once every 2000 iterations of the program.  The thread where I  
mentioned this problem is http://cygwin.com/ml/cygwin/2005-11/ 
msg0.html


The script can be restarted by using the process.exe program (http:// 
www.beyondlogic.org/solutions/processutil/processutil.htm) using the  
restart option.


When I run the test_configure script, after about 2000 iterations it  
will hang.  If I do a ps -ef I can see several running sh commands  
from the script. I pick the one that doesn't have any children and  
cat /proc//cmdline and it show .  Then I cat the winpid  
and use the process program to restart.  This causes things to start  
running again.


Occasionally I will see that there is a child process (i.e. sort, not  
another sh)  If I try to cat the cmdline the cat process seems to  
hang;  I can only kill cat with the task manager.  However, I can  
still cat the winpid and when I do the process restart, things start  
running again.  This behavior is fairly new.  I have noted that it  
was the 12/22/2005 snapshot.  But I didn't try the 12/21, 12/20 or  
12/19 snapshots.


The machine is a windows 2000 with sp4.  Dual processor at 933Mhz.

cygcheck.out attached.

Peter
(this is a resend...the first one seems to have disappeared)


cygcheck.out
Description: Binary data
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: once more unto the breech - please try a snapshot so I can release this thing

[Peter Rehley]

On Jan 10, 2006, at 6:23 PM, Christopher Faylor wrote:


I hope that I've nailed down the last of the problems due to trying to
hide the console, aka ssh doesn't work, aka emacs doesn't work, aka
rxvt doesn't work, aka setsid something doesn't work.


So, please try a snapshot and report problems.  Please indicate  
whether
the problem is a regression from 1.5.18 or previous snapshots and  
please

respond to this message when reporting a problem.  Don't start a new
thread.  Please always provide cygcheck output even if you think  
you've

already done it recently.  Please provide exact details to duplicate a
problem - a simple program indicating the problem is ideal.



It's a rather difficult bug to reproduce, but I'm still seeing the  
hang up with the test_configure script.  I seem to be getting it  
about once every 2000 iterations of the program.  The thread where I  
mentioned this problem is http://cygwin.com/ml/cygwin/2005-11/ 
msg0.html


The script can be restarted by using the process.exe program (http:// 
www.beyondlogic.org/solutions/processutil/processutil.htm) using the  
restart option.


When I run the test_configure script, after about 2000 iterations it  
will hang.  If I do a ps -ef I can see several running sh commands  
from the script. I pick the one that doesn't have any children and  
cat /proc//cmdline and it show .  Then I cat the winpid  
and use the process program to restart.  This causes things to start  
running again.


Occasionally I will see that there is a child process (i.e. sort, not  
another sh)  If I try to cat the cmdline the cat process seems to  
hang;  I can only kill cat with the task manager.  However, I can  
still cat the winpid and when I do the process restart, things start  
running again.  This behavior is fairly new.  I have noted that it  
was the 12/22/2005 snapshot.  But I didn't try the 12/21, 12/20 or  
12/19 snapshots.


The machine is a windows 2000 with sp4.  Dual processor at 933Mhz.

cygcheck.out attached.

Peter



cygcheck.out
Description: Binary data
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Call for testing Cygwin snapshot (getopt and -liberty don't mix..binutils issue)

[Peter Rehley]

On Dec 16, 2005, at 7:05 PM, Christopher Faylor wrote:


On Fri, Dec 16, 2005 at 06:54:48PM -0800, Peter Rehley wrote:

I know that the cygwin getopt and libiberty getopt are different, but
I was just wondering why there is a liberty directory in the  
cygwin src.


Because the cygwin DLL build uses libiberty.  What other reason would
there be?


The hippos perhaps.




And finally for now, is there a way to use the cygwin version of
getopt and not the libiberty version even if we need to link to
libiberty?


-lcygwin


Right, I found this just after I sent the message :P

Thanks,
Peter


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Call for testing Cygwin snapshot (getopt and -liberty don't mix..binutils issue)

[Peter Rehley]

On Dec 16, 2005, at 6:14 PM, Christopher Faylor wrote:


On Fri, Dec 16, 2005 at 05:50:01PM -0800, Peter Rehley wrote:

On Dec 16, 2005, at 3:41 PM, Christopher Faylor wrote:

On Fri, Dec 16, 2005 at 02:41:54PM -0800, Peter Rehley wrote:
I just noticed something else that may or may not be a problem  
(noticed
when working on tftpd).  When I link with iberty (-liberty), the  
getopt

function doesn't return the correct value for the option argument.
Here is a sample program


libiberty has its own implementation of getopt.  This is not a  
cygwin

problem.

hmmm, ok.  it's binutils then.  But when I do a build of cygwin using
the snapshot, it builds libiberty.a.  The libiberty directory in the
snapshot source has a getopt.c file that is nearly identical to the
binutils version.  I've tried out the version of libiberty.a that
cygwin builds (replaced the binutils version), and it has the same
problem as the binutils version.  Why does cygwin need to build it's
own version of libiberty?  and where does the libiberty in the cygwin
source come from?

I'll look at binutils at little closer to track the problem further.


I don't know why you're using libiberty but if it you are using the  
one
that comes from binutils then it still isn't a cygwin problem  
regardless

of the fact that you found a libiberty in cygwin's build area.  Cygwin
has its own version of getopt and it is not the version that comes  
from

libiberty.  There are no guarantees that cygwin's getopt header will
match whatever is in libiberty.a.


libiberty.a is being used because the tftpd (tftpd-hpa) package we  
are using uses xmalloc and the configure script that comes with that  
package determined that libiberty.a contains xmalloc.


I know that the cygwin getopt and libiberty getopt are different, but  
I was just wondering why there is a liberty directory in the cygwin src.


And finally for now, is there a way to use the cygwin version of  
getopt and not the libiberty version even if we need to link to  
libiberty?

Peter

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Call for testing Cygwin snapshot (getopt and -liberty don't mix..binutils issue)

[Peter Rehley]

On Dec 16, 2005, at 3:41 PM, Christopher Faylor wrote:


On Fri, Dec 16, 2005 at 02:41:54PM -0800, Peter Rehley wrote:

I just noticed something else that may or may not be a problem
(noticed when working on tftpd).  When I link with iberty (-liberty),
the getopt function doesn't return the correct value for the option
argument.  Here is a sample program


libiberty has its own implementation of getopt.  This is not a cygwin
problem.
hmmm, ok. it's binutils then.  But when I do a build of cygwin using  
the snapshot, it builds libiberty.a.  The libiberty directory in the  
snapshot source has a getopt.c file that is nearly identical to the  
binutils version.  I've tried out the version of libiberty.a that  
cygwin builds (replaced the binutils version), and it has the same  
problem as the binutils version. Why does cygwin need to build it's  
own version of libiberty?  and where does the libiberty in the cygwin  
source come from?


I'll look at binutils at little closer to track the problem further.
Peter



cgf

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/





--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Call for testing Cygwin snapshot (getopt and -liberty don't mix)

[Peter Rehley]

Hi,

I just noticed something else that may or may not be a problem  
(noticed when working on tftpd).  When I link with iberty (-liberty),  
the getopt function doesn't return the correct value for the option  
argument.  Here is a sample program


#include 
#include 

int main (int argc, char *argv[])
  {
  int c;
  while ((c = getopt(argc, argv, "a:b:")) != -1)
{
switch (c)
  {
  case 'a':
printf ("a received with option %s\n",optarg);
break;

  case 'b':
printf ("b received with option %s\n",optarg);
break;
  default:
printf ("Invalid options\n");
break;
  }
}
  return 0;
  }

when I compile with
gcc -o opt_test opt_test.c

and type
./opt_test -a hello -b goodbye

I see
a received with option hello
b received with option goodbye

When I compile with
gcc -o opt_test opt_test.c -liberty

and type
./opt_test -a hello -b goodbye

I see
a received with option (null)
b received with option (null)


I notice this for 1.5.18 and the 20051215 snapshot.  It did work in  
1.3.22.


Peter
 

cygcheck.out
Description: Binary data


On Nov 30, 2005, at 9:11 AM, Corinna Vinschen wrote:


Since we're much too long on the way to the 1.5.19 release and there
are already way too many changes since 1.5.18, we would again like to
ask people for testing the latest snapshot, 2005-Nov-30, from

  http://www.cygwin.com/snapshots/

Please report back in this thread when you encounter a problem, which
you can't reproduce with 1.5.18.  We're interested in regressions in
the first place.

1.5.19 has also some new functionality over 1.5.18.  If you have  
sources
which take advantage of that stuff if present, we're also  
interested in

getting feeedback about those:

  - clock_getres, clock_setres.
  - fts(3) functions (BSD).
  - futimes.
  - getline, getdelim.
  - memmem.
  - mlock,munlock.
  - mmap(..., MAP_NORESERVE) for anonymous maps.
  - pread, pwrite.
  - readdir_r.
  - strptime's 'c and 'Z' formats.
  - timelocal, timegm.

Keep in mind that we can easier find problems if you attach a brief,
concise, selfcontained testcase, if possible in plain C, which allows
easy reproducing.

If nothing's overly badly broken, we're planning to release 1.5.19
within the next week.  Keep your fingers crossed.

Again, please report all problems as reply to this mail.


Thanks in advance,
Corinna

--
Corinna Vinschen  Please, send mails regarding  
Cygwin to

Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat, Inc.

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/





--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Call for testing Cygwin snapshot

[Peter Rehley]

Hi,

With the 20051212 snapshot I am not seeing this problem.  I'm still  
running tests, but at this point it looks good.  I'm also still  
trying to see if it will hang.


Peter

On Dec 7, 2005, at 3:18 PM, Peter Rehley wrote:


Hi,

I've retried the problem I mentioned in this thread http:// 
cygwin.com/ml/cygwin/2005-11/msg00053.html and the problem still  
exists in the 20051207 snapshot, but it now seems easier to  
reproduce.  Before I had to run "ps -ef" several times before the  
test_configure script died, but now it only takes one or two times.


The recap is that on windows 2000 when I run test_configure (see  
http://cygwin.com/ml/cygwin/2005-11/msg0.html for the script)  
and the in a separate command prompt type "ps -ef" the  
test_configure script exits and issues the message "fork: Resource  
temporarily unavailable"


I am attaching a strace of the test_configure script with the  
failure, and a ps -ef strace that caused a similar failure in the  
test_configure script.


Sorry for the large size of the test_configure stace output.  I cut  
out a large portion and left what I thought might be helpful.


Peter





On Nov 30, 2005, at 9:11 AM, Corinna Vinschen wrote:


Since we're much too long on the way to the 1.5.19 release and there
are already way too many changes since 1.5.18, we would again like to
ask people for testing the latest snapshot, 2005-Nov-30, from

  http://www.cygwin.com/snapshots/

Please report back in this thread when you encounter a problem, which
you can't reproduce with 1.5.18.  We're interested in regressions in
the first place.

1.5.19 has also some new functionality over 1.5.18.  If you have  
sources
which take advantage of that stuff if present, we're also  
interested in

getting feeedback about those:

  - clock_getres, clock_setres.
  - fts(3) functions (BSD).
  - futimes.
  - getline, getdelim.
  - memmem.
  - mlock,munlock.
  - mmap(..., MAP_NORESERVE) for anonymous maps.
  - pread, pwrite.
  - readdir_r.
  - strptime's 'c and 'Z' formats.
  - timelocal, timegm.

Keep in mind that we can easier find problems if you attach a brief,
concise, selfcontained testcase, if possible in plain C, which allows
easy reproducing.

If nothing's overly badly broken, we're planning to release 1.5.19
within the next week.  Keep your fingers crossed.

Again, please report all problems as reply to this mail.


Thanks in advance,
Corinna

--
Corinna Vinschen  Please, send mails regarding  
Cygwin to

Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat, Inc.

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/





--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Call for testing Cygwin snapshot (problem with inode numbers. problem figured out)

[Peter Rehley]

On Dec 3, 2005, at 1:49 AM, Corinna Vinschen wrote:


On Dec  2 12:34, Peter Rehley wrote:

On Dec 2, 2005, at 3:14 AM, Corinna Vinschen wrote:
The problem is, that your Samba version apparently screws up the  
inode

information and we have re-enabled using the inode numbers sent from
remote file systems which are supposed to be capable of that.  For
this
we use the HAS_PERSISTENT_ACLS property.

What Samba version is your Mac OS X using?  I'm using 3.0.20a for
which
the inode information is useable.  Is Samba a part of the OS
packages or
did you install it from an external source?  Is it a rather old one?
Can you upgrade?  The problem is that there's no way for us to
distinguish
between a newer and an older version of Samba.  I would rather not
lose
the inode information when available.


I'm using mac os x 10.4.3 which is using samba version 3.0.10.  So
it's not that old.  However, I did find one reference that implied
that mac did something funny for acl's.

I'm going to try install a non-apple version of samba and see what
happens.


Keep us informed, please.  I'd rather keep the inode handling as it
is now, but we should at least know if there are ways to solve the
problem one way or the other.


Can I say "D'oh"?  I knew I could ;)

The problem turned out to be a samba configuration issue.  Several  
months ago I had added the parameter "large readwrite = no" to my  
smb.conf file in order to speed up transfers between my mac and  
windows.  When it's in the configuration file the inodes are messed  
up.  When I remove it, the inodes are fine.


I get the same behavior on a non-apple version of samba... in my case  
I tried the darwinports version, 3.0.20b, and large readwrite had the  
same problem.


So problem solved.

Thanks for all you help,
Peter




Corinna

--
Corinna Vinschen  Please, send mails regarding  
Cygwin to

Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat, Inc.

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/





--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Call for testing Cygwin snapshot (problem with inode numbers)

[Peter Rehley]

On Dec 2, 2005, at 3:14 AM, Corinna Vinschen wrote:


On Dec  1 15:38, Peter Rehley wrote:

On Dec 1, 2005, at 1:38 PM, Corinna Vinschen wrote:


On Dec  1 13:01, Peter Rehley wrote:

 It only appears to be a problem
when I have a mac os x share mounted to a drive on windows. 
When I

try with a windows share or a linux share I don't seem to have the
problem.

The problem that I'm seeing is that the inode value isn't unique  
when
listing a directory (or using any program that uses the inode  
value).


Do I understand you right that this only happens for  
directories?  The

normal file inodes are looking ok?

No, it also happens for files too.


$%^&


The output of both tests might be helpful.

Output is attached.


Well, the volume information looks exactly as usual for a remote Samba
drive.

The problem is, that your Samba version apparently screws up the inode
information and we have re-enabled using the inode numbers sent from
remote file systems which are supposed to be capable of that.  For  
this

we use the HAS_PERSISTENT_ACLS property.

What Samba version is your Mac OS X using?  I'm using 3.0.20a for  
which
the inode information is useable.  Is Samba a part of the OS  
packages or

did you install it from an external source?  Is it a rather old one?
Can you upgrade?  The problem is that there's no way for us to  
distinguish
between a newer and an older version of Samba.  I would rather not  
lose

the inode information when available.

I'm using mac os x 10.4.3 which is using samba version 3.0.10.  So  
it's not that old.  However, I did find one reference that implied  
that mac did something funny for acl's.


I'm going to try install a non-apple version of samba and see what  
happens.


Corinna

--
Corinna Vinschen  Please, send mails regarding  
Cygwin to

Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat, Inc.

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/





--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Call for testing Cygwin snapshot (problem with inode numbers)

[Peter Rehley]

On Dec 1, 2005, at 1:38 PM, Corinna Vinschen wrote:


On Dec  1 13:01, Peter Rehley wrote:

  It only appears to be a problem
when I have a mac os x share mounted to a drive on windows.When I
try with a windows share or a linux share I don't seem to have the
problem.

The problem that I'm seeing is that the inode value isn't unique when
listing a directory (or using any program that uses the inode value).


Do I understand you right that this only happens for directories?  The
normal file inodes are looking ok?

No, it also happens for files too.




The inode that comes back from doing a ls -li is first much shorter
that a normal inode.  I've included lists from my share when using
the 20051123 snapshot and then they 20051128 snapshot.  The only
change that I've done between the two is update cygwin using the
cygwin-inst snapshot file.


Yes, I have no Mac OS X handy.  I have attached two hacked test
applications, which you can simply build with `gcc -o foo foo.c'.

The first one, GetVolInfo, should get a Cygwin path to any file on the
Mac OS X share.  It prints the volume information returned from the
share.

The second one, GetFileInfo, should be called on a few directories  
and a

couple of files on the share.

The output of both tests might be helpful.

Output is attached.



And another thing to try.  Could you please check (only with the  
latest

snapshot) if the resulting inode numbers are the same when running

 $ cd /local/cygwin/dir && ls -i //MacOSX/share/dir

and

 $ cd //MacOSX/share && ls -i dir

?


cd /tmp && ls -i //10.0.10.42/prehley/tmp
it returned
3776088840 GetFileInfo.c  3776088840 GetVolInfo.c  3776088848 inode_test

cd //10.0.10.42/prehley && ls -i tmp
it returned
3776088840 GetFileInfo.c  3776088840 GetVolInfo.c  3776088848 inode_test




getinfo.out
Description: Binary data





Thanks,
Corinna

--  
Corinna Vinschen  Please, send mails regarding  
Cygwin to

Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat, Inc.


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Hang with 1.5.18, 1.5.19 snapshot 20051029 (now with 20051117)

[Peter Rehley]

Hi

I did some more testing and looking through source code, and it seems  
that the process that is hanging hasn't initialized yet.  When I do  
the cygwin kill command it returns with "No such process" and based  
on what I see in the code (pinfo.cc, pinfo::init) that can happen if  
the process is still waiting to be initialized.  Tthat's one case,  
the other case is when the process really doesn't exist.  But the  
process does exist, and it shows up in ps command and windows process  
viewer.


It's a guess that the hung process is waiting to be initialized, but  
I did try resuming the process using a program called "process  
explorer", and the hung process continued, finished, and the main  
test_configure also continued.


This implies that wait_sig (sigproc.cc) isn't called sometimes.

Of course this is pure speculation.  I'll keep trying to see if I can  
provide information that is more useful.


Peter

On Oct 31, 2005, at 4:09 PM, Peter Rehley wrote:


Hi,

I have a problem where a configure script is hanging.  I first saw  
the behavior in 1.5.18, and it's still there in the latest  
snapshot. The only machines that we are seeing it hang on are  
windows 2000 machines, sp4, with duel pentinum 933 mhz processors,  
and using ssh to login to the machine.  I haven't been able to  
reproduce the problem on single processor machines or when ssh is  
not used.


Under 1.5.18, the hang occurred about 1 in ten times in the  
test_configure script (provided in the bash_test.tar.bz2 file.   
Under the latest snapshot it's about 1 in 900.


When the hang happens it appears that a process is completed, but  
still can be found in the process directory.  The cmdline file says  
, but the process still shows up in the process list (ps - 
ef).  If I try to clean up by killing the process, the kill command  
says that the process doesn't exist.  The only way that I can make  
the hung process go away is by using the task manager to kill the  
process.


The simplest test I've gotten down to is:

### Simple Test
#! /bin/sh
# Guess values for system-dependent variables and create Makefiles.
# Generated by GNU Autoconf 2.59 for expr-configure 1.5.11-1.
#
# Report bugs to .
#
# Copyright (C) 2003 Free Software Foundation, Inc.
# This configure script is free software; the Free Software Foundation
# gives unlimited permission to copy, distribute and modify it.
## - ##
## M4sh Initialization.  ##
## - ##

set -xv

count=0
while [ ! -f stop ] ; do
  as_var=LC_MONETARY
  if (test -z "`(eval $as_var=C; export $as_var; echo ho) 2>&1`");  
then

echo "hi"
eval $as_var=C; export $as_var
  fi
  count=`expr $count + 1`
  echo $count
done
### End simple test

Someplace in the eval line the hang occurs.  Unfortunately I  
haven't had success when using strace.


If I've missed anything or there are questions about the above,  
please let me know.

Peter











--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Simple cygwin script doesn't work with Windows schedular/Command prompt

[Peter Rehley]

On Nov 15, 2005, at 5:58 PM, Pandey, Sunil K wrote:


I have a very simple shell script say test.csh

$cat test.csh
#!/bin/csh
set x = "Some name"
echo $x > /tmp/xyz

When I ran this script in cygwin shell it works fine.

$cat /tmp/xyz
Some Name

However when I try to launch the same script with windows scheduler  
via

following command line it doesn't work.

Scheduler command line

C:\cygwin\bin\bash.exe -l -e /tmp/test.csh

Try using csh instead of bash



I also tried above command on Windows command prompt still doesn't  
work.


It creates a blank xyz file. Most probably set command is not working.
Not sure how to fix this script. Any help/hack will be much-much
appreciated.

Thanks.
Sunil

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/





--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

BUG: Binutils strip corrupts dll files when using cygwin 1.5.18 and latest snapshot (20051103)

[Peter Rehley]

Hi,

After compiling a snapshot, I tried to strip the cygwin1.dll using  
the binutils strip command.  After I did this I started seeing this  
windows dialog box appear:


"ls.exe - Bad Image

The application or DLL F:\cygwin\home\peter\tmp\cygwin1.dll is not a  
valid Windows image.  Please check this against your installation  
diskette."


I first tried this on cygwin 1.5.18 using binutils 20050610.  I then  
updated my cygwin to the latest snapshot and tried again, and I got  
the same message.  I then tried rebuilding binutils, just to make  
sure it wasn't a binutils build issue, and received the same error  
message when I used this recompiled strip.


Let me know is you need additional information...cycheck output for  
snapshot is attached.

Peter



cygcheck_20051103.out
Description: Binary data
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Hang with 1.5.18, 1.5.19 snapshot 20051029

[Peter Rehley]

On Nov 1, 2005, at 5:52 AM, Volker Quetschke wrote:


Hi!

Peter Rehley wrote:
I have a problem where a configure script is hanging.  I first  
saw  the behavior in 1.5.18, and it's still there in the latest  
snapshot.  The only machines that we are seeing it hang on are  
windows 2000  machines, sp4, with duel pentinum 933 mhz  
processors, and using ssh  to login to the machine.  I haven't  
been able to reproduce the  problem on single processor machines  
or when ssh is not used.
Under 1.5.18, the hang occurred about 1 in ten times in the   
test_configure script (provided in the bash_test.tar.bz2 file.   
Under  the latest snapshot it's about 1 in 900.
When the hang happens it appears that a process is completed, but   
still can be found in the process directory.  The cmdline file  
says  , but the process still shows up in the process  
list (ps - ef).  If I try to clean up by killing the process, the  
kill command  says that the process doesn't exist.  The only way  
that I can make  the hung process go away is by using the task  
manager to kill the  process.


Your symptoms look familiar to our OOo build hang. I'm curious if in
your case a:

$ ls /proc//fd

also cures the hang. (Sometimes this has to be issued several times.)


This didn't seem to do anything for me.but I also did not try  
several times,  and now I'm having a hard time reproducing the  
problem. :(


One really odd thing that I did notice on my windows 2000 machines  
was that when I do a 'ps -ef' many times in a row quickly, the  
test_configure script that I'm using dies...it either segfaults or I  
get fork: Resource Temporarily unavailable.


Peter

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Hang with 1.5.18, 1.5.19 snapshot 20051029

[Peter Rehley]

Hi,

I have a problem where a configure script is hanging.  I first saw  
the behavior in 1.5.18, and it's still there in the latest snapshot.  
The only machines that we are seeing it hang on are windows 2000  
machines, sp4, with duel pentinum 933 mhz processors, and using ssh  
to login to the machine.  I haven't been able to reproduce the  
problem on single processor machines or when ssh is not used.


Under 1.5.18, the hang occurred about 1 in ten times in the  
test_configure script (provided in the bash_test.tar.bz2 file.  Under  
the latest snapshot it's about 1 in 900.


When the hang happens it appears that a process is completed, but  
still can be found in the process directory.  The cmdline file says  
, but the process still shows up in the process list (ps - 
ef).  If I try to clean up by killing the process, the kill command  
says that the process doesn't exist.  The only way that I can make  
the hung process go away is by using the task manager to kill the  
process.


The simplest test I've gotten down to is:

### Simple Test
#! /bin/sh
# Guess values for system-dependent variables and create Makefiles.
# Generated by GNU Autoconf 2.59 for expr-configure 1.5.11-1.
#
# Report bugs to .
#
# Copyright (C) 2003 Free Software Foundation, Inc.
# This configure script is free software; the Free Software Foundation
# gives unlimited permission to copy, distribute and modify it.
## - ##
## M4sh Initialization.  ##
## - ##

set -xv

count=0
while [ ! -f stop ] ; do
  as_var=LC_MONETARY
  if (test -z "`(eval $as_var=C; export $as_var; echo ho) 2>&1`"); then
echo "hi"
eval $as_var=C; export $as_var
  fi
  count=`expr $count + 1`
  echo $count
done
### End simple test

Someplace in the eval line the hang occurs.  Unfortunately I haven't  
had success when using strace.


If I've missed anything or there are questions about the above,  
please let me know.

Peter



cygcheck.out
Description: Binary data




bash_test.tar.bz2
Description: Binary data







 
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: cant set baud rate with stty

[Peter Rehley]

On Oct 8, 2005, at 4:33 PM, tns1 wrote:


Cygwin on WinXP

What version of cygwin are you using?


I am trying to redirect the IO from a terminal app to a serial port.
$terminal_app > /dev/com5
Works but uses the wrong baud rate.

$stty /dev/com5 115200
Does not change the baud: 'unable to perform all requested  
operations'.

I have tried many variations on this syntax.
$stty does not even show the usb adaptor I am using on com5, but it  
does not let me change the baud rate on the ports that it does see.



Did you try looking for this problem.
http://cygwin.com/ml/cygwin/2005-08/msg00485.html

Try a snapshot.  You might be surprised.

Should stty  let me change the baud in the shell?

Where is the default baud rate I am getting established, in  
windows, in cygwin, or in my usb adaptor driver?


thanks




--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/






--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: sed doesnt convert varibale values???

[Peter Rehley]

On Oct 6, 2005, at 10:57 AM, Maloney, Michael wrote:



I tried it with double-quotes before and it wont accept it:

$ sed "s/weblogic.Server/$APP_SERVER_DOMAIN weblogic.Server/" $file
sed: -e expression #1, char 22: unknown option to `s'

ok, This tells me that APP_SERVER_DOMAIN is getting expanded and  
probably contains some characters that are messing up the sed  
expression.  What is $APP_SERVER_DOMAIN set to.   Just send "echo  
sed "


I grabbed a line from a script that works on Solaris (double quotes  
work

there):
sed "s/"$system"_User_email = "$cur_email"/"$system"_User_email =
"$new_mail"/" $file > ./tmp.txt



-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On  
Behalf

Of Peter Rehley
Sent: Thursday, October 06, 2005 1:41 PM
To: Cygwin List'
Subject: Re: sed doesnt convert varibale values???


On Oct 6, 2005, at 10:36 AM, Maloney, Michael wrote:




I am using sed and for some reason, it is entering the variable
name and
not the value to output. The line looks like:
sed 's/weblogic.Server/$APP_SERVER_DOMAIN weblogic.Server/' $file


It's not a sed thing, it's a shell thing.  When you put the
expression in single quotes, the shell doesn't touch the string, but
by putting the string in double quotes the shell will parse the
string before sending it to sed.  This is standard for unix, linux,
cygwin, etc, etc



The output looks like:
%JAVA_HOME%\bin\java %JAVA_VM% %MEM_ARGS% %JAVA_OPTIONS%
-Dweblogic.Name=%SERVER
_NAME% -Dweblogic.ProductionModeEnabled=%PRODUCTION_MODE%
-Djava.security.policy
="%WL_HOME%\server\lib\weblogic.policy" "$APP_SERVER_DOMAIN
weblogic.Server"

It's just putting the variable name there. I went back an looked at
some
earlier scripts that I wrote for Unix and the Unix sed worked just
as I
am trying to do now.





--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/







--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/






--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: sed doesnt convert varibale values???

[Peter Rehley]

On Oct 6, 2005, at 10:36 AM, Maloney, Michael wrote:



I am using sed and for some reason, it is entering the variable  
name and

not the value to output. The line looks like:
sed 's/weblogic.Server/$APP_SERVER_DOMAIN weblogic.Server/' $file
It's not a sed thing, it's a shell thing.  When you put the  
expression in single quotes, the shell doesn't touch the string, but  
by putting the string in double quotes the shell will parse the  
string before sending it to sed.  This is standard for unix, linux,  
cygwin, etc, etc


The output looks like:
%JAVA_HOME%\bin\java %JAVA_VM% %MEM_ARGS% %JAVA_OPTIONS%
-Dweblogic.Name=%SERVER
_NAME% -Dweblogic.ProductionModeEnabled=%PRODUCTION_MODE%
-Djava.security.policy
="%WL_HOME%\server\lib\weblogic.policy" "$APP_SERVER_DOMAIN
weblogic.Server"

It's just putting the variable name there. I went back an looked at  
some
earlier scripts that I wrote for Unix and the Unix sed worked just  
as I

am trying to do now.



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/






--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Bug in stty or /dev/ttySx handling code

[Peter Rehley]

Hi,

I'm seeing problems when I run stty.  If I run stty -F /dev/ttyS0, it 
shows 0 baud.  I found this thread from may that has the same issue:


http://sourceware.org/ml/cygwin/2005-05/msg00399.html

and I found that a patch was applied in 02/01/2003 that seems to 
prevent setting the baud if the DTR is zero.  Why is the baud invalid 
when DTR is not set?  It seems like to me that DTR doesn't/shouldn't 
have an affect on the reported baud.  Can anyone shed some light on 
this?


Thanks,
Peter
---
A Møøse once bit my sister

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Please try latest snapshot -- pthreads mutex users please note

[Peter Rehley]

Yeah, I tried the June 30th snapshot.
On Jul 1, 2005, at 1:21 PM, Christopher Faylor wrote:


On Fri, Jul 01, 2005 at 01:09:21PM -0700, Peter Rehley wrote:

My tests indicated that the changes are working correctly.


You did try the snapshot, right?  I neglected to mention that I had to
make some corresponding changes to the DLL beyond the below changes.
I don't know exactly when I did that.  I made the below changes on 6/9
but I made more changes on 6/11.  So, any snapshot since that time
would have these changes.


On Jun 30, 2005, at 8:23 PM, Christopher Faylor wrote:
We're coming close to a 1.5.18 release.  Please try the latest 
snapshot

at http://cygwin.com/snapshots/ and help verify that there are no
regresions against 1.5.17.

I'm particularly interested in hearing if the changes made (at 
users's

requests) to the default mutex handling in pthread.h are working
correctly.  Specifically, does this:

Index: include/pthread.h
===
RCS file: /cvs/uberbaum/winsup/cygwin/include/pthread.h,v
retrieving revision 1.21
retrieving revision 1.23
diff -u -d -1 -r1.21 -r1.23
--- include/pthread.h   2 May 2005 03:50:09 -   1.21
+++ include/pthread.h   11 Jun 2005 04:56:36 -  1.23
@@ -55,3 +55,3 @@
#define PTHREAD_MUTEX_NORMAL 2
-#define PTHREAD_MUTEX_DEFAULT PTHREAD_MUTEX_ERRORCHECK
+#define PTHREAD_MUTEX_DEFAULT PTHREAD_MUTEX_NORMAL
/* this should be too low to ever be a valid address */

do what was requested?  This simple change required a lot of changes 
in
the cygwin test suite so I'm not entirely convinced that it was a 
good

thing yet.


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/




Enjoy,
Peter
---
A Møøse once bit my sister


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Please try latest snapshot -- pthreads mutex users please note

[Peter Rehley]

My tests indicated that the changes are working correctly.

Peter

On Jun 30, 2005, at 8:23 PM, Christopher Faylor wrote:


We're coming close to a 1.5.18 release.  Please try the latest snapshot
at http://cygwin.com/snapshots/ and help verify that there are no
regresions against 1.5.17.

I'm particularly interested in hearing if the changes made (at users's
requests) to the default mutex handling in pthread.h are working
correctly.  Specifically, does this:

Index: include/pthread.h
===
RCS file: /cvs/uberbaum/winsup/cygwin/include/pthread.h,v
retrieving revision 1.21
retrieving revision 1.23
diff -u -d -1 -r1.21 -r1.23
--- include/pthread.h   2 May 2005 03:50:09 -   1.21
+++ include/pthread.h   11 Jun 2005 04:56:36 -  1.23
@@ -55,3 +55,3 @@
 #define PTHREAD_MUTEX_NORMAL 2
-#define PTHREAD_MUTEX_DEFAULT PTHREAD_MUTEX_ERRORCHECK
+#define PTHREAD_MUTEX_DEFAULT PTHREAD_MUTEX_NORMAL
 /* this should be too low to ever be a valid address */

do what was requested?  This simple change required a lot of changes in
the cygwin test suite so I'm not entirely convinced that it was a good
thing yet.

cgf

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/




Enjoy,
Peter
---
A Møøse once bit my sister


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: PTHREAD_MUTEX_DEFAULT different for cygwin v.s. linux.

[Peter Rehley]

On Jun 9, 2005, at 8:57 AM, Christopher Faylor wrote:


On Wed, Jun 08, 2005 at 03:29:46PM -0700, Peter Rehley wrote:

On Jun 8, 2005, at 2:59 PM, Thomas E. Zerucha wrote:


I have a problem similar to that of:

http://sourceware.org/ml/cygwin/2005-05/msg01400.html

I have an old system that I'm trying to port that uses pthreads, but
doesn't set the attribute, and a non-owner thread will destroy the
thread in a deallocate routine, but this won't happen (it won't
actually destroy the thread).

The problem is that (in pthread.h) PTHREAD_MUTEX_DEFAULT is .._NORMAL
on linux, the system was originally written for.  It works but
eventually dies when it runs out of threads or mutexes or something
since it can't recycle.  PTHREAD_MUTEX_DEFAULT is .._ERRORCHECK on
cygwin.

It would be painful to add a whole section to create an attribute
structure just to set this to be the same as linux.


If you look at the test case you will see a line that says
mutex=PTHREAD_MUTEX_INITIALIZER;

This causes the program to use the default (ERRORCHECK) mutex.  To get
a normal mutex, you can use mutex=PTHREAD_NORMAL_MUTEX_INITIALIZER_NP;

However, in the test case when NORMAL is used, the mutex never gets
unlocked because the signal SIG_CHLD doesn't get to the parent.


FWIW, I've changed the default for PTHREAD_MUTEX_INITIALIZER to
PTHREAD_NORMAL_MUTEX_INITIALIZER_NP in CVS.  Last night I also tried to
implement handling for interrupting mutexes based on Corinna's
explanation of what your patch did.


Shouldn't PTHREAD_MUTEX_DEFAULT be PTHREAD_MUTEX_NORMAL?


Both of these changes are in the current snapshot.
And the pthread_mutex_lock is still waiting forever...doesn't process 
the signal.  Looking at the code I think that the pthread_mutex::_lock 
function should be using the cancelable_wait routine in place of the 
WaitForSingleObject.





cgf

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/




Enjoy,
Peter
---
A Møøse once bit my sister


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: PTHREAD_MUTEX_DEFAULT different for cygwin v.s. linux.

[Peter Rehley]

On Jun 8, 2005, at 2:59 PM, Thomas E. Zerucha wrote:


I have a problem similar to that of:

http://sourceware.org/ml/cygwin/2005-05/msg01400.html

I have an old system that I'm trying to port that uses pthreads, but 
doesn't set the attribute, and a non-owner thread will destroy the 
thread in a deallocate routine, but this won't happen (it won't 
actually destroy the thread).


The problem is that (in pthread.h) PTHREAD_MUTEX_DEFAULT is .._NORMAL 
on linux, the system was originally written for.  It works but 
eventually dies when it runs out of threads or mutexes or something 
since it can't recycle.  PTHREAD_MUTEX_DEFAULT is .._ERRORCHECK on 
cygwin.


It would be painful to add a whole section to create an attribute 
structure just to set this to be the same as linux.

If you look at the test case you will see a line that says
mutex=PTHREAD_MUTEX_INITIALIZER;

This causes the program to use the default (ERRORCHECK) mutex.  To get 
a normal mutex, you can use

mutex=PTHREAD_NORMAL_MUTEX_INITIALIZER_NP;

However, in the test case when NORMAL is used, the mutex never gets 
unlocked because the signal SIG_CHLD doesn't get to the parent.


Hopefully that is something that you can use.


I can't seem to build the cygwin1.dll so I could replace it (are there 
any instructions on how to create an identical copy to the release?  I 
didn't see any on the FAQ, and ./configure;make generates a file 8x 
larger, and it complained about something with the address).


You need to provide more information than this.  Based on what you 
said, you didn't follow the instructions in the FAQ; and yes there are 
instructions for building the cygwin1.dll in the FAQ



I think just changing it in the pthread.h and recompiling the dll will 
fix it.  Note that the attribute is invisible since you need not 
bother with the attr structure and parameter when doing defaults.



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/




Enjoy,
Peter
---
A Møøse once bit my sister


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: pthreads, cygwin and pthread_mutex_lock not blocking

[Peter Rehley]

On Jun 8, 2005, at 7:42 AM, Corinna Vinschen wrote:


On Jun  7 10:22, Peter Rehley wrote:

Any comments about this?

On Jun 2, 2005, at 11:22 AM, Peter Rehley wrote:


Here is a patch to thread.cc that allows _lock to process signals.
The patch is against the 1.178 version of thread.cc found in cvs.


Thanks for the patch, but it's big enough to require a copyright
assignment, unfortunately.  See http://cygwin.com/contrib.html.
hmm, I'm not certain that it really needs a copyright assignment.  The 
code is basically taken from the pthread::join function and then 
modified slightly to work in the lock context.  It just looks big 
because it's new to lock :)




Since cgf hasn't had a look into your patch so far, he's not tainted
and will come up with a self-written patch to fix this problem for now.

ahh yes.  I  understand.


However, if you would be interested to contribute to the Cygwin DLL,
I'd be glad to receive your copyright assignment at one point.


Corinna

--
Corinna Vinschen  Please, send mails regarding Cygwin 
to

Cygwin Project Co-Leader  mailto:cygwin@cygwin.com
Red Hat, Inc.

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/




Enjoy,
Peter
---
A Møøse once bit my sister


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: pthreads, cygwin and pthread_mutex_lock not blocking

[Peter Rehley]

Any comments about this?

On Jun 2, 2005, at 11:22 AM, Peter Rehley wrote:

Here is a patch to thread.cc that allows _lock to process signals.  
The patch is against the 1.178 version of thread.cc found in cvs.


--- thread.cc.orig  Thu Jun  2 11:17:39 2005
+++ thread.cc   Thu Jun  2 11:20:00 2005
@@ -1543,8 +1543,24 @@
 }
   else
 {
-  WaitForSingleObject (win32_obj_id, INFINITE);
-  set_owner (self);
+  //WaitForSingleObject (win32_obj_id, INFINITE);
+  //set_owner (self);
+  bool loop = true;
+  do
+   switch (pthread::cancelable_wait (win32_obj_id, INFINITE, 
false, true))

+ {
+ case WAIT_OBJECT_0:
+set_owner (self);
+loop=false;
+   break;
+ case WAIT_SIGNALED:
+   _my_tls.call_signal_handler ();
+   break;
+ default:
+   // should never happen
+   return EINVAL;
+ }
+  while (loop);
 }

   return result;

On Jun 1, 2005, at 6:17 PM, Peter Rehley wrote:


Here is the patch to pthread.h

hummingbird:~/MontaVista/tmp prehley$ diff -u pthread.h.cygwin 
pthread.h.new

--- pthread.h.cygwinWed Jun  1 18:15:40 2005
+++ pthread.h.new   Wed Jun  1 18:06:49 2005
@@ -53,12 +53,12 @@
 #define PTHREAD_MUTEX_RECURSIVE 0
 #define PTHREAD_MUTEX_ERRORCHECK 1
 #define PTHREAD_MUTEX_NORMAL 2
-#define PTHREAD_MUTEX_DEFAULT PTHREAD_MUTEX_ERRORCHECK
+#define PTHREAD_MUTEX_DEFAULT PTHREAD_MUTEX_NORMAL
 /* this should be too low to ever be a valid address */
 #define PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP (pthread_mutex_t)18
 #define PTHREAD_NORMAL_MUTEX_INITIALIZER_NP (pthread_mutex_t)19
 #define PTHREAD_ERRORCHECK_MUTEX_INITIALIZER_NP (pthread_mutex_t)20
-#define PTHREAD_MUTEX_INITIALIZER 
PTHREAD_ERRORCHECK_MUTEX_INITIALIZER_NP

+#define PTHREAD_MUTEX_INITIALIZER PTHREAD_NORMAL_MUTEX_INITIALIZER_NP
 #define PTHREAD_ONCE_INIT { PTHREAD_MUTEX_INITIALIZER, 0 }
 #define PTHREAD_PRIO_INHERIT
 #define PTHREAD_PRIO_NONE
@@ -202,4 +202,3 @@
 #endif

 #endif /* _PTHREAD_H */
-

On Jun 1, 2005, at 5:22 PM, Peter Rehley wrote:




On May 31, 2005, at 10:50 AM, David Rothenberger wrote:


On 5/31/2005 10:15 AM, Peter Rehley wrote:
Well, here is a simple test case, but turns out I wasn't using the 
latest version.  I was having the problem on 1.5.12,  I haven't 
been able to get a good build with cygwin 1.5.17-1.  It builds and 
I can run the install script, but when I put the dll in place I 
see the message "cygheap magic number mismatch detected", and gcc 
doesn't want to work.


I had a similar problem (see 
<http://cygwin.com/ml/cygwin/2005-05/msg01251.html>). It turned out 
it was because I was using the latest release of binutils. Try 
rolling back to the previous release.


Ok, I rolled binutils to 20041229, rebuilt and copied the new dll.  
It's having the same issue that I see in 1.5.12.  When I debug the 
program, I see that the signal is being sent, but it doesn't get 
executed.


I've looked at the cygwin code, and I have noticed that the sleep 
(nanosleep) is calling pthread::cancelable_wait, and that will call 
WaitForMultipleObjects.  However, in pthread_mutex::_lock, it's only 
using WaitForSingleObject.  I'm wondering if something like 
WaitForMultipleObjects should be added to the lock function so that 
signals (SIGCHLD, in my case) can be handled.


It's just a guess since I'm not an expert with this code.

Enjoy,
Peter
---
A Møøse once bit my sister


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/




Enjoy,
Peter
---
A Møøse once bit my sister


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/




Enjoy,
Peter
---
A Møøse once bit my sister


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/




Enjoy,
Peter
---
A Møøse once bit my sister


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: pthreads, cygwin and pthread_mutex_lock not blocking

[Peter Rehley]

Here is a patch to thread.cc that allows _lock to process signals.  The 
patch is against the 1.178 version of thread.cc found in cvs.


--- thread.cc.orig  Thu Jun  2 11:17:39 2005
+++ thread.cc   Thu Jun  2 11:20:00 2005
@@ -1543,8 +1543,24 @@
 }
   else
 {
-  WaitForSingleObject (win32_obj_id, INFINITE);
-  set_owner (self);
+  //WaitForSingleObject (win32_obj_id, INFINITE);
+  //set_owner (self);
+  bool loop = true;
+  do
+   switch (pthread::cancelable_wait (win32_obj_id, INFINITE, 
false, true))

+ {
+ case WAIT_OBJECT_0:
+set_owner (self);
+loop=false;
+   break;
+ case WAIT_SIGNALED:
+   _my_tls.call_signal_handler ();
+   break;
+ default:
+   // should never happen
+   return EINVAL;
+ }
+  while (loop);
 }

   return result;

On Jun 1, 2005, at 6:17 PM, Peter Rehley wrote:


Here is the patch to pthread.h

hummingbird:~/MontaVista/tmp prehley$ diff -u pthread.h.cygwin 
pthread.h.new

--- pthread.h.cygwinWed Jun  1 18:15:40 2005
+++ pthread.h.new   Wed Jun  1 18:06:49 2005
@@ -53,12 +53,12 @@
 #define PTHREAD_MUTEX_RECURSIVE 0
 #define PTHREAD_MUTEX_ERRORCHECK 1
 #define PTHREAD_MUTEX_NORMAL 2
-#define PTHREAD_MUTEX_DEFAULT PTHREAD_MUTEX_ERRORCHECK
+#define PTHREAD_MUTEX_DEFAULT PTHREAD_MUTEX_NORMAL
 /* this should be too low to ever be a valid address */
 #define PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP (pthread_mutex_t)18
 #define PTHREAD_NORMAL_MUTEX_INITIALIZER_NP (pthread_mutex_t)19
 #define PTHREAD_ERRORCHECK_MUTEX_INITIALIZER_NP (pthread_mutex_t)20
-#define PTHREAD_MUTEX_INITIALIZER 
PTHREAD_ERRORCHECK_MUTEX_INITIALIZER_NP

+#define PTHREAD_MUTEX_INITIALIZER PTHREAD_NORMAL_MUTEX_INITIALIZER_NP
 #define PTHREAD_ONCE_INIT { PTHREAD_MUTEX_INITIALIZER, 0 }
 #define PTHREAD_PRIO_INHERIT
 #define PTHREAD_PRIO_NONE
@@ -202,4 +202,3 @@
 #endif

 #endif /* _PTHREAD_H */
-

On Jun 1, 2005, at 5:22 PM, Peter Rehley wrote:




On May 31, 2005, at 10:50 AM, David Rothenberger wrote:


On 5/31/2005 10:15 AM, Peter Rehley wrote:
Well, here is a simple test case, but turns out I wasn't using the 
latest version.  I was having the problem on 1.5.12,  I haven't 
been able to get a good build with cygwin 1.5.17-1.  It builds and 
I can run the install script, but when I put the dll in place I see 
the message "cygheap magic number mismatch detected", and gcc 
doesn't want to work.


I had a similar problem (see 
<http://cygwin.com/ml/cygwin/2005-05/msg01251.html>). It turned out 
it was because I was using the latest release of binutils. Try 
rolling back to the previous release.


Ok, I rolled binutils to 20041229, rebuilt and copied the new dll.  
It's having the same issue that I see in 1.5.12.  When I debug the 
program, I see that the signal is being sent, but it doesn't get 
executed.


I've looked at the cygwin code, and I have noticed that the sleep 
(nanosleep) is calling pthread::cancelable_wait, and that will call 
WaitForMultipleObjects.  However, in pthread_mutex::_lock, it's only 
using WaitForSingleObject.  I'm wondering if something like 
WaitForMultipleObjects should be added to the lock function so that 
signals (SIGCHLD, in my case) can be handled.


It's just a guess since I'm not an expert with this code.

Enjoy,
Peter
---
A Møøse once bit my sister


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/




Enjoy,
Peter
---
A Møøse once bit my sister


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/




Enjoy,
Peter
---
A Møøse once bit my sister


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: pthreads, cygwin and pthread_mutex_lock not blocking

[Peter Rehley]

Here is the patch to pthread.h

hummingbird:~/MontaVista/tmp prehley$ diff -u pthread.h.cygwin 
pthread.h.new

--- pthread.h.cygwinWed Jun  1 18:15:40 2005
+++ pthread.h.new   Wed Jun  1 18:06:49 2005
@@ -53,12 +53,12 @@
 #define PTHREAD_MUTEX_RECURSIVE 0
 #define PTHREAD_MUTEX_ERRORCHECK 1
 #define PTHREAD_MUTEX_NORMAL 2
-#define PTHREAD_MUTEX_DEFAULT PTHREAD_MUTEX_ERRORCHECK
+#define PTHREAD_MUTEX_DEFAULT PTHREAD_MUTEX_NORMAL
 /* this should be too low to ever be a valid address */
 #define PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP (pthread_mutex_t)18
 #define PTHREAD_NORMAL_MUTEX_INITIALIZER_NP (pthread_mutex_t)19
 #define PTHREAD_ERRORCHECK_MUTEX_INITIALIZER_NP (pthread_mutex_t)20
-#define PTHREAD_MUTEX_INITIALIZER 
PTHREAD_ERRORCHECK_MUTEX_INITIALIZER_NP

+#define PTHREAD_MUTEX_INITIALIZER PTHREAD_NORMAL_MUTEX_INITIALIZER_NP
 #define PTHREAD_ONCE_INIT { PTHREAD_MUTEX_INITIALIZER, 0 }
 #define PTHREAD_PRIO_INHERIT
 #define PTHREAD_PRIO_NONE
@@ -202,4 +202,3 @@
 #endif

 #endif /* _PTHREAD_H */
-

On Jun 1, 2005, at 5:22 PM, Peter Rehley wrote:




On May 31, 2005, at 10:50 AM, David Rothenberger wrote:


On 5/31/2005 10:15 AM, Peter Rehley wrote:
Well, here is a simple test case, but turns out I wasn't using the 
latest version.  I was having the problem on 1.5.12,  I haven't been 
able to get a good build with cygwin 1.5.17-1.  It builds and I can 
run the install script, but when I put the dll in place I see the 
message "cygheap magic number mismatch detected", and gcc doesn't 
want to work.


I had a similar problem (see 
<http://cygwin.com/ml/cygwin/2005-05/msg01251.html>). It turned out 
it was because I was using the latest release of binutils. Try 
rolling back to the previous release.


Ok, I rolled binutils to 20041229, rebuilt and copied the new dll.  
It's having the same issue that I see in 1.5.12.  When I debug the 
program, I see that the signal is being sent, but it doesn't get 
executed.


I've looked at the cygwin code, and I have noticed that the sleep 
(nanosleep) is calling pthread::cancelable_wait, and that will call 
WaitForMultipleObjects.  However, in pthread_mutex::_lock, it's only 
using WaitForSingleObject.  I'm wondering if something like 
WaitForMultipleObjects should be added to the lock function so that 
signals (SIGCHLD, in my case) can be handled.


It's just a guess since I'm not an expert with this code.

Enjoy,
Peter
---
A Møøse once bit my sister


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/




Enjoy,
Peter
---
A Møøse once bit my sister


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: pthreads, cygwin and pthread_mutex_lock not blocking

[Peter Rehley]

On May 31, 2005, at 10:50 AM, David Rothenberger wrote:


On 5/31/2005 10:15 AM, Peter Rehley wrote:
Well, here is a simple test case, but turns out I wasn't using the 
latest version.  I was having the problem on 1.5.12,  I haven't been 
able to get a good build with cygwin 1.5.17-1.  It builds and I can 
run the install script, but when I put the dll in place I see the 
message "cygheap magic number mismatch detected", and gcc doesn't 
want to work.


I had a similar problem (see 
<http://cygwin.com/ml/cygwin/2005-05/msg01251.html>). It turned out it 
was because I was using the latest release of binutils. Try rolling 
back to the previous release.


Ok, I rolled binutils to 20041229, rebuilt and copied the new dll.  
It's having the same issue that I see in 1.5.12.  When I debug the 
program, I see that the signal is being sent, but it doesn't get 
executed.


I've looked at the cygwin code, and I have noticed that the sleep 
(nanosleep) is calling pthread::cancelable_wait, and that will call 
WaitForMultipleObjects.  However, in pthread_mutex::_lock, it's only 
using WaitForSingleObject.  I'm wondering if something like 
WaitForMultipleObjects should be added to the lock function so that 
signals (SIGCHLD, in my case) can be handled.


It's just a guess since I'm not an expert with this code.

Enjoy,
Peter
---
A Møøse once bit my sister


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: pthreads, cygwin and pthread_mutex_lock not blocking

[Peter Rehley]

Well, here is a simple test case, but turns out I wasn't using the 
latest version.  I was having the problem on 1.5.12,  I haven't been 
able to get a good build with cygwin 1.5.17-1.  It builds and I can run 
the install script, but when I put the dll in place I see the message 
"cygheap magic number mismatch detected", and gcc doesn't want to work.


I followed the instructions on the FAQ page for building cygwin.  Also 
the only line that I changed was in winsup/cygwin/include/pthread.h, 
line 56


from
#define PTHREAD_MUTEX_DEFAULT PTHREAD_MUTEX_ERRORCHECK
to
#define PTHREAD_MUTEX_DEFAULT PTHREAD_MUTEX_NORMAL

On the unmodified cygwin 1.5.17, the parent lock returns 45 (EDEADLK)

On May 28, 2005, at 9:15 AM, Christopher Faylor wrote:


On Fri, May 27, 2005 at 04:35:39PM -0700, Peter Rehley wrote:

On May 27, 2005, at 1:28 PM, Christopher Faylor wrote:


On Fri, May 27, 2005 at 10:57:34AM -0700, Peter Rehley wrote:

I'm trying to use pthread in cygwin, and I'm expecting the function
pthread_mutex_lock to block when used.  However it is returning 
error
45 (EDEADLK).I'm using a static initializer for the thread so 
the

mutex is type PTHREAD_MUTEX_DEFAULT.
When I look through the pthread code I see that 
PTHREAD_MUTEX_DEFAULT

is set to PTHREAD_MUTEX_ERRORCHECK,
When I do the same on linux or soloris, the pthread_mutex_lock 
blocks,

and looking in the pthread.h file on those systems see that  the
default is set to PTHREAD_MUTEX_NORMAL.

Why is cygwin using PTHREAD_MUTEX_ERRORCHECK as the default?  And 
what

problems might occur if PTHREAD_MUTEX_DEFAULT is set to
PTHREAD_MUTEX_NORMAL?


Why not just try it and report the results?

Done.  Hangs at WaitForSingleObject.


Can you provide a STC(tm) (simple test case) which demonstrates the
problem both with and without PTHREAD_MUTEX_ERRORCHECK?

cgf

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/




Enjoy,
Peter
---
A Møøse once bit my sister
#include 
#include 
#include 

pthread_mutex_t mutex;

void signal_rec(int sig_num)
  {
  printf("The child is done\n");
  pthread_mutex_unlock(&mutex);
  }

int main(int argc, char *argv[])
  {
  int ret_value;

  signal(SIGCHLD, signal_rec);

  mutex=PTHREAD_MUTEX_INITIALIZER;
  ret_value=pthread_mutex_lock(&mutex);
  printf("thread locked %d\n",ret_value);
  ret_value=fork();
  if (ret_value==0)
{
printf("I'm the child\n");
sleep(5);
printf("ahh, what a good nap\n");
}
  else
{
printf("I'm the parent\n");
//sleep(10);
ret_value = pthread_mutex_lock(&mutex);
printf("heh, I'm done %d\n",ret_value);
}

  return 0;
  }



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: pthreads, cygwin and pthread_mutex_lock not blocking

[Peter Rehley]

On May 27, 2005, at 1:28 PM, Christopher Faylor wrote:


On Fri, May 27, 2005 at 10:57:34AM -0700, Peter Rehley wrote:

I'm trying to use pthread in cygwin, and I'm expecting the function
pthread_mutex_lock to block when used.  However it is returning error
45 (EDEADLK).I'm using a static initializer for the thread so the
mutex is type PTHREAD_MUTEX_DEFAULT.
When I look through the pthread code I see that PTHREAD_MUTEX_DEFAULT
is set to PTHREAD_MUTEX_ERRORCHECK,
When I do the same on linux or soloris, the pthread_mutex_lock blocks,
and looking in the pthread.h file on those systems see that  the
default is set to PTHREAD_MUTEX_NORMAL.

Why is cygwin using PTHREAD_MUTEX_ERRORCHECK as the default?  And what
problems might occur if PTHREAD_MUTEX_DEFAULT is set to
PTHREAD_MUTEX_NORMAL?


Why not just try it and report the results?

Done.  Hangs at WaitForSingleObject.

The application that I'm working on is rpm 4.3.3, the problem that we 
are seeing is running scripts.  When set the default is set to 
ERRORCHECK, the parent process doesn't wait and removes the script 
before the child has chance to run it.


When default is NORMAL, the parents hangs waiting for the child.  The 
app uses SIGCHLD to signal the parent when the child dies, and the 
signal handler for sigchld releases the mutex.  This should cause the 
WaitForSingleObject to release and the application should continue to 
run.  For whatever reason, the signal isn't being seen by the parent.


Enjoy,
Peter
---
A Møøse once bit my sister


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

pthreads, cygwin and pthread_mutex_lock not blocking

[Peter Rehley]

Hi,

I'm trying to use pthread in cygwin, and I'm expecting the function 
pthread_mutex_lock to block when used.  However it is returning error 
45 (EDEADLK).I'm using a static initializer for the thread so the 
mutex is type PTHREAD_MUTEX_DEFAULT.
When I look through the pthread code I see that PTHREAD_MUTEX_DEFAULT 
is set to PTHREAD_MUTEX_ERRORCHECK,
When I do the same on linux or soloris, the pthread_mutex_lock blocks, 
and looking in the pthread.h file on those systems see that  the 
default is set to PTHREAD_MUTEX_NORMAL.


Why is cygwin using PTHREAD_MUTEX_ERRORCHECK as the default?  And what 
problems might occur if PTHREAD_MUTEX_DEFAULT is set to 
PTHREAD_MUTEX_NORMAL?


The reason why I'm asking is because the application that I'm working 
on needs to work on linux, soloris and cygwin, and keeping the code the 
same is important.


Thanks,
Peter

---
A Møøse once bit my sister

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Problem running xgettext after compiling gettext 0.14.1 with gcc 3.3.3

[Peter Rehley]

hmm, the solution was mentioned over a month ago, don't know why it's 
suddenly become active.  FYI: Problem was const struct in the some of 
the programs.  See

http://sourceware.org/ml/cygwin/2005-03/msg00048.html
Also, execute bit was set on, it is an NTFS filesystem, and turning 
execute bit off gave slightly different message.  See the previous 
replies to this thread.


On Apr 11, 2005, at 12:47 AM, Brian Dessent wrote:
Peter Rehley wrote:
"The application failed to initialize properly (0xc005). Click on
OK to terminate the application."
My money is on this:
<http://sources.redhat.com/ml/cygwin/2004-09/msg01101.html>.  Newer 
gccs
try to put const data in .rdata section, but this fails if one of those
"const" datums is actually a pointer that needs runtime fixup by 
windows
loader.  The best solution at the moment seems to be to hunt down and
remove instances of const data structures that contain pointers and
remove the const keyword.

Brian
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Enjoy,
Peter
---
A Møøse once bit my sister
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Question about mkdir and windows paths

[Peter Rehley]

Hi,
I'm using mkdir with a windows path, and it's not working the way I 
expect.  When I type the following command

mkdir -p C:\\Cygwin\\tmp\hello; # cygwin and tmp already exist
the directory is created.
If I try the following
rm -rf C:\\Cygwin\\tmp\\hello
mkdir -p C:\\Cygwin\\tmp\\hello\\goodbye
I get
mkdir : cannot create directory `C:\\MontaVista\\tmp\\hello\\goodbye': 
No such file or directory

Is this the except behavior of mkdir or is there a bug here?  I've 
check the source and noticed that the make_path function only looks for 
'/'

The source I've check is coreutils-5.2-1 and coreutils-5.3-0.  Both are 
doing the same thing.

Thanks,
Peter
---
A Møøse once bit my sister
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Re; Problem running xgettext after compiling gettext 0.14.1 with gcc 3.3.3

[Peter Rehley]

On Feb 25, 2005, at 2:04 PM, Danny Smith wrote:
From: Peter Rehley
Hi,
I am working on a project where I had to recompile gettext using gcc
3.3.3. I'm using cygwin 1.5.12. It compiled without issues but when I
went to run some of the programs, a windows dialog box pops up showing
the following message:
"The application failed to initialize properly (0xc005). Click on 
OK
to terminate the application."

see thread starting here:
 http://sourceware.org/ml/cygwin/2004-09/msg01101.html
heh, I actually had that thread bookmarked.
Anyway I took the suggestion and modified the libtool files.  And it 
didn't work.  I still got the same error message.  What I did next was 
look for occurrences of "const struct", and noticed some in the 
programs that I had problems with.  xgettext was one program and the 
long options struct was defined with "static const struct".  When I 
removed the const from there and recompiled, the program worked.

I tried this with the other programs that I was having problems with, 
and they all started working.  I'm still baffled but I have the 
programs working now.

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Enjoy,
Peter
---
A Møøse once bit my sister
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Problem running xgettext after compiling gettext 0.14.1 with gcc 3.3.3

[Peter Rehley]

On Feb 25, 2005, at 1:29 PM, Peter Rehley wrote:
On Feb 25, 2005, at 1:03 PM, Igor Pechtchanski wrote:
On Fri, 25 Feb 2005, Peter Rehley wrote:
Hi,
I am working on a project where I had to recompile gettext using gcc 
3.3.3.
I'm using cygwin 1.5.12.  It compiled without issues but when I went 
to run
some of the programs, a windows dialog box pops up showing the 
following
message:

"The application failed to initialize properly (0xc005). Click 
on OK to
terminate the application."
Check that all of the required DLLs are accessible and have the
executable bit set.
Yes all are readable and all have the exe bit set. (mode 755)
If I remove the execute bit, the error message becomes
"The application failed to initialize properly (0xc022).  Click on 
OK to terminate the application"


Igor
--
http://cs.nyu.edu/~pechtcha/
 |\  _,,,---,,_ [EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
|,4-  ) )-,_. ,\ (  `'-'Igor Pechtchanski, Ph.D.
   '---''(_/--'  `-'\_) fL  a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!
"The Sun will pass between the Earth and the Moon tonight for a total
Lunar eclipse..." -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT

Peter
---
A Møøse once bit my sister
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Enjoy,
Peter
---
A Møøse once bit my sister
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Problem running xgettext after compiling gettext 0.14.1 with gcc 3.3.3

[Peter Rehley]

On Feb 25, 2005, at 1:03 PM, Igor Pechtchanski wrote:
On Fri, 25 Feb 2005, Peter Rehley wrote:
Hi,
I am working on a project where I had to recompile gettext using gcc 
3.3.3.
I'm using cygwin 1.5.12.  It compiled without issues but when I went 
to run
some of the programs, a windows dialog box pops up showing the 
following
message:

"The application failed to initialize properly (0xc005). Click on 
OK to
terminate the application."
Check that all of the required DLLs are accessible and have the
executable bit set.
Yes all are readable and all have the exe bit set. (mode 755)
Igor
--
http://cs.nyu.edu/~pechtcha/
 |\  _,,,---,,_ [EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
|,4-  ) )-,_. ,\ (  `'-'Igor Pechtchanski, Ph.D.
   '---''(_/--'  `-'\_) fL  a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!
"The Sun will pass between the Earth and the Moon tonight for a total
Lunar eclipse..." -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT

Peter
---
A Møøse once bit my sister
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: setup package format v. rpm, reasoning?

[Peter Rehley]

On Feb 15, 2005, at 4:36 PM, Linda W wrote:
I can imagine during the early development of cygwin, the rpm
package types were rather "unsupportable" -- especially on a
"first install", since no unix shell or coreutils are available.
However, after the basic support is installed, what was the reasoning
for keeping packages in YAPM (YetAnotherPackageManager).
It seems even a bit more surprising considering Cygwin's early
roots coming from a RedHat...
Why is the current setup.exe "format" still the preferred format?
Would it be beneficial to start having the packages moved toward
rpm format?  It would be useful, at times, to do the equivalent
of an "rpm -qf ", or "rpm -qi" for info, etc...Yes,
one can continue to reinvent the wheel by writing utils that parse
file lists in /etc/setup, but it seems that would be 'reinventing'
the wheel for no great purpose...
So I guess I'm curious why Cygwin uses YAPM since RPM has been
ported?  I'm not looking for any religious debates -- just
technical/engineering reasons why a different package.  I'm not
"sold" on the rpm package manager, just wondering why the need
for creating another format?
It would require a new setup.exe.  The current setup program is a pure 
windows program.  This is needed because it doesn't require using any 
cygwin program or package.  If it used, say for example the 
cygwin1.dll, that dll couldn't be updated because windows won't allow 
files to be changed while they are in use.

So, the new setup would need  create a temporary cygwin environment 
that is totally separate from any already installed cygwin environment. 
 The environment could have rpm and do updates pointing to the cygwin 
environment being updated.

 Or setup would need non-cygwin programs that know how to use rpm.  
Both of these would require rewriting setup from scratch.  Do a search 
for discussions about why setup.exe hasn't been changed.

It's weird -- I tried installing an RPM, and among files that
were listed as 'missing' were /bin/rm, /bin/sh, /usr/bin/perl
and libc -- I can see RPM not knowing about the libc package
name, but the filenames?  I know they're installed, so what's
the scoop?
rpm uses it's database to determine what is there or not.  While 
/bin/sh, etc, may be on the system, they aren't in the rpm database, 
and hence the error.
Thanks,
-linda
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Enjoy,
Peter
---
A Møøse once bit my sister
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Apache as a Windows Service?

[Peter Rehley]

On Feb 11, 2005, at 6:49 PM, Ronald S Woan wrote:
have read /usr/share/doc/Cygwin/apache-1.3.29-1.README which indicates 
all
you need is the -a "-F" flag. I did have to run rebaseall which cause 
httpd
to fail which was fixed using setup to do a reinstall of apache. 
Problem now
is I quit my shell that started the httpd daemon and disconnected, 
httpd
dies, so it seems like the windows service is the best option to keep 
it
running even when I am logged off.


[EMAIL PROTECTED] /usr/share/doc/Cygwin
$ cygrunsrv -I apache -p /usr/sbin/httpd.exe -a "-F"

[EMAIL PROTECTED] /usr/share/doc/Cygwin
$ cygrunsrv -S apache
cygrunsrv: Error starting a service: QueryServiceStatus:  Win32 error 
1062:

The service has not been started.


[EMAIL PROTECTED] /usr/share/doc/Cygwin
$ /usr/sbin/httpd.exe -F

Thanks,
Ronald S Woan

Did you check the log files?
Enjoy,
Peter
---
A Møøse once bit my sister
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Help with deleting Cygwin shortcuts

[Peter Rehley]

On Feb 8, 2005, at 5:23 PM, Ivan Lenev wrote:
Hello!
Can someone help me with deleting all the files from the
\Cygwin directory?
I was able to delete about 99% of the files in the
directories, but some files stated that they cannot be
deleted because "Access is Denied. Make sure the disk is
not full or write protected." I tried everything from 'Safe
Mode' to deleting with Cmd. All of these files are
Shortcuts to some other files. Ex. d:\cygwin\etc\hosts
cannot be deleted.
I even tried cutting them into the recycle bin. I am also
sure that the shortcuts are not used by any programs or
services.
Any help would be appreciated!!!
-Ivan Lenev

Have you tried change or looking at the permissions on the shortcuts?
Enjoy,
Peter
---
A Møøse once bit my sister
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Renaming Cygwin DLLs

[Peter Rehley]

On Jan 6, 2005, at 12:09 PM, Mike Disbrow wrote:
On Wed, Jan 05, 2005 at 03:58:39PM -0600, Mike Disbrow wrote:
>I'd like to build the supporting Cygwin DLLs to be renamed to 
something
>other than cyg*.dll (e.g.  cygwin1.dll to foo.dll), what is the best
>way to build the DLLs with different names?

May I ask why you want to do this?  I can't think of any valid reason 
to
rename the DLL which would not involve trying to mask the existence of
Cygwin.  And, I can't think of any reason for doing that which does 
not
involve either bypassing Cygwin's GPL or trying to take credit for a 
DLL
which you didn't develop.

The motive isn't that sinister.  We'll be deploying Cygwin's X Server 
to users and don't want the users to know whose X Server we're using.  
In fact, we're doing all we can to hide the fact that the application 
they're using is running through X.  By changing the dll names we hope 
to make it a little harder for someone to determine we're using 
Cygwin's X Server so they don't get the source, and modify it in some 
malicious way.

- Mike
Ummm, an intelligent user would still figure this out.It seems that 
you are trying to camouflage that cygwin is being used.  Security 
through obscurity will not stop a user.   There is also more that you 
need to change then just the dll name.  There are the registry keys, 
uname output, plus probably a dozen other things that I'm not aware of.

What might be better is to setup the cygwin environment as admin on an 
NTFS partition and then make sure the user doesn't have admin 
privileges.  That way a user wouldn't be able to change the default 
configuration.  They still might be able to figure out how to recompile 
items and make them work and screw up their own environment, but 
nothing that an admin couldn't quickly fix.

Enjoy,
Peter
---
A Møøse once bit my sister
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: HELP: Cygwin ruined my WinXP files/HDD

[Peter Rehley]

On Dec 11, 2004, at 9:07 PM, KevinGPO wrote:

find . -type d | xargs chmod +w
Hi guys, Thanks for your replies.
Igor, I tried find . -type d | xargs chmod +w
and then rm -Rf the main folder/directory. To no avail, it does not 
work :(((
Coming in the middle, so I may be out of context or you might have 
tried this already...

But try changing the permissions of the files using windows explorer.  
I've had some odds cases where this is the only way to remove files.
Igor Pechtchanski  cs.nyu.edu> writes:
and then your 'rm -rf' command again.
Igor


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Enjoy,
Peter
---
A Møøse once bit my sister
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Failing to mount from nfs-server

[Peter Rehley]

On Dec 3, 2004, at 4:00 PM, Michael Butler wrote:
How silly of me to not try this earlier.  Success!  Thank you.
On another note, is it a bug that * does not work in this version of
nfsd/mountd/whatever?  I have had it work with every other version of
nfsd.
I think that it would be a bug.  The manual says a * should match any 
machine, but it doesn't on cygwin.

Mike
On Fri, 3 Dec 2004 15:52:11 -0800, Peter Rehley <[EMAIL PROTECTED]> 
wrote:
Try removing the '*' in the exports file and restarting things.  I've
had problems with using only the *.  Your milage may vary though.
Enjoy,
Peter
---
A Møøse once bit my sister


Enjoy,
Peter
---
A Møøse once bit my sister
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Failing to mount from nfs-server

[Peter Rehley]

On Dec 3, 2004, at 3:00 PM, Michael Butler wrote:
When I add -overs=2 to the mount command, I get a permission denied
error instead of the server down error.  Can anyone help me?
On Thu, 2 Dec 2004 15:06:08 -0800, Michael Butler 
<[EMAIL PROTECTED]> wrote:
I installed the latest cygwin with nfs-server and the required support
packges, along with nothing else extra.  I ran nfs-server-config,
changed my exports, and started the daemons in the windows services.
All 3 have "started" but when I try to mount shared directories from a
Fedora Core 2 client on the same network, I get
mount to NFS server '192.168.1.2' failed: server is down.
rpcinfo -p from the localhost and from the client both return the
following info:
  program vers proto   port
   102   tcp111
   102   udp111
   132   udp   2049  nfs
   132   tcp   2049  nfs
   151   udp850
   152   udp850
   151   tcp853
   152   tcp853
nmapping these ports shows each of them as open except for 850.  There
is no firewall software on the server machine.  My exports file is as
follows:
/mnt/c/export/root  *(ro,no_root_squash,sync)
/pub*(ro,no_root_squash,sync)
It seems to me as though this should be a working setup.  Did I miss 
something?
Try removing the '*' in the exports file and restarting things.  I've 
had problems with using only the *.  Your milage may vary though.


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Enjoy,
Peter
---
A Møøse once bit my sister
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: flex and dos source files. How is flex built for cygwin (No longer on topic)

[Peter Rehley]

On Nov 22, 2004, at 11:00 AM, Igor Pechtchanski wrote:
[snip]

[snip]
Modified build commands would be
./configure; make LDFLAGS="/usr/lib/automode.o"

The above should really be
./configure; make LDLIBS="/usr/lib/automode.o"

make LIBS="-lintl /usr/lib/automode.o".  There is no LDLIBS in the 
flex
source, and when setting LIBS the -lintl is needed because the LIBS 
in the
Makefile had that value.
It *is* LDLIBS.  See "make -pf/dev/null | grep -C2 '^%: %.o'".  BTW, 
this
is not Cygwin-specific.
Ok, that's the built-in rule, but the flex Makefile isn't using the 
built-in rule.  See the rule for $(FLEX)


It may not matter for linking in a .o file, but it certainly will 
matter if
a -l form is used (as you tried earlier).

HTH,
Igor
--
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,4-  ) )-,_. ,\ (  `'-'   Igor Pechtchanski, Ph.D.
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!
"The Sun will pass between the Earth and the Moon tonight for a total
Lunar eclipse..." -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT

Enjoy,
Peter
---
A Møøse once bit my sister
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: flex and dos source files. How is flex built for cygwin

[Peter Rehley]

On Nov 22, 2004, at 9:21 AM, Igor Pechtchanski wrote:
On Sat, 20 Nov 2004, Peter Rehley wrote:
On Nov 20, 2004, at 10:19 AM, Reini Urban wrote:
[snip]
ok thanks, for confirmation.
so cgf should repackage it. it's obviously a bug.
I think so also because this isn't the behavior that occurs on linux 
or BSD.
Umm, which behavior are you talking about?  The automatic conversion 
of CRLF
line endings to LF?  This is Cygwin-specific behavior, and has nothing 
to do
with Linux or BSD.  It's there to avoid complaints from people who 
use, say,
notepad on binary mounts to edit their .flex files.
I suspected as much.
[snip]
Modified build commands would be
./configure; make LDFLAGS="/usr/lib/automode.o"

The above should really be
./configure; make LDLIBS="/usr/lib/automode.o"

make LIBS="-lintl /usr/lib/automode.o".  There is no LDLIBS in the flex 
source, and when setting LIBS the -lintl is needed because the LIBS in 
the Makefile had that value.
It may not matter for linking in a .o file, but it certainly will 
matter if
a -l form is used (as you tried earlier).


HTH,
Igor
--
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,4-  ) )-,_. ,\ (  `'-'   Igor Pechtchanski, Ph.D.
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!
"The Sun will pass between the Earth and the Moon tonight for a total
Lunar eclipse..." -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT

Let's move along.  Nothing to see here.
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Undelete

[Peter Rehley]

On Nov 20, 2004, at 11:20 AM, kent morris wrote:
I installed cygwin and found it does not meet my needs. How do I 
un-install it? WIN XP Control Panel does not show it in the add/remove 
window. I have not found any documentation on how to remove the 
program.
Did you see this?
http://cygwin.com/faq/faq0.html#SEC19
--
Kent Morris
May you live in interesting times

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Enjoy,
Peter
---
A Møøse once bit my sister
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: flex and dos source files. How is flex built for cygwin

[Peter Rehley]

On Nov 20, 2004, at 10:19 AM, Reini Urban wrote:
Peter Rehley schrieb:
On Nov 20, 2004, at 12:07 AM, Reini Urban wrote:
Peter Rehley schrieb:
Peter Rehley wrote:
Larry Hall wrote:
We have a customer that is using flex under a custom version of 
cygwin that we provided them (with source).  The customer is 
having problems when their "*.l" files are in dos format.  Flex 
is taking the lines from the file and adding them into the 
lex.yy.c file untouched.  (i.e. they still have the \n\r at the 
end), and this causing problems later on.

I tried using the version of flex that comes with the latest 
version of cygwin (1.5.12) and flex changes the \n\r to just \n, 
which makes everything work fine.  Good I thought since the 
version of flex we provide is not the latest.  I'll just 
recompile.

But when I tried that with the latest flex (2.5.4a-3) I get the 
same behavior that the customer is seeing.  I get this behavior 
even if I compile on the latest version of cygwin.

So, my question is what options are used for building flex?

there's no build script and an inactive maintainer. we don't know. 
hopefully just the standard options.
./configure --prefix=/usr sharedstatedir=/var --mandir=/usr/share/man
make && make install
Using these options the behavior of flex differs from the flex that 
is shipped with cygwin.

Linking against /usr/lib/binmode.o perhaps?

He meant that by accident flex was linked against binmode.o, which 
is wrong. It was no advice to reproduce that error with linking 
against binmode or textmount.

Tried on cygwin 1.5.12
make clean
make LDFLAGS="/usr/lib/binmode.o",
and
make clean
make LDFLAGS="-lbinmode"
but neither helped

for sure not.
However linking the /usr/lib/textmode.o did work
make LDFLAGS="/usr/lib/textmode.o" # <- did the job
Thanks Larry for pointing me in the right directory :)
Oh god. This was the right direction? Sorry no.
If you open your flex input file in a *textmode mount* \r\n will get 
converted, if you open that in a binmode mount it will not get 
converted.
$ man mount
The filesystem has been mounted in binmode, but  the flex that comes 
with cygwin translates the files.  Both flex and the text file are on 
binmode mounts.
ok thanks, for confirmation.
so cgf should repackage it. it's obviously a bug.
I think so also because this isn't the behavior that occurs on linux or 
BSD.

And please add a hint how to reproduce from source, so we don't have 
to guess. Christofer claims that he didn't link against textmode.a, 
but it looks like so, or there was some deeper magic behind, which 
went away suddenly.
He is using automode.o, he said in one of the followups to this thread.
Hint should be included in original posting.  It has original make 
commands that I used plus a simple example for testing.  It also has 
instructions on how to build and run the simple sample

Modified build commands would be ./configure; make 
LDFLAGS="/usr/lib/automode.o"

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: flex and dos source files. How is flex built for cygwin

[Peter Rehley]

On Nov 20, 2004, at 12:07 AM, Reini Urban wrote:
Peter Rehley schrieb:
Peter Rehley wrote:
Larry Hall wrote:
We have a customer that is using flex under a custom version of 
cygwin that we provided them (with source).  The customer is 
having problems when their "*.l" files are in dos format.  Flex is 
taking the lines from the file and adding them into the lex.yy.c 
file untouched.  (i.e. they still have the \n\r at the end), and 
this causing problems later on.

I tried using the version of flex that comes with the latest 
version of cygwin (1.5.12) and flex changes the \n\r to just \n, 
which makes everything work fine.  Good I thought since the 
version of flex we provide is not the latest.  I'll just 
recompile.

But when I tried that with the latest flex (2.5.4a-3) I get the 
same behavior that the customer is seeing.  I get this behavior 
even if I compile on the latest version of cygwin.

So, my question is what options are used for building flex?
there's no build script and an inactive maintainer. we don't know. 
hopefully just the standard options.
./configure --prefix=/usr sharedstatedir=/var --mandir=/usr/share/man
make && make install
Using these options the behavior of flex differs from the flex that is 
shipped with cygwin.


Linking against /usr/lib/binmode.o perhaps?
He meant that by accident flex was linked against binmode.o, which is 
wrong. It was no advice to reproduce that error with linking against 
binmode or textmount.

Tried on cygwin 1.5.12
make clean
make LDFLAGS="/usr/lib/binmode.o",
and
make clean
make LDFLAGS="-lbinmode"
but neither helped
for sure not.
However linking the /usr/lib/textmode.o did work
make LDFLAGS="/usr/lib/textmode.o" # <- did the job
Thanks Larry for pointing me in the right directory :)
Oh god. This was the right direction? Sorry no.
If you open your flex input file in a *textmode mount* \r\n will get 
converted, if you open that in a binmode mount it will not get 
converted.
$ man mount
The filesystem has been mounted in binmode, but  the flex that comes 
with cygwin translates the files.  Both flex and the text file are on 
binmode mounts.

So it's entirely a user problem behind the keyboard, and does NOT need 
a changed linker line. Just tell the user to set this mount to 
textmode, so that his DOSEOL will get converted. Or convert the DOSEOL 
by basic commands like unix2dos.
Yes, there are things that the user can do to work around the problem, 
like saving the file as a unix file, and he is already using dos2unix.  
However when  I was doing research on this problem I found that the 
flex that comes with a standard cygwin distribution does the \r\n to \n 
translation when the directory is mounted in binmode.

When I compile flex, it doesn't do the translation.  If the flex that 
came with cygwin didn't do the translation, there would be no 
questions, but since it does something different, I wanted to know how 
it was compiled because it was obviously compiled differently.  Larry 
offered a suggestion that led me to the solution that flex had been 
linked with /usr/lib/textmode.o, because when I use that option I get 
the same behavior that I see with the flex shipped with cygwin.

It could be that the maintainer of flex used /usr/bin/textmode.o to 
ensure that dos files wouldn't cause problems.

But if you force linking against binmode or textmode, your flex binary 
will do no conversions at all, and will only work on the matching 
mount modes.
If I understand right, then a program linked with textmode won't do a 
translation in binmode? but this is not the behavior that I'm seeing
This is a pretty basic cygwin FAQ, and I wonder why this needs such a 
long and wrong consideration.
Just trying to figure why the flex packaged with cygwin behaves 
differently than one compiled on the system.
--
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Enjoy,
Peter
---
A Møøse once bit my sister
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: flex and dos source files. How is flex built for cygwin

[Peter Rehley]

Peter Rehley wrote:
Larry Hall wrote:
At 02:29 PM 11/19/2004, you wrote:
 

Hi,
We have a customer that is using flex under a custom version of 
cygwin that we provided them (with source).  The customer is having 
problems when their "*.l" files are in dos format.  Flex is taking 
the lines from the file and adding them into the lex.yy.c file 
untouched.  (i.e. they still have the \n\r at the end), and this 
causing problems later on.

I tried using the version of flex that comes with the latest version 
of cygwin (1.5.12) and flex changes the \n\r to just \n, which makes 
everything work fine.  Good I thought since the version of flex we 
provide is not the latest.  I'll just recompile.

But when I tried that with the latest flex (2.5.4a-3) I get the same 
behavior that the customer is seeing.  I get this behavior even if I 
compile on the latest version of cygwin.

So, my question is what options are used for building flex?
  

Linking against /usr/lib/binmode.o perhaps?
 

Tried on cygwin 1.5.12
make clean
make LDFLAGS="/usr/lib/binmode.o",
and
make clean
make LDFLAGS="-lbinmode"
but neither helped
However linking the /usr/lib/textmode.o did work
make LDFLAGS="/usr/lib/textmode.o" # <- did the job
Thanks Larry for pointing me in the right directory :)

--
Larry Hall  http://www.rfk.com
RFK Partners, Inc.  (508) 893-9779 - RFK Office
838 Washington Street   (508) 893-9889 - FAX
Holliston, MA 01746

 



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: flex and dos source files. How is flex built for cygwin

[Peter Rehley]

Larry Hall wrote:
At 02:29 PM 11/19/2004, you wrote:
 

Hi,
We have a customer that is using flex under a custom version of cygwin that we provided 
them (with source).  The customer is having problems when their "*.l" files are 
in dos format.  Flex is taking the lines from the file and adding them into the lex.yy.c 
file untouched.  (i.e. they still have the \n\r at the end), and this causing problems 
later on.
I tried using the version of flex that comes with the latest version of cygwin 
(1.5.12) and flex changes the \n\r to just \n, which makes everything work 
fine.  Good I thought since the version of flex we provide is not the latest.  
I'll just recompile.
But when I tried that with the latest flex (2.5.4a-3) I get the same behavior 
that the customer is seeing.  I get this behavior even if I compile on the 
latest version of cygwin.
So, my question is what options are used for building flex?
   


Linking against /usr/lib/binmode.o perhaps?
 

Tried on cygwin 1.5.12
make clean
make LDFLAGS="/usr/lib/binmode.o",
and
make clean
make LDFLAGS="-lbinmode"
but neither helped
--
Larry Hall  http://www.rfk.com
RFK Partners, Inc.  (508) 893-9779 - RFK Office
838 Washington Street   (508) 893-9889 - FAX
Holliston, MA 01746 

 


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Apology

[Peter Rehley]

It's possible to deselect all (top level deselect), then select only 
cygwin and then download to local machine.  Then you would only have 
the package, setup wouldn't have installed it and you have what you 
need.

On Nov 15, 2004, at 9:56 AM, Darkfalz wrote:
Sorry about that last email, really. Please stop sending me abuse.
I'm just saying, it would be a good idea to have the zipped dll only 
as a quick and dirty download somewhere on the main page. Going 
through the installer can be a pain (when mirrors don't work etc) and 
then browsing through to deselect stuff when you only want the latest 
dll is just a lot of hassle.

Darkfalz
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Enjoy,
Peter
---
A Møøse once bit my sister
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

libiconv and am--refresh question

[Peter Rehley]

Hello,
I'm compiling libiconv-1.9.2-1 and it works fine.  However if I were  
touch aclocal.m4 (e.g hypothetically customize the file), I get the  
following error during the build option.

(cd .libs && rm -f libiconv.la && ln -s ../libiconv.la libiconv.la)
make[1]: Leaving directory  
`/opt/montavista/host/src/montavista/BUILD/libiconv/libiconv-1.9.2/ 
.build/lib'
cd srclib && make all
make[1]: Entering directory  
`/opt/montavista/host/src/montavista/BUILD/libiconv/libiconv-1.9.2/ 
.build/srclib'
make[2]: Entering directory  
`/opt/montavista/host/src/montavista/BUILD/libiconv/libiconv-1.9.2/ 
.build'
make[2]: *** No rule to make target `am--refresh'.  Stop.
make[2]: Leaving directory  
`/opt/montavista/host/src/montavista/BUILD/libiconv/libiconv-1.9.2/ 
.build'
make[1]: ***  
[/opt/montavista/host/src/montavista/BUILD/libiconv/libiconv-1.9.2/ 
srclib/Makefile.in] Error 1
make[1]: Leaving directory  
`/opt/montavista/host/src/montavista/BUILD/libiconv/libiconv-1.9.2/ 
.build/srclib'
make: *** [all] Error 2

I've checked the makefiles and there is no rule anywhere for  
am--refresh.  There are references for it that were added from a patch  
that gets applied during prep phase.  Is there suppose to be user  
interaction in this case?  and if so what are the commands that one  
would need to do to fix this problem?  If this should be handled  
automatically, would this be considered a bug?

The commands that I used to get this error message are after untarring  
package:
./libiconv-1.9.2-1.sh prep
touch libiconv-1.9.2/aclocal.m4
./libiconv-1.9.2-1.sh conf
./libiconv-1.9.2-1.sh build

I'm including also the gzip of the above output.
Enjoy,
Peter
---
A Møøse once bit my sister


libiconv.log.gz
Description: GNU Zip compressed data
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: File permission problem

[Peter Rehley]

This sound suspiciously like the files are on a FAT32 file partition.  
Are they?

On Sep 23, 2004, at 8:32 PM, <[EMAIL PROTECTED]> wrote:
Yes. But I have already export the environment variable "ntsec" and
restart cygwin. But chmod still doesn't work. Do I need to run any
server in order to activate the change?
Jacky
-Original Message-
From: Larry Hall [mailto:[EMAIL PROTECTED]
Sent: Friday, 24 September, 2004 10:52
To: Jacky Lam; [EMAIL PROTECTED]
Subject: Re: File permission problem
At 09:59 PM 9/23/2004, you wrote:
Dear all,
   I have try to generate a private key file so that I don't need
to enter password everytime I "ssh" to a remote machine. However, 
"ssh"
complaints me about the permission of key file. I don't know why
"chmod"
always return 666 or 444 even I want to change the file to 600 or 400.
   Does anymore have idea? Thanks.

Does this describe your situation?
Why doesn't chmod work?

--
Larry Hall  http://www.rfk.com
RFK Partners, Inc.  (508) 893-9779 - RFK Office
838 Washington Street   (508) 893-9889 - FAX
Holliston, MA 01746
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Enjoy,
Peter
---
A Møøse once bit my sister
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: special install

[Peter Rehley]

On Sep 23, 2004, at 11:36 AM, Igor Pechtchanski wrote:
On Thu, 23 Sep 2004, Peter Rehley wrote (heavily [snip]ped):
3) passwd file.  If the same users exist on each machine, then this 
isn't an
issue.
This is *wrong* (and is the main reason I'm sending this mesage,
actually).  WinNT/2k/XP machines have a notion of "SID" that they give 
to
each user.  That SID is different on different machines, even if the 
user
name is the same.  User SIDs are stored in /etc/passwd, so an 
/etc/passwd
from one machine will be useless on another.
D'oh.  I knew this.

However domain users would need to be added.  This could be done
before zipping cygwin directory.
Again, wrong.  Domain user SIDs are actually the same across the 
domain,
so the domain users in /etc/passwd will be ok.

Actually, I still think this would be ok for domain users.  My point 
being that you need to add domain users at some point since the default 
setup doesn't create domain users.  However, the suggestions you and 
other have given regarding the creation of the passwd file is the right 
way to go.

Enjoy,
Peter
---
A Møøse once bit my sister
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: special install

[Peter Rehley]

On Sep 23, 2004, at 10:54 AM, Dave Korn wrote:
-Original Message-
From: cygwin-owner On Behalf Of Peter Rehley
Sent: 23 September 2004 18:44

  Much snippage, just to summarize the essence of the post and it's 
role in
the conversation:

After you have a working installation on any computer, you can zip and
copy the C:\CYGWIN directory.  It is totally self contained, and
should work fine anywhere.


2) post-install scripts have already be run via initial
setup.

  So, in other words, what you're claiming is that
"It would work, but it won't create any mount points in the registry, 
nor
will it run any post-install scripts".
ummm, I'm saying that the post install scripts have already been run.  
And also giving suggestions on things that are missing.

  Well, thanks for that helpful clarification from the Department of
Redundancy Department!
Glad to be of service. Didn't I mention that before ;)

cheers,
  DaveK
--
Can't think of a witty .sigline today

Enjoy,
Peter
---
A Møøse once bit my sister
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: special install

[Peter Rehley]

On Sep 23, 2004, at 10:32 AM, Dave Korn wrote:
-Original Message-
From: cygwin-owner On Behalf Of J. David Boyd
Sent: 23 September 2004 18:16

"Calman, Jack" writes:
Hi,
 Our group is interested in installing cygwin on a group of
classified
computers that are not connected to the internet. Would you
please tell me
how to download what I need from the internet. Then I'll
put it on a CD,
carry it into the classified room, and then install on the
computers there.
 Thanks,
 - Jack Calman
Johns Hopkins University
Applied Physics Lab
Laurel, MD

After you have a working installation on any computer, you can zip and
copy the C:\CYGWIN directory.  It is totally self contained, and
should work fine anywhere.
  Nonsense!  That method won't create any mount points in the 
registry, nor
will it run any post-install scripts.  The correct method is to run
setup.exe, select 'Download from internet', download everything, burn 
the
temporary storage directory to cd along with a copy of setup.exe, then 
on
each enduser machine you run setup.exe and tell it to 'Install from 
local
directory', pointing at the download dir that you burnt to CD.
Actually, what the person mention would work.  Only thing left out 
would be the registry settings.  If the user has a working copy then 
everything is already set up in the cygwin directory.  Copying this to 
another machine would be perfectly fine.  I know because I've done 
something like this before and it has worked for me.

Potential problems could arise in
1) Registry settings.  These would need to be exported.  Actually, I 
think if they don't exist cygwin will create registry setting minus the 
mount points.  The mount points would need to be adjusted or imported 
from the original.  This could also be part of the zip file.
2) post-install scripts have already be run via initial setup.  However 
something would need to be done if any of the programs are set up as 
windows services.
3) passwd file.  If the same users exist on each machine, then this 
isn't an issue.  However domain users would need to be added.  This 
could be done before zipping cygwin directory.

cheers,
  DaveK
--
Can't think of a witty .sigline today

Enjoy,
Peter
--
A Møøse once bit my sister
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: apache2 as service

[Peter Rehley]

On Sep 17, 2004, at 3:11 PM, Igor Pechtchanski wrote:
On Fri, 17 Sep 2004, Prakash Khemani wrote:
Check the windows event viewer for more logs.
Windows event viewer has errors saying that the cygapache service
terminated unexpectedly.
What, no more information?
Actually, this is pretty normal.  Sometimes you might catch something.  
But in my experiences, those times have been rare.

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: So how do you uninstall Cygwin?

[Peter Rehley]

On Sep 17, 2004, at 12:11 PM, Dave Korn wrote:
-Original Message-
From: cygwin-owner On Behalf Of Igor Pechtchanski
Sent: 17 September 2004 19:50

FWIW, I have been thinking of implementing a --list option to
cygrunsrv
that would list all the Cygwin services installed with
cygrunsrv.  At this
point I have no implementation, though.
  Rather than run through the list of services and try and deduce 
which ones
are cygwin services, the simplest implementation might just be for 
cygrunsrv
to add a 'created_by_cygrunsrv' value into the service key in
HKLM/CCS/Services, which it can come back and look for later.
Looking for cygrunsrv is usually good enough.
cheers,
  DaveK
--
Can't think of a witty .sigline today
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

A Møøse once bit my sister
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: So how do you uninstall Cygwin?

[Peter Rehley]

On Sep 17, 2004, at 11:50 AM, Igor Pechtchanski wrote:
On Thu, 16 Sep 2004, Brian Dessent wrote:
lukekendallcisracanoncomau wrote:
  ^^
Tut-tut.  . ;-)
It occurred to me, while trying to work out why ssh isn't working on 
a
laptop that we installed Cygwin on recently, to wonder whether the
information at http://cygwin.com/faq/faq_2.html#SEC19 (How do I 
uninstall
all of Cygwin?) could be a little more helpful.

It gives good advice, but ends by saying:
It's up to you to deal with other changes you made to your
system, such as installing the inetd service, altering system
paths, etc. Setup would not have done any of these things
for you.
This is true.  But for ssh, and other packages, is there any useful
advice that could be given on how to uninstall?
I'm wondering how I get the machine back into a pristine state to 
try a
re-install, since perhaps some of our post-install changes screwed
things up.  (ssh normally works just fine.)
Remove any services you might have installed ("cygrunsrv -R ssh") and
FWIW, I have been thinking of implementing a --list option to cygrunsrv
that would list all the Cygwin services installed with cygrunsrv.  At 
this
point I have no implementation, though.
Another feature that would be helpful is an option to show what program 
and the options associated with the program.  It would prevent hunting 
through the registry when debugging problems.


remove all entries from the mount table ("umount -a") and that should
pretty much do it, assuming of course you removed the main 
installation
directory as well.
Well, one could always add an "Uninstall all" radio button to 
setup.exe's
action screen.   :-)
	Igor
--
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_		[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_		[EMAIL PROTECTED]
 |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski, Ph.D.
'---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Happiness lies in being privileged to work hard for long hours in 
doing
whatever you think is worth doing."  -- Dr. Jubal Harshaw

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

A Møøse once bit my sister
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: apache2 as service

[Peter Rehley]

On Sep 17, 2004, at 9:18 AM, Prakash Khemani wrote:
Hi,
I compiled & installed apache2 on cygwin+WinXP. I am able to use it 
fine
- but I am not able to install it as a service.

The run as User in the httpd.conf file is SYSTEM.
I installed apache2 asa service using the following command
cygrunsrv -I cygapache -p /usr/local/apache2/bin/httpd.exe -a "-k 
start"
-t auto

I'll assume that it seemed to install correctly.  As a quick simple 
sanity check try typing the command in a bash prompt and see what 
happens.  Make sure that starts ok.  If it goes to the background, you 
will need to find the parameter that keeps apache in the foreground.  
cygrunsrv needs this.  Otherwise it can say that the service has not 
started when it is running.

When I try to start it
cygrunsrv -S cygapache
I get the following error
cygrunsrv: Error starting a service: QueryServiceStatus:  Win32 error
1062:
The service has not been started.
Nothing is written to /var/log/cygaapche.log or to
/usr/local/apache2/log/error_log
Check the windows event viewer for more logs.  Might be nothing, but 
might also give hints to what may be happening.

The pid stored in httpd.pid changes but the httpd processes don't show
up on doing ps -ae
Almost sounds like apache wants to start, but is encountering a problem.
What am I doing wrong?
I compiled and installed apache2 as the network user ENG/khemani. I had
to change the permissions on apache2/logs directory to be able to run
apache2 as the user SYSTEM.
What more should I do?
Configuration problems.  File permissions.  Check them all.
Thanks,
Prakash
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

A Møøse once bit my sister
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Problem in Cygwin-X...

[Peter Rehley]

On Sep 16, 2004, at 10:38 PM, Moises Deangelo wrote:
Please
I installed cygwin in my windows 2000 with service pack 4.
I download the complete version of cygwin.
But the graphic interface does not work by any means
Cygwin-X does not run.
Any applications do not accuse no mistake, simply do not initiate.
Other introduce the following mistake:
RUN.EXE
ERROR: could not start C:\cygwin\usr\X11R6\xdvi -display 127.0.0.1:0.0
Can anybody help to do the graphic interface to work?
Have you checked out the following site?
http://x.cygwin.com/
My guess is that the X Server isn't running (did you do startx?)
Also, it's been said before, but check out
http://cygwin.com/problems.html
Peter
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Program terminates with "cygheap version mismatch detected"

[Peter Rehley]

On Sep 15, 2004, at 5:54 AM, Joshua Wright wrote:
Jörg Schaible wrote:
c:\DEV\testing\asleap.exe (988): *** cygheap version mismatch 
detected - 0x6178/0xBF. You have multiple copies of 
cygwin1.dll on your system.

From your cygcheck output I've seen that you have or had a B15
running ... do you still use it? Even it the dll name is cygwin.dll
(just a guess, B15 was not my time ), it might already allocate
the same shared memory than cygwin1.dll.
I tried to remove all instances of Cygwin from my system in an effort 
to troubleshoot:
 + Did a find with regedit and removed any keys with "cyg" in them
 + Removed the c:\cygwin tree
 + Did a Windows Find on "cyg" and removed all files

Reinstalled cygwin, rebooted.  Same error. :(
Any other thoughts?  Possibly a problem with Windows XP SP2?  I'm not 
sure what to try next
Maybe off the wall, but keep the program that you are trying to run.  
Remove the cygwin tree (c:\cygwin) and then try running the exe again.  
See what happens.  If the program runs, then there is a cygwin1.dll 
outside of the tree.  Check the path that the program uses to see where 
the dll might be lurking.

Could the dll have a different name then cygwin1?  Where I work we've 
created a special dll with a different name to prevent cross over 
problems from the regular cygwin dll.  When running a regular cygwin 
program in this custom space (i.e. start from bash in custom 
environment) the error message you've seen appears.

Again off the wall things to try and check.
Peter
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: can't open file for writing

[Peter Rehley]

On Sep 3, 2004, at 2:33 PM, C Schreiner wrote:
I can not save to a nonexistant file name under
Cygwin, but I can under Windows.
When I type:
   cat "hello" > foo.txt
Does the file "hello" exist?  Try echo "hello" > foo.txt
under Cygwin I get this error message:
   bash: foo.txt: No such file or directory
(unless foo.txt already exists in the current
directory).  This only happens with network
filesystems.  I know I have write permission because I
can create the file with "touch foo.txt", and I can
create the files with Windows Wordpad.  Other programs
under Cygwin also cannot create files, such as vim,
and co (from the rcs package).  Things work fine for
all programs on the local C: drive.
Why does this problem occur under Cygwin?  Is there
maybe a workaround?
I have not seen anything about this in the Cygwin FAQ
or in two mailing list archive searches.  If there is
already documentation about this, please point me to
it.
I am using Windows XP professional 5.1.2600 SP 1.0,
and Cygwin DLL version 1.5.10-3 (setup program version
2.427).
Thank you for your consideration,
Christian Schreiner
caschreirc (at) yahoo (dot) com
__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: how to re-build Cygwin core package?

[Peter Rehley]

Might we be able to update the FAQ with this information?
On Aug 26, 2004, at 11:22 PM, Gernot Hillier wrote:
Hi!
Am Mittwoch, 25. August 2004 13:07 schrieb Gernot Hillier:
how to re-build Cygwin core package?
Just as reference for others - I now did it this way:
1.  Install Cygwin 2004-06-24, start bash
2.  Unpack the Cygwin core source package:
tar xvjf /cygdrive/e/release/cygwin/cygwin-1.5.10-3-src.tar.bz2
3.  Apply the needed patch (from
http://www.cygwin.com/ml/cygwin-patches/2004-q3/msg00039.html):
cd cygwin-1.5.10-3/winsup/cygwin && patch -p0 < /path/to/root.diff
4.	It's necessary to build Cygwin in an extra path, so create one and 
change
to it:

cd ../../.. && mkdir obj && cd obj
5.	To avoid Cygwin to overwrite the files of your make environment, an 
install
prefix is used:

../cygwin-1.5.10-3/configure --prefix=/fake/usr --sysconfdir=/fake/etc 
\
 --libexecdir=/fake/usr/sbin --localstatedir=/fake/var \
 --datadir=/fake/usr/share --mandir=/fake/usr/share/man \
 --infodir=/fake/usr/share/info

6.	Build and install the new Cygwin to the install prefix path given 
above:

make && make install
7.  Remove debug symbols from all executables:
cd /fake && find . -type f -exec strip {} \;
8.  Correct some file locations:
mv  usr/i686-pc-cygwin/bin/* usr/bin/
mv  usr/i686-pc-cygwin/lib/* usr/lib/
rm -rf usr/i686-pc-cygwin/bin usr/i686-pc-cygwin/lib usr/etc
mv  usr/i686-pc-cygwin/* usr/
9.  Create the w32api package:
tar cjf w32api-20040624-1.tar.bz2 usr/include/w32api usr/lib/w32api
10. Remove the files which belong to the w32api package from our tree:
rm -rf /fake/usr/include/w32api /fake/usr/lib/w32api
11. Create the mingw-runtime package:
tar cjf mingw-runtime-20040624-1.tar.bz2 usr/bin/mingwm10.dll \
   usr/doc/mingw-runtime usr/include/mingw usr/lib/mingw
12. Remove the files which belong to the w32api package from our tree:
rm -rf /fake/usr/bin/mingwm10.dll /fake/usr/doc/mingw-runtime \
   /fake/usr/include/mingw /fake/usr/lib/mingw
13.	Remove files which are distributed with other packages (but are 
included
in the cygwin source package for boot-strapping) or should not be 
distributed
at all:

rm -rf /fake/usr/include/iconv.h # comes also with libiconv
rm -rf /fake/usr/include/unctrl.h # comes also with libncurses-devel
rm -rf /fake/usr/share/info/configure.info-1 # auto-created by info 
tool
rm -rf /fake/usr/lib/libiberty.a # comes also with binutils

14.	Three files were not built and would need extra effort (i.e. 
compiling
other libraries be-fore the Cygwin package). Take them from the already
installed Cygwin distribution:

cp /usr/bin/dumper.exe usr/bin/
cp /usr/share/info/libc.info usr/share/info/
cp /usr/share/info/libm.info usr/share/info/
15. Finally, the cygwin package itself can be created:
tar cjf cygwin-20040624-1.tar.bz2 etc/ usr/
16.	Now, the created packages can be moved to the Cygwin installation 
CD-ROM
to release/cygwin/, release/mingw-runtime/ and release/w32api/ and the 
file
names, sizes and md5sums in setup.ini modified accordingly so that 
setup.exe
will in-stall the new core packages in the future.

HTH anyone...
--
Bye,
Gernot Hillier
CT SE 2
Siemens AG, Mch P
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: problem starting the server in an XP account other than the one installing cygwin

[Peter Rehley]

On Aug 23, 2004, at 10:56 AM, Congwu Cui wrote:
I just installed cygwin in xp. I found that the X server could not be
started in any acccount other than that in which it is installled, 
even the
the account is an admistrator one. what do i need to do? thanks a lot. 
I am
new to this software.

You need to read http://cygwin.com/problems.html.  This provides 
guidelines as to what to provide when having problems with cygwin.


Yours,
Congwu Cui

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Question about moving cygwin to another dirve

[Peter Rehley]

On Aug 16, 2004, at 9:43 PM, Yihu Li wrote:
Dear all,
My c drive does not have enough space, so I just copyed the whole 
folder of cygwin to another drive and expect to run it there. It 
worked but the problem is that the default folder is still under 
c:/cygwin, not the new one g:/cygwin. Anyone knows how to map it to 
the new drive?
Change the mount information in the registry
Thanks a lot.
Yihu

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: How To Export NFS?

[Peter Rehley]

I'm going start off by stating the obvious.  After starting the 
daemons, make sure that they are really running.  After the mount do 
the check again.  Make sure that you can ping the box you want to 
access.

Try removing the broadcast and submask from the exports file.
If everything seems to be running, then stop the daemons and start them 
again with debugging turned on.  You'll need two bash windows opened 
for this.
rpc.mountd -F -d all
rpc.nfsd -F -d all

This will run the commands in the foreground and show all messages.  If 
you don't need all messages don't use -d all.

When running as a back ground process, you can check the log messages 
in the Event Viewer or /var/log/*.log

On your linux machine, check the log files also.
If you already got this to work.. Good job, what did you do.
Peter
On May 14, 2004, at 6:26 AM, Baurjan Ismagulov wrote:
Hello, Jack!
On Thu, 13 May 2004, Jack Polimer wrote:
I'm trying to export an NFS filesystem under cygwin to
a Linux machine on the same network, but I get"
# mount -t nfs 10.0.0.1:/etc /mnt
mount: RPC: Timed out
The client is not getting anything from the remote portmapper. Try
"rpcinfo -p 10.0.0.1" and "showmount -e 10.0.0.1". If this does not
help, investigate with tcpdump/ethereal on both ends.
With kind regards,
Baurjan.
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

=
Infinity Softworks.  Making scientific, financial and realtor 
calculators for Palm Pilots and other PDAs since 1997

Visit them today at http://www.infinitysw.com
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Cywin Setup application not able to maximise

[Peter Rehley]

Greg McCrory wrote:

At 3/5/2004 04:08 PM, you wrote:

> -Original Message-
>
>Michael John
> Sent: Friday, March 05, 2004 4:51 PM
> Subject: Cywin Setup application not able to maximise
>
>
> Hi,
>
> i'm using Cygwin for more than half a yeah now. Admittedly, i
> find it very
> impractical not being allowed to resize, respectively maximize, the 
setup
> application, because the tree of packages to install is much to
> large for the
> window.
>
> Is this intended? Differently asked, is there a projected time to
> change this
> behaviour?
>

A search of the archives will prove instructive

Ken


Actually, a search of the archives will prove futile, as the standard 
response is, "if you want a better setup, code it yourself."  Since 
most of the people asking this question are a bit green in their 
programming skills, and in fact may be complete neophytes, the 
response to "code it yourself" is somewhat cold.

How about a kinder, gentler response like, "we are trying to find 
someone with the skill and will to re-code the setup program to 
provide for window resizing, but as of yet have no takers."

GMc
But that would violate the cygwin slogan "Because We Are Mean"

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: two versions

[Peter Rehley]

On Wednesday, September 3, 2003, at 12:22  PM, Rolf Campbell wrote:

Eduardo Osorio Armenta wrote:

Hi,
i want to test cygwin 1.5.X
but not break my set cygwin 1.3.22
so i wonder if installing cygwin 1.5.X in
another path e.g. c:\cygwin_1.5
and configuring all the PATH to my shell (cygwin.bat)
to only include c:\cygwin_1.5\bin (and all related)
would not interfere with my cygwin 1.3.22
it's that posible?
Not really.

or the registry stuff will prevent this!
Bingo.

You can do it if you switch mount tables/paths when you switch between 
versions.
One thing that you can do ( I do this at work because I'm working with 
multiple versions of cygwin for a project we are working) is to rename 
your 1.3.22 to something like cygwin_1_3_22 and then install the latest 
version.  You may want to back up your registry settings just in case 
the installer changes them, but I don't think that it does.

Once you have everything installed, just rename the directory for the 
version you want to use and launch your programs.  You will need to 
make sure that no cygwin application is running before you switch or 
windows will complain about renaming the directory.  I don't have the 
change the registry because that will always be pointing to the cygwin 
that I want to use.

It won't let you run multiple version of cygwin at the same time, but I 
don't think you are trying to do that.

Peter

Infinity Softworks.  Making scientific, financial and realtor 
calculators for Palm Pilots and other PDAs since 1997

Visit them today at http://www.infinitysw.com

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: help running tftpd under winXP

[Peter Rehley]

It will run as an inetd process.  The code would need to be changed to 
allow it to run as a windows services.
On Thursday, July 3, 2003, at 09:57  AM, Vince Hoffman wrote:

will it run under inetd rather than as a stand alone service ? (since 
it has
a commented entry in inetd.conf)

-Original Message-
From: Rajesh Gottlieb [mailto:[EMAIL PROTECTED]
Sent: 03 July 2003 17:40
To: [EMAIL PROTECTED]
Subject: Re: help running tftpd under winXP
There's nothing in /var/log/tftpd.log

Here's what the windows "event viewer" logs show. They might
be informative,
but they still don't help me much.
System logs:

first entry:
The tftpd service was successfully sent a start control
second entry:
The tftp service entered the stopped state
Application logs:

first entry:
The description for Event ID ( 0 ) in Source ( tftpd ) cannot
be found. The
local computer may not have the necessary registry
information or message DLL
files to display messages from a remote computer. You may be
able to use the
/AUXSOURCE= flag to retrieve this description; see Help and
Support for
details. The following information is part of the event:
tftpd : PID 2656 :
ioctl(FIONBIO): Invalid argument.
second entry:
The description for Event ID ( 0 ) in Source ( tftpd ) cannot
be found. The
local computer may not have the necessary registry
information or message DLL
files to display messages from a remote computer. You may be
able to use the
/AUXSOURCE= flag to retrieve this description; see Help and
Support for
details. The following information is part of the event:
tftpd : PID 1896 :
starting service `tftpd' failed: execv: 1, Operation not permitted.
third entry:
The description for Event ID ( 0 ) in Source ( tftpd ) cannot
be found. The
local computer may not have the necessary registry
information or message DLL
files to display messages from a remote computer. You may be
able to use the
/AUXSOURCE= flag to retrieve this description; see Help and
Support for
details. The following information is part of the event:
tftpd : PID 1896 :
`tftpd' service stopped.
__
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/


=

Infinity Softworks.  Making scientific, financial and realtor 
calculators for Palm Pilots and other PDAs since 1997

Visit them today at http://www.infinitysw.com

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: 1.3.19-1:poll bug. Patch included.

[Peter Rehley]

Hello,

Just to make sure that we are both clear.  Change recvfrom so that if 
the buffer is too small it returns the number of bytes that can be 
written into the buffer instead of setting errno.  Also clear errno 
since there is no error.

Now in poll since we will now be returning the number of bytes instead 
of -1, do we will need to check for WSAEMSGSIZE?  I don't think so 
because that will now be handled in recvfrom.

Is this correct?

Peter

On Sunday, February 2, 2003, at 07:03  PM, Christopher Faylor wrote:

On Sun, Feb 02, 2003 at 06:37:34PM -0800, Peter Rehley wrote:

Hello,

While working on another program (syslogd in inetutils) I found that
the poll function was returning POLLERR when something arrived on a 
UDP
socket; it should be return POLLIN.  Inside the poll function, 
recvfrom
was returning -1 with errno = EMSGSIZE, but the only error value being
check for in WSAENOTCONN.  However EMSGSIZE is a reasonable return
value since the buffer to recvfrom was only 1 byte while the actual
message size was larger than this.  Basically saying your buffer is 
too
small for the message, but since we are only peeking, this shouldn't 
be
returned as a POLLERR.

The fix should be to add EMSGSIZE as part of the condition so this
error returns POLLIN.  I'm including the patch below and a changelog
following that.  Please review these changes and make sure that they
seem reasonable.  I've done tests on my system (windows XP) and have
verified that the change works.

Thanks for the patch.  Would you mind reworking it so that it doesn't 
set
errno at all in the case that you describe and then check against the 
correct
WSAGetLastError value?

cgf

Patch
---
Index: winsup/cygwin/poll.cc
===
RCS file: /cvs/src/src/winsup/cygwin/poll.cc,v
retrieving revision 1.34
diff -u -p -r1.34 poll.cc
--- winsup/cygwin/poll.cc	20 Nov 2002 11:00:15 -	1.34
+++ winsup/cygwin/poll.cc	3 Feb 2003 01:52:10 -
@@ -112,7 +112,8 @@ poll (struct pollfd *fds, unsigned int n
 sense then.  It returns WSAENOTCONN in that
 case.  Since that's not actually an error,
 we must not set POLLERR but POLLIN. */
-			  if (WSAGetLastError () != WSAENOTCONN)
+			  if (WSAGetLastError () != WSAENOTCONN &&
+  errno!=EMSGSIZE)
fds[i].revents |= POLLERR;
			  else
fds[i].revents |= POLLIN;
----------
Changelog
2003-02-02  Peter Rehley<[EMAIL PROTECTED]>

* poll.cc: EMSGSIZE being ignore returning incorrect POLLERR on UDP
socket receive
if recvfrom returns error, return POLLIN if errno = EMSGSIZE
---

Peter
=
Infinity Softworks.  Making scientific, financial and realtor
calculators for Palm Pilots and other PDAs since 1997

Visit them today at http://www.infinitysw.com


--
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/


--
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/




=

Infinity Softworks.  Making scientific, financial and realtor 
calculators for Palm Pilots and other PDAs since 1997

Visit them today at http://www.infinitysw.com


--
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/

1.3.19-1:poll bug. Patch included.

[Peter Rehley]

Hello,

While working on another program (syslogd in inetutils) I found that 
the poll function was returning POLLERR when something arrived on a UDP 
socket; it should be return POLLIN.  Inside the poll function, recvfrom 
was returning -1 with errno = EMSGSIZE, but the only error value being 
check for in WSAENOTCONN.  However EMSGSIZE is a reasonable return 
value since the buffer to recvfrom was only 1 byte while the actual 
message size was larger than this.  Basically saying your buffer is too 
small for the message, but since we are only peeking, this shouldn't be 
returned as a POLLERR.

The fix should be to add EMSGSIZE as part of the condition so this 
error returns POLLIN.  I'm including the patch below and a changelog 
following that.  Please review these changes and make sure that they 
seem reasonable.  I've done tests on my system (windows XP) and have 
verified that the change works.

Patch
---
Index: winsup/cygwin/poll.cc
===
RCS file: /cvs/src/src/winsup/cygwin/poll.cc,v
retrieving revision 1.34
diff -u -p -r1.34 poll.cc
--- winsup/cygwin/poll.cc	20 Nov 2002 11:00:15 -	1.34
+++ winsup/cygwin/poll.cc	3 Feb 2003 01:52:10 -
@@ -112,7 +112,8 @@ poll (struct pollfd *fds, unsigned int n
  sense then.  It returns WSAENOTCONN in that
  case.  Since that's not actually an error,
  we must not set POLLERR but POLLIN. */
-			  if (WSAGetLastError () != WSAENOTCONN)
+			  if (WSAGetLastError () != WSAENOTCONN &&
+  errno!=EMSGSIZE)
 fds[i].revents |= POLLERR;
 			  else
 fds[i].revents |= POLLIN;
--
Changelog
2003-02-02  Peter Rehley<[EMAIL PROTECTED]>

* poll.cc: EMSGSIZE being ignore returning incorrect POLLERR on UDP 
socket receive
 if recvfrom returns error, return POLLIN if errno = EMSGSIZE
---

Peter
=
Infinity Softworks.  Making scientific, financial and realtor 
calculators for Palm Pilots and other PDAs since 1997

Visit them today at http://www.infinitysw.com


--
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/