headers
Christopher Faylor | 1 Jul 2012 02:35
Favicon

Re: Persistence of file implemented objects

On Sat, Jun 30, 2012 at 11:29:10PM +0100, Richard H Lee wrote:
>Various objects like fifo pipes, POSIX IPC shared memory and semaphores 
>that are implemented through the filesystem in cygwin persist when the 
>program abnornally terminates. They also persist through reboots, which 
>is different to the behaviour on linux. This is also different with the 
>case of sysV IPC + cygserver on cygwin which clears after reboots.

Please be more precise about what you are talking about.

Fifos persist on reboot on Linux or Cygwin.  They live on the
filesystem.  I don't see how POSIX IPC shared memory and semaphores
could persist.

cgf
Permalink | Reply | 3 comments |
headers
LMH | 1 Jul 2012 19:16

libsqlite3-ruby

The libsqlite3-ruby package does not appear to be in the current package 
manager. Is this available for cygwin? If not, is there a workaround to 
install of build it locally? I have tried installing it with gem, but I 
don't appear to have gem, or there is something wrong with the 
configuration.

gem install sqlite3-ruby

gives,
-bash: gem: command not found

I see allot of posts about this, but some of them go back to 2007, so 
I'm not sure about the current state of things. I don't have ruby 
windows installed, just the cygwin version, and am still using gcc 3.

Thanks,

LMH
Permalink | Reply | 0 comments |
headers
Richard H Lee | 1 Jul 2012 20:17
Picon

Re: Persistence of file implemented objects

> Fifos persist on reboot on Linux or Cygwin.  They live on the
> filesystem.  I don't see how POSIX IPC shared memory and semaphores
> could persist.

Sorry, I meant unix/bsd sockets.

Regarding the POSIX IPC's, they are stored in /dev . In regular *nix, 
/dev do not represent "physical" files on the filesystem, hence they do 
not persist over boot.

In cygwin, they actually do represent physical files. So if they are not 
freed correctly by the program, the persist over to the next boot.
Permalink | Reply | 2 comments |
headers
Andrey Repin | 2 Jul 2012 01:05
Picon

Re: vim/cygwin: python support

Greetings, ping!

> and ... I do find some minor (maybe not that minor) issue in here, e.g:

> 1)sometime (not everytime, roughly half chances) follow warning/errors 
> prompt, press <enter> it will go away and laugh vim.

> [ping <at> ping-new-laptop ~]$ vim
>        1 [main] vim 6740 child_info_fork::abort: address space needed by 
> 'fcntl.dll' (0x320000) is already occupied

> Cannot fork

> Press ENTER or type command to continue

Sounds like you need to rebase some DLL's.

> 2) if 1) happened, then ConqueTerm plugin crash vim; otherwise it works 
> fine.

> #when it crashes:

>    ~
>    ~
>    ~
> :ConqueTerm bash.exe

> Error detected while processing function 231..conque_term#set_mappings:
> line  150:
> E31: No such mapping
(Continue reading)

Permalink | Reply | 0 comments |
headers
Christopher Faylor | 2 Jul 2012 01:35
Favicon

Re: Persistence of file implemented objects

On Sun, Jul 01, 2012 at 07:17:15PM +0100, Richard H Lee wrote:
>> Fifos persist on reboot on Linux or Cygwin.  They live on the
>> filesystem.  I don't see how POSIX IPC shared memory and semaphores
>> could persist.
>
>Sorry, I meant unix/bsd sockets.

...which also persist on linux.

>Regarding the POSIX IPC's, they are stored in /dev . In regular *nix, 
>/dev do not represent "physical" files on the filesystem, hence they do 
>not persist over boot.
>
>In cygwin, they actually do represent physical files. So if they are not 
>freed correctly by the program, the persist over to the next boot.

what specific interface are you talking about which creates physical
files in /dev?
Permalink | Reply | 0 comments |
headers
Corinna Vinschen | 2 Jul 2012 10:03
Favicon

Re: Persistence of file implemented objects

On Jul  1 19:17, Richard H Lee wrote:
> >Fifos persist on reboot on Linux or Cygwin.  They live on the
> >filesystem.  I don't see how POSIX IPC shared memory and semaphores
> >could persist.
> 
> Sorry, I meant unix/bsd sockets.

AF_UNIX/AF_LOCAL sockets are implemented on filesystem level as well,
not only on Cygwin.  If they are not explicitely unlinked, they will be
in the way when trying to create a new socket of the same name.

> Regarding the POSIX IPC's, they are stored in /dev . In regular
> *nix, /dev do not represent "physical" files on the filesystem,
> hence they do not persist over boot.
> 
> In cygwin, they actually do represent physical files. So if they are
> not freed correctly by the program, the persist over to the next
> boot.

Right.  The named POSIX IPC objects are created as normal files under
/dev/shm and /dev/mqueue.  These objects are supposed to follow POSIX
file name naming rules, and they are supposed to be persistent until you
call mq_unlink, sem_unlink, or shm_unlink respectively.  They are also
meant to persist if a process crashes(*).

So in contrast to XSI IPC implemented by running cygserver they also
persist when all Cygwin processes have stopped and even over reboot,
because they don't live on a virtual filesystem like on Linux, but on
the real filesystem.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Nikolai Weibull | 2 Jul 2012 15:24
Picon
Gravatar

Problem forking from Zsh under 1.7 when installed under UNC path

Hi!

I have come across a problem that occurs when Zsh (both 4.3.11 and
4.3.12) tries to fork when Cygwin (1.7) has been installed under a UNC
path.  The problem occurs because Zsh has support for dynamically
loaded modules.  When Zsh forks to run a process (like “ls”), Cygwin
tries to map these modules (DLLs) into the new process, but somewhere
along the line gets confused as to what passed was used to load the
module:

      2 [main] zsh 8220 child_info_fork::abort: unable to map UNC\Filer\Programs
\Cygwin\lib\zsh\4.3.11\zsh\parameter.dll, Win32 error 126
compaudit:91: fork failed: resource temporarily unavailable
      2 [main] zsh 4836 child_info_fork::abort: unable to map UNC\Filer\Programs
\Cygwin\lib\zsh\4.3.11\zsh\zle.dll, Win32 error 126
compinit:526: fork failed: resource temporarily unavailable

I have installed Cygwin under the path \\Filer\Programs\Cygwin.
MODULE_PATH in Zsh is /usr/lib/zsh/4.3.11.

The modules are loaded fine inside Zsh itself, but can’t be mapped
over into the fork properly, it seems.

This occurred when I upgraded Cygwin from 1.5 to 1.7.  Zsh was also
upgraded from 4.3.11 to 4.3.12 at the same time, but was since
downgraded to exclude any changes that may have occurred in Zsh
between 4.3.11 and 4.3.12.

Note that running “ls” from Bash works fine, as it doesn’t have
loadable modules.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Corinna Vinschen | 2 Jul 2012 16:19
Favicon

Re: Problem forking from Zsh under 1.7 when installed under UNC path

On Jul  2 15:24, Nikolai Weibull wrote:
> Hi!
> 
> I have come across a problem that occurs when Zsh (both 4.3.11 and
> 4.3.12) tries to fork when Cygwin (1.7) has been installed under a UNC
> path.  The problem occurs because Zsh has support for dynamically
> loaded modules.  When Zsh forks to run a process (like “ls”), Cygwin
> tries to map these modules (DLLs) into the new process, but somewhere
> along the line gets confused as to what passed was used to load the
> module:
> 
>       2 [main] zsh 8220 child_info_fork::abort: unable to map UNC\Filer\Programs
> \Cygwin\lib\zsh\4.3.11\zsh\parameter.dll, Win32 error 126
> compaudit:91: fork failed: resource temporarily unavailable
>       2 [main] zsh 4836 child_info_fork::abort: unable to map UNC\Filer\Programs
> \Cygwin\lib\zsh\4.3.11\zsh\zle.dll, Win32 error 126
> compinit:526: fork failed: resource temporarily unavailable

Thanks for the report.  That's certainly a bug in Cygwin.  I applied
a patch which is supposed to fix this issue.  Please test the next
developer snapshot from http://cygwin.com/snapshots/

Thanks,
Corinna

--

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

Permalink | Reply | 1 comment |
headers
marco atzeri | 2 Jul 2012 16:43
Picon

Re: crash on latest cygwin snapshot

On 6/27/2012 3:46 AM, Christopher Faylor wrote:
>
> Sorry, Marco.  Nevermind.  I duplicated this.  No need to upload anything.
> I'm still working on it.
>
> cgf
>

it seems solved on 20120702 snapshots

Thanks
Marco
Permalink | Reply | 33 comments |

Gmane