RE: resolving _glgetstr...@4 by linking to _glGetString

[Jay K]

  > Not so much of an issue any more (still a bit curious about it, but). I 
soon 
  > found that providing a '-lopengl32' link instead of 
  > '/cygdrive/c/Windows/System32/opengl32.dll' fixed the problem. 


Linking to /cygdrive/c/windows/system32/whatever is "never" right.


It is not easy to explain this though.


In the "Unix model", the "headers and libraries" come with the operating system.
  /usr/include, /lib, /usr/lib, etc.


In the "Windows model", they come separately with the compiler or a 
"development kit".


The "Unix model" advantages:
   system is "self describing" 
   smaller: no separate "import libraries", just the dynamic libraries 


The "Windows model" advantages:
  Sort of more amenable to cross builds. Including targeting an older or newer 
OS release.


I say "sort of" because, like, adding additional headers and libraries doesn't 
change the model.
In the "Unix model", any headers/libraries apart from "the OS" are sort of 
following a different model,
where in the "Windows model", they are all following the same model.


This isn't the "Unix" or "Windows" model really, it is just how things tend to 
be done on those systems.
If you look at Mac OS X development systems, they are closer to Windows.
If you have ever used "sysroot" with gcc, well, that is like Windows then.


Personally I prefer the Windows model.
And Cygwin follows it, because, well, again, the main difference is if the 
operating system
contains the headers/libraries needed. Cygwin can be as Gnuy/Linuxy/Posixy as 
it wants, but
the operating system doesn't contain the files it needs, so it includes them.


Now, there is something funny to this term "libraries".
You know, modern systems are heavily dynamically linked, and the information 
needed
by the dynamic linker and the "static linker" is similar/same, in particular 
for the "static linker"
to build an executable or library that references symbols dynamically.
The main information is just a list of function names.
 Sometimes what library contains what function, depending on the system and 
compiler/linker flags.
 

Thus it becomes reasonable seeming to point at the "running code" for 
libraries, instead
of some separate libraries, sometimes called "stub libraries" or "import 
libraries", etc.
 (These "import libraries" basically just contain lists of function names, no 
actual code;
  older forms of them do contain a jmp per function, but that hardly counts.)


Now, then, what is the difference between the file -lopengl32 found, vs. 
/cygdrive/c/windows/system32/opengl32.dll?


Well, Windows on x86 does have something uniquely slightly bad about it: There 
are multiple calling conventions.
And the different calling conventions lead to a form of "name mangling", even 
in C code.


There are generally three calling conventions.
Though some compilers let you declare custom ones, e.g. I believe gcc and 
OpenWatcom.
As well the compiler can create custom calling conventions for "static" 
functions. That is a different more general point and
  true on many systems.


Anyway, the three usual Windows/x86 calling conventions are "stdcall", "cdecl", 
"fastcall".


"cdecl" is usually the default.
Parameters passed on the stack, right to left, callER pops, function "Foo" is 
"mangled" to "_Foo".


"stdcall" is heavily used.
Parameters passed on the stack, right to left, callEE pops, function "Foo" is 
"mangled" to "_...@n"
where "N" is the decimal number of bytes of parameters, e.g. 0, 4, 8, 16, etc.


"fastcall" I don't know entirely, but roughly speaking, it passes the first 8 
bytes of parameters in ecx, edx,
right to left, the rest on the stack, callEE pops, "Foo" becomes "_...@foo@N".


"cdecl" is "needed" for varargs i.e. printf, because caller pops.
"stdcall" is smaller/faster because callee pops.


Now, I said "stdcall" is heavily used.
Almost all public Windows functions (aka APIs) are stdcall.


So instead of generating a reference to " _glGetString", the compiler generates 
a reference to " _glgetstr...@4".


However presumably because it looks nicer or maybe for consistency with the 
other architectures, the exported
names are not "mangled" (or "decorated").
("other architectures": NT on MIPS, Alpha, PowerPC, IA64, AMD64, only one 
calling convention each)


If you run link -dump -exports %windir%\system32\opengl32.dll, you'll see plain 
"glGetString".
 There is no clear indication in the .dll that glGetString takes 4 bytes of 
parameters (maybe if you disassemble it...)


The file -lopengl32 found though, contains some stuff in it with both strings 
"_glgetstr...@4" and "glGetString".
The first is what symbol the linker should resolve against, the second is what 
it should stuck in the special data in the
file it is outputing.


Make sense?


(To repeat, I think distributing headers/libraries separate is good, but having 
multiple calling conventions is clearly mixed/bad.)


 - Jay
  

--
Problem reports:   http://

Re: 1.7.5 cannot bg mintty

[Andy Koppe]

On 30 May 2010 07:00, Christopher Faylor wrote:
> On Sat, May 29, 2010 at 11:32:23PM +0100, Andy Koppe wrote:
>>There's also another issue with the ^Z not taking effect immediately
>>due to signal handling being disabled while mintty waits for Windows
>>events, but that would require some fairly major restructuring to fix,
>>so leaving that for later.

Fixed in mintty 0.8-beta1, now available from mintty.googlecode.com.

>> Looking at rxvt, the right thing to do is a
>>select() on the pty device and /dev/windows instead of mintty's
>>current approach using multiple threads and
>>MsgWaitForMultipleObjects.)
>
> ...assuming that still works.  I wonder if anyone has used that
> interface in the last few years.
>
> But, then, I dunno.  Maybe rxvt uses it.

Yep, rxvt does use /dev/windows; I double-checked via /proc//fd.
XWin uses it too. It allowed getting rid of quite a bit of complexity
in mintty's I/O handling code.

Andy

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

Re: seteuid problem Win2003

[Corinna Vinschen]

On Jul  9 17:17, Vikentsy Lapa wrote:
> Hello, all.
> 
> I run simple seteuid programm which switch user context form user   admin   
> to user   UserDom1.
> 
> Programm output is
> $ ./t_seteuid.exe
> Process EUID: 11133
> seteuid failed:: Permission denied

That's a Windows limitation.

http://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-setuid-overview

Users in the administrators group don't have the right to switch the
user context without providing a password.  For method 1
(http://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-nopasswd1) the user
must hold the SE_CREATE_TOKEN_NAME privilege, for method 2 and 3
(http://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-nopasswd2
 http://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-nopasswd3) the user
needs the SE_TCB_NAME privilege.  These privileges are generally
only given to the SYSTEM user.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

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

[ANNOUNCEMENT] Updated: cppcheck-1.44-1

[Chris Sutcliffe]

Version 1.44-1 of cppcheck has been uploaded, following the upstream release.

cppcheck is a tool for static C/C++ code analysis.  It tries to detect
bugs that your C/C++ compiler don't see.
The goal is no false positives.

cppcheck is versatile. You can check non-standard code that includes
various compiler extensions, inline assembly code, etc.

For a list of changes see:

http://sourceforge.net/news/?group_id=195752&id=289096

*** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there. It will be in the format:

cygwin-announce-unsubscribe-you=yourdomain@cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is
available starting at this URL.


-- 
Chris Sutcliffe
http://emergedesktop.org
http://www.google.com/profiles/ir0nh34d

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

Re: XWin seg fault on Vista (cygwin 1.7)

[Peter Huang]

Xwin doesn't work with Windows XP as well. But when I update all X11 libraries 
(libxcb) from version 1.6-1 to 1.5-1, Xwin works.


--- On Fri, 7/9/10, Larry Hall (Cygwin)  
wrote:

> From: Larry Hall (Cygwin) 
> Subject: Re: XWin seg fault on Vista (cygwin 1.7)
> To: cygwin@cygwin.com
> Date: Friday, July 9, 2010, 10:06 AM
> On 7/9/2010 8:33 AM, Markus Moeller
> wrote:
> > Welcome to the XWin X Server
> > Vendor: The Cygwin/X Project
> > Release: 1.8.0.0 (1080)
> > Build Date: 2010-04-02
> >
> > Hi,
> >
> > I used cygwin with XWin for some time now with an
> older cygwin release.
> > I have upadted now to version 1.7 and get the
> following error:
> 
> This is a question that's more appropriate for the
> cygwin-xfree list.
> Please send it there and consult the problem reporting
> guidelines found
> here:
> 
> 
> 
> -- 
> Larry Hall             
>                 http://www.rfk.com
> RFK Partners, Inc.           
>           (508) 893-9779 - RFK
> Office
> 216 Dalton Rd.           
>               (508)
> 893-9889 - FAX
> Holliston, MA 01746
> 
> _
> 
> A: Yes.
> > Q: Are you sure?
> >> A: Because it reverses the logical flow of
> conversation.
> >>> Q: Why is top posting annoying in email?
> 
> --
> Problem reports:       http://cygwin.com/problems.html
> FAQ:               
>    http://cygwin.com/faq/
> Documentation:         http://cygwin.com/docs.html
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
> 
>


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

Re: Cygwin extremely slow after updating from 1.5.1 to 1.7.5

[Jet Thompson]

Huang Bambo  gmail.com> writes:

> 
> Use "strace ls" and "strace -t ls" and attach the output first.
> 

strace ls: http://pastie.org/1041010

strace -t ls: http://pastie.org/1041018

It is just on the first invocation ls is slow.
Bash starts up slow every time, and my Cucumber
test takes 6 minutes every time.

Cheers,

   Jet


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

Re: Cygwin extremely slow after updating from 1.5.1 to 1.7.5

[Jet Thompson]

Larry Hall (Cygwin  cygwin.com> writes:

> 
> On 7/11/2010 9:00 PM, Jet Thompson wrote:
> > It is now taking over 30 seconds for bash to come up,
> > whereas in 1.5 it would take 1-2 seconds.

> 
> This is typically the result of .
> 

Only program I had installed that was on the list was
SONIC DLA.

I removed this, but it had no effect.

Jet




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

Re: Cygwin extremely slow after updating from 1.5.1 to 1.7.5

[Matthias Andree]

Am 12.07.2010 03:00, schrieb Jet Thompson:
> It is now taking over 30 seconds for bash to come up,
> whereas in 1.5 it would take 1-2 seconds.
> 
> Doing an ls of my ~ directory takes 5 seconds.
> 
> Running a cucumber test takes 5-6 minutes.
> 
> Any idea what could be causing this?

Virus, Spyware and similar scanners, and broken software.

> At this point, I can not use Cygwin for development.
> Not feasible to use such a slow environment.
> 
> Hope someone may have some good ideas.
> I am using an older XP machine, but still it is
> dual 2.8 Xeon processors, 800MHz bus, 7200rpm
> sata hard drive with 8MB cache. It is painful
> to see such dismal performance.

ls isn't representative, as it uses stat() which is painfully slow on Cygwin.

If bash is slow to start, see if uninstalling bash-completion fixes it.
For me it helped quite a bit.

-- 
Matthias Andree

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

Re: Cygwin extremely slow after updating from 1.5.1 to 1.7.5

[Jet Thompson]

Matthias Andree  gmx.de> writes:

> If bash is slow to start, see if uninstalling bash-completion fixes it.
> For me it helped quite a bit.

Matthias,

I uninstalled bash-completion and it did indeed make a very substantial
improvement.
 
Thank you.

Jet





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

Sending SIGUSR1 to thread in nanosleep causes segfault

[James Cotton]

Hello, I've been trying to get the FreeRTOS Posix simulator to run on
Cygwin and have run into a few bugs in the signal handling/pthread
libraries and have isolated test cases

Essentially sending a SIGUSR1 to a pthread causes a segfault if that
thread is in sleep/nanosleep/select.  This behavior continues if you
comment out the printing behavior.

I believe at least nanosleep is meant to return when it receives a
signal so this seems like a bug.

Thanks,
James


test_case_1_sleep.c
Description: Binary data


test_case_2_nanosleep.c
Description: Binary data


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

pthread_mutex_lock doesn't interrupt

[James Cotton]

Hello, I've been trying to get the FreeRTOS Posix simulator to run on
Cygwin and have run into a few bugs in the signal handling/pthread
libraries and have isolated test cases

I believe when pthread_mutex_lock receives an interrupt it should run
it then resume trying to get a lock, the signal handler appears to
never run (at least as inferred by no output.  I tried running under
cygwin gdb but get uniformative backtraces).

Thanks,
James


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

Re: pthread_mutex_lock doesn't interrupt

[Larry Hall (Cygwin)]

On 7/12/2010 12:56 PM, James Cotton wrote:

Hello, I've been trying to get the FreeRTOS Posix simulator to run on
Cygwin and have run into a few bugs in the signal handling/pthread
libraries and have isolated test cases

I believe when pthread_mutex_lock receives an interrupt it should run
it then resume trying to get a lock, the signal handler appears to
never run (at least as inferred by no output.  I tried running under
cygwin gdb but get uniformative backtraces).


Did you build a debuggable Cygwin DLL or download one from
?

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

_

A: Yes.

Q: Are you sure?

A: Because it reverses the logical flow of conversation.

Q: Why is top posting annoying in email?


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

[ANNOUNCEMENT] Updated: vorbis-tools-1.4.0-1

[David Rothenberger]

A new version of the vorbis-tools package is now available for
download.

NEWS:
=
This is a new upstream release. Please see the Changes attachment
below for more details.

DESCRIPTION:

vorbis-tools contains oggenc (an encoder) and ogg123 (a playback
tool). It also has vorbiscomment (to add comments to vorbis files),
ogginfo (to give all useful information about an ogg file, including
streams in it), oggdec (a simple command line decoder), and vcut
(which allows you to cut up vorbis files).

DOWNLOAD:
=
Note that downloads from sources.redhat.com (aka cygwin.com) aren't
allowed due to bandwidth limitations.  This means that you will need to
find a mirror which has this update, please choose the one nearest to
you: http://cygwin.com/mirrors.html

QUESTIONS:
==
If you want to make a point or ask a question the Cygwin mailing list is
the appropriate place.

CYGWIN-ANNOUNCE UNSUBSCRIBE INFO:
=
To unsubscribe to the cygwin-announce mailing list, look at the
"List-Unsubscribe: " tag in the email header of this message.  Send
email to the address specified there.  It will be in the format:

cygwin-announce-unsubscribe-you=yourdomain@cygwin.com

If you need more information on unsubscribing, start reading here:

http://sources.redhat.com/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.

-- 
David Rothenberger    daver...@acm.org

College:
The fountains of knowledge, where everyone goes to drink.
vorbis-tools 1.4.0 -- 2010-03-25

 * Implement corrected channel mappings for all input and playback file types
 * Correct an possible infinite loop in WAV input reading code when header is 
corrupt
 * Implement disable_coupling option for oggenc
 * Fix Ctrl-C lockup bug in ogg123
 * ogg123 playback in sorted order
 * Add WAVEFORMATEXTENSIBLE support
 * More translations
 * Add '-' as stdin/out filename in vcut
 * Add -lnetwork check for socket in configure
 * Remove 'extra' F parameter from ogg123 remote output

vorbis-tools 1.3.0 -- Unreleased

 * Fixed an error in configure.ac; --with-speex/flac work again (#1319)
 * Corrected problems in the Visual Studio project files
 * Updated po files from the Translation Project
 * Added new en_GB.po, eo.po, pl.po, sk.po and vi.po translation files
 * Added AC_USE_SYSTEM_EXTENSIONS to configure.ac; no more configure warnings
 * Corrected SUBLANG values in intl/localename.c (#1415)
 * Change -v to -V on oggenc and oggdec for consistency (#1112)
 * Fix for utf8_decode in Windows; improves behavior in vorbiscomment (#268)
 * Updated gettextize to version 0.17
 * ogg123: backported fix from libfishsound to patch the Speex decoder (#1347)
 * ogg123: fixed CPU issue when outputting to a closed pipe (#1357)
 * ogg123: return value to stop decoding after buffer is shut down (#1357)
 * ogg123: support for ReplayGain; requires libvorbis 1.2.1 or later (#381)
 * ogg123: unset non-blocking mode on stderr
 * oggdec: gettextized help text (#1385)
 * oggdec: gettextized all strings
 * oggdec: call ov_open_callbacks instead of ov_open; it works on Windows now
 * oggenc: fixed a core dump while resampling from FLAC (#1316)
 * oggenc: fixed a typo in the Skeleton handling routine
 * oggenc: fixed remapping channels bug (#1326)
 * oggenc: support for WAVE_FORMAT_EXTENSIBLE headers (#1326)
 * oggenc: support for 32 bit Wave files (#1326)
 * oggenc: --ignorelength; support for Wave files > 4 GB (#1326)
 * oggenc: split help text into manageable chunks to help translators (#1385)
 * oggenc: --utf8 command similar to vorbiscomment's --raw (#268)
 * oggenc: fixed the encoding of extended characters in Windows (#268)
 * oggenc: validate raw UTF-8 sent to oggenc (#268)
 * oggenc: include the PID in the RNG seed to get a unique serial (#1432)
 * oggenc: lyrics support using .lrc as source; requires libkate (#1403)
 * ogginfo: support for information in Kate streams (#1360)
 * vcut: 64 bit fixes (#1366)
 * vcut: support for chained streams (#1455)
 * vorbiscomment: correct memory allocation (#472)
 * vorbiscomment: validate raw UTF-8 sent to vorbiscomment (#268)
 * vorbiscomment: fix segfault when using --tag (#1439)
 * vorbiscomment: round-trip multi-line comments (#273)

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

[ANNOUNCEMENT] New: libtheora-1.1.1-2

[David Rothenberger]

New packages providing Xiph.Org's Theora video codec are now
available for download.

DESCRIPTION:

Theora is Xiph.Org's first publicly released video codec, intended
for use within the Ogg's project's Ogg multimedia streaming
system. Theora is derived directly from On2's VP3 codec; Currently
the two are nearly identical, varying only in encapsulating decoder
tables in the bitstream headers, but Theora will make use of this
extra freedom in the future to improve over what is possible with
VP3.

DOWNLOAD:
=
Note that downloads from sourceware.org (aka cygwin.com) aren't
allowed due to bandwidth limitations.  This means that you will need
to find a mirror which has this update, please choose the one
nearest to you: http://cygwin.com/mirrors.html

QUESTIONS:
==
If you want to make a point or ask a question the Cygwin mailing list is
the appropriate place.

CYGWIN-ANNOUNCE UNSUBSCRIBE INFO:
=
To unsubscribe to the cygwin-announce mailing list, look at the
"List-Unsubscribe: " tag in the email header of this message.  Send
email to the address specified there.  It will be in the format:

cygwin-announce-unsubscribe-you=yourdomain@cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.

-- 
David Rothenberger    daver...@acm.org

College:
The fountains of knowledge, where everyone goes to drink.

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

Re: License violation: gpsd4win

[Corinna Vinschen]

On Jul 11 22:56, Yaakov S wrote:
> http://code.google.com/p/gpsd-4-win/
> 
> This project provides an installer containing cygwin1.dll and at least a
> Base installation.  The project's SVN repo also contains the same
> binaries.  Nowhere are sources to Cygwin or any other package provided. 

Thanks, Yaakov.  I'll have a look.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

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

Re: Tab Completion Problem

[Jacob Jacobson]

On 7/9/2010 2:16 PM, Jacob Jacobson wrote:

On 7/8/2010 9:08 AM, Jacob Jacobson wrote:

I recently updated my Cygwin installation and now I get,

[~$:501] cd /c/home/bash: exclude: unbound variable
[~$:501]

when I hit TAB.

I have seen Eric's announcement & followed that.

>> A new release of bash-completion, 1.2-1, is now available for
>> download, leaving 1.1-2 as previous.

>> NEWS:
>> =
>> This is a new upstream release.

I put -
. /etc/bash_completion in my .bashrc file.

The file /etc/bash_completion exists.

Cygcheck output attached. Please help.



Worked on it some more to try & debug this. Here is what
I get after "set -x" in bash.

[home$:503] cd /c/home/ab+ local cur 'IFS=
' i j k
+ _get_comp_words_by_ref cur
+ local exclude flag i OPTIND=1
+ words=()
+ local cur cword words
+ upargs=()
+ upvars=()
+ local upargs upvars vcur vcword vprev vwords
+ getopts c:i:n:p:w: flag cur
+ [[ 1 -ge 1 ]]
+ case ${!OPTIND} in
+ vcur=cur
+ let 'OPTIND += 1'
+ [[ 1 -ge 2 ]]
+ __get_cword_at_cursor_by_ref '' words cword cur
+ words=()
+ local cword words
+ __reassemble_comp_words_by_ref '' words cword
+ local exclude i j ref
+ [[ -n '' ]]
+ eval cword=1
++ cword=1
bash: exclude: unbound variable
[home$:503]





I defined a new function -
md () { command cd "$@"; echo "$PWD" ; }

Now, tab completion works for "md". Previously, this function was "cd"
and tab-completion was giving me problems described above.



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

Re: Sending SIGUSR1 to thread in nanosleep causes segfault

[Corvus Corax]

FYI

Just to update some details.

I am working with James Cotton on the OpenPilot project.
We are trying to port the POSIX simulation port of FreeRTOS to cygwin.

We run into issues with signal handling in cygwin 1.7.5 that are
currently blocking our development, since every method to suspend a
running thread via signals either causes:

- random segfaults within Cygwin DLL.
or
- failure to execute the signal handler.

For the sake of narrowing down the source of our problems,
we created 8 demo test cases.

Each of them works the same way:

1. A thread is spawned via pthread_create(), which then executes some
   code that is supposed to "sleep the thread" in background.
2. Signals are repeatedly sent to that thread using pthread_kill()
   which are supposed to be handled by a signal handler.
3. Each succesful call to the signal handler writes a dot (.) to stderr
   (using the write() system call to be thread safe)

Obviously what this is supposed to create is a neverending line of dots.
(Tested and working on Linux and Mac OS X on several architectures)

We believe this is a sign of a major flaw in cygwin signal handling and
may possibly affect many applications.
(Any application that uses signal handlers is potentially affected!)

SEGFAULTS usually occur only once in several thousand signals, so it is
a problem that won't appear on normal applications in a very frequent
way. However it is definitely reproducable!

All 8 test cases usually reach a stable state (segfault or freeze of
output) within less than 10 seconds (usually less than 1s) of run time.


The 8 test cases are as follows:



test_case_1_sleep.c

- The thread sleeps (literally) calling sleep() from 
Bug:
- After a couple thousand dots, the program ends with SIGSEGV in
  cygwin1.dll. The backtrace leads to garbage due to stack corruption!



test_case_2_nanosleep.c

- The thread sleeps calling nanosleep() from 
Bug:
- After a couple thousand dots, the program ends with SIGSEGV in
  cygwin1.dll. The backtrace leads to garbage due to stack corruption!



test_case_3_select.c

- The thread sleeps calling select() from 
Bug:
- Once select() is executed, cygwin blocks signals, failing to execute
  the signal handler. No dots are printed (There is a violation to
  POSIX specification. select() is supposed to return prematurely on
  receiving any signal, whether handled or not. This does not happen.)



test_case_4_mutex_lock.c

- The thread sleeps calling pthread_mutex_lock() from 
Bug:
- Once mutex_lock() is executed, cygwin blocks signals, failing to
  execute the signal handler. No dots are printed. This is a major
  issue for the porting of FreeRTOS, because it causes deadlocks we
  cannot resolve.



test_case_5_pselect.c

- The thread sleeps calling pselect() from . Pselect allows
  to specify a signal mask of signals to be (or not to be) blocked
  during the pselect() call. The mask is deliberate set EMPTY to make
  pselect() interrupt on ALL signals.
Bug:
- Once pselect() is executed, cygwin blocks signals, failing to execute
  the signal handler. No dots are printed (pselect() completely
  ignores its signal mask argument ! )



test_case_6_sched_yield.c

- The thread "sleeps" repeatedly calling sched_yield() from 
Bug:
- The signal handler is not executed in a reliable fashion.



test_case_7_busy_waiting.c
- The thread runs like crazy in a busy loop.
Bug:
- The signal handler is not executed in a reliable fashion.



test_case_8_io.c
- The thread "sleeps" by executing a blocking "read()" call from stdin
Bug:
- The signal handler is not executed in a reliable fashion.
- Occasional segfaults in cygwin dll.

/**
 * small test program whether signals between threads work as they should
 */

#include 
#include 
#include 

void sighandler(int sig) {
	write(2,".",1);
	return;
}

void* threadstart(void* arg) {

	while (1) {
		sleep(1);
	}
}

int main(char** argc, int argv) {

	pthread_t testthread1;	
	struct sigaction action;

	action.sa_handler=sighandler;
	action.sa_flags=0;
	sigfillset( &action.sa_mask );
	sigaction(SIGUSR1,&action,NULL);

	pthread_create(&testthread1,NULL,threadstart,NULL);
	while (1) {
		pthread_kill(testthread1,SIGUSR1);
	}
}
/**
 * small test program whether signals between threads work as they should
 */

#include 
#include 
#include 

void sighandler(int sig) {
	write(2,".",1);
	return;
}

void* threadstart(void* arg) {
struct timespec sleeptime;

	while (1) {
		sleeptime.tv_sec=1;
		sleeptime.tv_nsec=0;
		nanosleep(&sleeptime,NULL);
	}
}

int main(char** argc, int argv) {

	pthread_t testthread1;	
	struct sigaction action;

	action.sa_handler=sighandler;
	action.sa_flags=0;
	sigfillset( &action.sa_mask );
	sigaction(SIGUSR1,&action,NULL);

	pthread_create(&testthread1,NULL,threadstart,NULL);
	while (1) {
		pthread_kill(testthread1,SIGUSR1);
	}
}
/**
 * small test program whether signals between threads work as they should
 */

#include 
#include 
#include 
#include 
#include 

void s

Cygwin / Windows 7 Heap Problems

[m2c]

Hey, I'm wondering if there are any cygwin gurus who can shed some light on
crashes that look to be Windows7 64bit compatibility-related.  When running
a perl script through cygwin/bash on a fresh windows 7 64-bit install, I
encounter errors similar to what others have corrected using "rebaseall". 
These errors occur erratically, and cannot be reproduced every attempt.  I
have successfully rebased a few times before (through ash), which only lead
to the errors happening less frequently (or possibly some old errors being
corrected).

A snippet of the errors I'm running into are:

  2 [main] perl 2312 C:\cygwin\bin\perl.exe: *** fatal error - couldn't
allocate heap, Win32 error 487, base 0x131, top 0x154A000, reserve_size
2330624, allocsize 2334720, page_const 4096
6119825 [main] perl 576 fork: child -1 - died waiting for longjmp before
initialization, retry 0, exit code 0x100, errno 11

7717301 [main] perl 1540 fork: child -1 - died waiting for longjmp before
initialization, retry 0, exit code 0x100, errno 11
  2 [main] svn 632 C:\cygwin\bin\svn.exe: *** fatal error - couldn't
allocate heap, Win32 error 487, base 0xA7, top 0xC2, reserve_size
1765376, allocsize 1769472, page_const 4096
  1 [main] svn 720 fork: child -1 - died waiting for longjmp before
initialization, retry 0, exit code 0x100, errno 11
svn: Can't create tunnel: Resource temporarily unavailable

I have no problems running this script on other computers' cygwin
installations, so I suspect the conflict lies with windows 7 (64bit) and
cygwin.  Our script is just a standard set of system calls (including svn).

I'm using the latest cygwin version - output from uname -a is:
CYGWIN_NT-6.1-WOW64 [computername] 1.7.5(0.225/5/3) 2010-04-12 19:07 i686
Cygwin

Any suggestions / comments would be appreciated!
-- 
View this message in context: 
http://old.nabble.com/Cygwin---Windows-7-Heap-Problems-tp29144331p29144331.html
Sent from the Cygwin list mailing list archive at Nabble.com.


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

Re: Cygwin / Windows 7 Heap Problems

[Larry Hall (Cygwin)]

On 7/12/2010 5:40 PM, m2c wrote:


Hey, I'm wondering if there are any cygwin gurus who can shed some light on
crashes that look to be Windows7 64bit compatibility-related.  When running
a perl script through cygwin/bash on a fresh windows 7 64-bit install, I
encounter errors similar to what others have corrected using "rebaseall".
These errors occur erratically, and cannot be reproduced every attempt.  I
have successfully rebased a few times before (through ash), which only lead
to the errors happening less frequently (or possibly some old errors being
corrected).

A snippet of the errors I'm running into are:

   2 [main] perl 2312 C:\cygwin\bin\perl.exe: *** fatal error - couldn't
allocate heap, Win32 error 487, base 0x131, top 0x154A000, reserve_size
2330624, allocsize 2334720, page_const 4096
6119825 [main] perl 576 fork: child -1 - died waiting for longjmp before
initialization, retry 0, exit code 0x100, errno 11


Perhaps you just need perlrebase.  Have you run that?

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

_

A: Yes.

Q: Are you sure?

A: Because it reverses the logical flow of conversation.

Q: Why is top posting annoying in email?


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

Re: Cygwin / Windows 7 Heap Problems

[Andy Koppe]

On 12 July 2010 22:40, m2c wrote:
>
> Hey, I'm wondering if there are any cygwin gurus who can shed some light on
> crashes that look to be Windows7 64bit compatibility-related.  When running
> a perl script through cygwin/bash on a fresh windows 7 64-bit install, I
> encounter errors similar to what others have corrected using "rebaseall".
> These errors occur erratically, and cannot be reproduced every attempt.  I
> have successfully rebased a few times before (through ash), which only lead
> to the errors happening less frequently (or possibly some old errors being
> corrected).
>
> A snippet of the errors I'm running into are:
>
>      2 [main] perl 2312 C:\cygwin\bin\perl.exe: *** fatal error - couldn't
> allocate heap, Win32 error 487, base 0x131, top 0x154A000, reserve_size
> 2330624, allocsize 2334720, page_const 4096
> 6119825 [main] perl 576 fork: child -1 - died waiting for longjmp before
> initialization, retry 0, exit code 0x100, errno 11
>
> 7717301 [main] perl 1540 fork: child -1 - died waiting for longjmp before
> initialization, retry 0, exit code 0x100, errno 11
>      2 [main] svn 632 C:\cygwin\bin\svn.exe: *** fatal error - couldn't
> allocate heap, Win32 error 487, base 0xA7, top 0xC2, reserve_size
> 1765376, allocsize 1769472, page_const 4096
>      1 [main] svn 720 fork: child -1 - died waiting for longjmp before
> initialization, retry 0, exit code 0x100, errno 11
> svn: Can't create tunnel: Resource temporarily unavailable
>
> I have no problems running this script on other computers' cygwin
> installations, so I suspect the conflict lies with windows 7 (64bit) and
> cygwin.  Our script is just a standard set of system calls (including svn).
>
> I'm using the latest cygwin version - output from uname -a is:
> CYGWIN_NT-6.1-WOW64 [computername] 1.7.5(0.225/5/3) 2010-04-12 19:07 i686
> Cygwin
>
> Any suggestions / comments would be appreciated!

Have you checked your system against the Big List Of Dodgy Apps at
http://cygwin.com/faq/faq.using.html#faq.using.bloda?

Andy

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

Re: pthread_mutex_lock doesn't interrupt

[Andy Koppe]

On 12 July 2010 17:56, James Cotton wrote:
> Hello, I've been trying to get the FreeRTOS Posix simulator to run on
> Cygwin and have run into a few bugs in the signal handling/pthread
> libraries and have isolated test cases
>
> I believe when pthread_mutex_lock receives an interrupt it should run
> it then resume trying to get a lock

Have you got chapter and verse from the POSIX standard on that? By
'interrupt' do you mean SIGINT or any signal? Is it possible that the
signal is just being deferred and then subsumed by later signals?

Andy

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

Re: Cygwin / Windows 7 Heap Problems

[m2c]

When I try, I get the error: find:
'/usr/lib/perl15/site_perl/5.10/i686-cygwin/auto/': No such file or
directory, and then the rebaseimage error (with no clues from google).


Larry Hall (Cygwin) wrote:
> 
> On 7/12/2010 5:40 PM, m2c wrote:
>>
>> Hey, I'm wondering if there are any cygwin gurus who can shed some light
>> on
>> crashes that look to be Windows7 64bit compatibility-related.  When
>> running
>> a perl script through cygwin/bash on a fresh windows 7 64-bit install, I
>> encounter errors similar to what others have corrected using "rebaseall".
>> These errors occur erratically, and cannot be reproduced every attempt. 
>> I
>> have successfully rebased a few times before (through ash), which only
>> lead
>> to the errors happening less frequently (or possibly some old errors
>> being
>> corrected).
>>
>> A snippet of the errors I'm running into are:
>>
>>2 [main] perl 2312 C:\cygwin\bin\perl.exe: *** fatal error -
>> couldn't
>> allocate heap, Win32 error 487, base 0x131, top 0x154A000,
>> reserve_size
>> 2330624, allocsize 2334720, page_const 4096
>> 6119825 [main] perl 576 fork: child -1 - died waiting for longjmp before
>> initialization, retry 0, exit code 0x100, errno 11
> 
> Perhaps you just need perlrebase.  Have you run that?
> 
> -- 
> Larry Hall  http://www.rfk.com
> RFK Partners, Inc.  (508) 893-9779 - RFK Office
> 216 Dalton Rd.  (508) 893-9889 - FAX
> Holliston, MA 01746
> 
> _
> 
> A: Yes.
>> Q: Are you sure?
>>> A: Because it reverses the logical flow of conversation.
 Q: Why is top posting annoying in email?
> 
> --
> Problem reports:   http://cygwin.com/problems.html
> FAQ:   http://cygwin.com/faq/
> Documentation: http://cygwin.com/docs.html
> Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
> 
> 
> 

-- 
View this message in context: 
http://old.nabble.com/Cygwin---Windows-7-Heap-Problems-tp29144331p29144856.html
Sent from the Cygwin list mailing list archive at Nabble.com.


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

Re: Cygwin / Windows 7 Heap Problems

[m2c]

Yes, I've checked that list - I'm certain we have none of that installed.

Andy Koppe wrote:
> 
> On 12 July 2010 22:40, m2c wrote:
>>
>> Hey, I'm wondering if there are any cygwin gurus who can shed some light
>> on
>> crashes that look to be Windows7 64bit compatibility-related.  When
>> running
>> a perl script through cygwin/bash on a fresh windows 7 64-bit install, I
>> encounter errors similar to what others have corrected using "rebaseall".
>> These errors occur erratically, and cannot be reproduced every attempt.
>>  I
>> have successfully rebased a few times before (through ash), which only
>> lead
>> to the errors happening less frequently (or possibly some old errors
>> being
>> corrected).
>>
>> A snippet of the errors I'm running into are:
>>
>>      2 [main] perl 2312 C:\cygwin\bin\perl.exe: *** fatal error -
>> couldn't
>> allocate heap, Win32 error 487, base 0x131, top 0x154A000,
>> reserve_size
>> 2330624, allocsize 2334720, page_const 4096
>> 6119825 [main] perl 576 fork: child -1 - died waiting for longjmp before
>> initialization, retry 0, exit code 0x100, errno 11
>>
>> 7717301 [main] perl 1540 fork: child -1 - died waiting for longjmp before
>> initialization, retry 0, exit code 0x100, errno 11
>>      2 [main] svn 632 C:\cygwin\bin\svn.exe: *** fatal error - couldn't
>> allocate heap, Win32 error 487, base 0xA7, top 0xC2, reserve_size
>> 1765376, allocsize 1769472, page_const 4096
>>      1 [main] svn 720 fork: child -1 - died waiting for longjmp before
>> initialization, retry 0, exit code 0x100, errno 11
>> svn: Can't create tunnel: Resource temporarily unavailable
>>
>> I have no problems running this script on other computers' cygwin
>> installations, so I suspect the conflict lies with windows 7 (64bit) and
>> cygwin.  Our script is just a standard set of system calls (including
>> svn).
>>
>> I'm using the latest cygwin version - output from uname -a is:
>> CYGWIN_NT-6.1-WOW64 [computername] 1.7.5(0.225/5/3) 2010-04-12 19:07 i686
>> Cygwin
>>
>> Any suggestions / comments would be appreciated!
> 
> Have you checked your system against the Big List Of Dodgy Apps at
> http://cygwin.com/faq/faq.using.html#faq.using.bloda?
> 
> Andy
> 
> --
> Problem reports:   http://cygwin.com/problems.html
> FAQ:   http://cygwin.com/faq/
> Documentation: http://cygwin.com/docs.html
> Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
> 
> 
> 

-- 
View this message in context: 
http://old.nabble.com/Cygwin---Windows-7-Heap-Problems-tp29144331p29144888.html
Sent from the Cygwin list mailing list archive at Nabble.com.


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

Re: Cygwin extremely slow after updating from 1.5.1 to 1.7.5

[Jet Thompson]

Jet Thompson  whidbey.com> writes:

> 
> It is now taking over 30 seconds for bash to come up,
> whereas in 1.5 it would take 1-2 seconds.

Above fixed by removing bash-completion

> Doing an ls of my ~ directory takes 5 seconds.

Above fixed by removing bash-completion

 
> Running a cucumber test takes 5-6 minutes.
> 
> Any idea what could be causing this?

I have installed spork. 

Time is now 45.2 seconds running Cucumber from
within e text editor.

Time is 32 seconds running Cucumber from the command
line (bash).

Is this the best I should expect from running Cucumber within
Cygwin, or is something still out of whack with my environment?

It seems that the people doing the same under Linux or on Mac
have times like 3-4 seconds.

I did check the list of programs that could be interfering with
Cygwin. Removed Sonic DLA, the only one I had installed that was
on the list. However, I did not notice any change. I am running
Kaspersky, but it was not on the list, and I did not notice any
difference when it was disabled.


Any ideas for improving performance deeply appreciated


Cheers,

   Jet




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

Re: pthread_mutex_lock doesn't interrupt

[James Cotton]

Sorry, I don't have access to the actual POSIX standard, but my
interpretation is based on man pages:

https://computing.llnl.gov/tutorials/pthreads/man/pthread_mutex_lock.txt

And certainly nowhere have I see "pthread_mutex_lock blocks signals".
The signal we are using is SIGUSR1.  I don't see why the signal would
be deferred since there are no signals being blocked.  Possibly the
first signal gets caught and another one comes while in the signal
handler (where usual that signal should then get blocked) and is
disrupting the processing.

James

>On 12 July 2010 17:56, James Cotton wrote:
>> Hello, I've been trying to get the FreeRTOS Posix simulator to run on
>> Cygwin and have run into a few bugs in the signal handling/pthread
>> libraries and have isolated test cases
>>
>> I believe when pthread_mutex_lock receives an interrupt it should run
>> it then resume trying to get a lock
>
>Have you got chapter and verse from the POSIX standard on that? By
>'interrupt' do you mean SIGINT or any signal? Is it possible that the
>signal is just being deferred and then subsumed by later signals?
>
>Andy

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

Re: Cygwin extremely slow after updating from 1.5.1 to 1.7.5

[Andy Koppe]

On 12 July 2010 23:48, Jet Thompson wrote:
>> Running a cucumber test takes 5-6 minutes.
>>
>> Any idea what could be causing this?
>
> I have installed spork.
>
> Time is now 45.2 seconds running Cucumber from
> within e text editor.
>
> Time is 32 seconds running Cucumber from the command
> line (bash).
>
> Is this the best I should expect from running Cucumber within
> Cygwin, or is something still out of whack with my environment?

"Spork"? "Cucumber"? Neither of those are either Cygwin packages or
widely known programs, so a bit of context would have been nice.
They're certainly not supported on this list.

Do they fork lots of processes? In that case, the answer might well be yes.

Otherwise, are any network drives involved in your setup? Those can be
rather slow with Cygwin.

Andy

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

Re: pthread_mutex_lock doesn't interrupt

[Andy Koppe]

On 13 July 2010 01:08, James Cotton wrote:
> Sorry, I don't have access to the actual POSIX standard

It's at http://www.opengroup.org/onlinepubs/9699919799.

> but my
> interpretation is based on man pages:
>
> https://computing.llnl.gov/tutorials/pthreads/man/pthread_mutex_lock.txt
>
> And certainly nowhere have I see "pthread_mutex_lock blocks signals".
> The signal we are using is SIGUSR1.  I don't see why the signal would
> be deferred since there are no signals being blocked.  Possibly the
> first signal gets caught and another one comes while in the signal
> handler (where usual that signal should then get blocked) and is
> disrupting the processing.

Makes sense.

Andy

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

Re: Sending SIGUSR1 to thread in nanosleep causes segfault

[Andy Koppe]

On 12 July 2010 22:05, Corvus Corax wrote:
> Just to update some details.
>
> I am working with James Cotton on the OpenPilot project.
> We are trying to port the POSIX simulation port of FreeRTOS to cygwin.
>
> We run into issues with signal handling in cygwin 1.7.5 that are
> currently blocking our development, since every method to suspend a
> running thread via signals either causes:
>
> - random segfaults within Cygwin DLL.
> or
> - failure to execute the signal handler.

I'm afraid you're unlikely to get a quick and comprehensive answer,
because the Cygwin signal guru currently is on a well-deserved
vacation. Thanks for the testcases, hopefully they'll prove useful.

You could also try the latest snapshot from
http://cygwin.com/snapshots to see whether that makes a difference. A
debug version of the DLL is available there as well. And if you're
brave enough, you could try getting stuck into the Cygwin sources
yourself.

The trouble with Cygwin signals is that Windows provides practically
no support for them, so everything has to be manually mapped to
Windows concepts. Have a look at the Signals section of
http://www.cygwin.com/cygwin-ug-net/highlights.html for some of the
tricks. Obviously pthreads further complicate matters, and the sort of
thing you're doing here is not something that tends to get a lot of
use by "normal" programs, so shortcomings are quite likely.

Andy

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