On 2019-03-26 14:12, Achim Gratz wrote:
> LMH writes:
>> Is there some reason I should be expecting these processes to talk to
>> svchost.exe?
> If your machine is in a domain they will contact the DC to get user and
> group information via standard Windows facilities.
Could it also be Windows ins
Achim Gratz wrote:
> LMH writes:
>> Is there some reason I should be expecting these processes to talk to
>> svchost.exe?
>
> If your machine is in a domain they will contact the DC to get user and
> group information via standard Windows facilities.
>
>
> Regards,
> Achim.
>
As far as I know
LMH writes:
> Is there some reason I should be expecting these processes to talk to
> svchost.exe?
If your machine is in a domain they will contact the DC to get user and
group information via standard Windows facilities.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda
ting inter-process communication with
svchost.exe. I also get a notification that a potential threat to network
traffic
interception or injection has been detected for the same processes. Blocking
this IPC
does not appear to affect anything in how my script runs, so I am wondering
what the
purp
On Jun 29 20:13, Stanisław Wawszczak wrote:
> >
> > Do you have the cygserver service running? (See
> > /usr/share/doc/Cygwin/cygserver.README.)
> >
> > Ken
> Yes, I have. And I have believed that defaults are as stated in config file,
> but they aren't.
> Just after uncommenting the
> kern.ipc
>
> Do you have the cygserver service running? (See
> /usr/share/doc/Cygwin/cygserver.README.)
>
> Ken
Yes, I have. And I have believed that defaults are as stated in config file,
but they aren't.
Just after uncommenting the
kern.ipc.semmsl 60
config line and restarting the cygserver it started
On 6/29/2016 3:20 PM, Stanisław Wawszczak wrote:
On 29/06/2016 18:06, Stanisław Wawszczak wrote:
*Real question is why Cygwin's implementation of getsem() is not allowing to
ask for more than nsems == 1?*
Here is stated, that the platform is limiting the nsems value:
http://pubs.opengroup.org/
>On 29/06/2016 18:06, Stanisław Wawszczak wrote:
>> Dear Corinna,
>>
>> I am sorry about confusing you.
>> Simply:
>>
>> - Issue
>>
>> Call to ftok() returns negative value
>
> Hi Stanisław,
>
> may be I am missing somthing, but noth
On 29/06/2016 18:06, Stanisław Wawszczak wrote:
Dear Corinna,
I am sorry about confusing you.
Simply:
- Issue
Call to ftok() returns negative value
Hi Stanisław,
may be I am missing somthing, but nothing on
http://pubs.opengrou
f Of
Corinna Vinschen
Sent: Wednesday, June 29, 2016 5:15 PM
To: cygwin@cygwin.com
Subject: Re: Cygwin IPC - ftok() returns negative values - Bug Report
On Jun 29 13:14, Stanisław Wawszczak wrote:
> Dear All,
>
> I have had to compile sblim-sfcbd-1.4.10 on Cygwin. It is using IPC
>
On Jun 29 13:14, Stanisław Wawszczak wrote:
> Dear All,
>
> I have had to compile sblim-sfcbd-1.4.10 on Cygwin. It is using IPC
> semaphores.
> Unfortunately it is returning wrong value as the result of complicated
> bit-wise logical operations.
> I have tried to “hack
Dear All,
I have had to compile sblim-sfcbd-1.4.10 on Cygwin. It is using IPC semaphores.
Unfortunately it is returning wrong value as the result of complicated bit-wise
logical operations.
I have tried to “hack the system” and make multiplication of returned value by
-1, but it triggers error
> > > I just checked in the change.
> >
> > Thank you. I will test it as soon as it's available in a snapshot.
I've rebuilt cygserver, and it looks/works fine!
Anton Lavrentiev
Contractor NIH/NLM/NCBI
> You don't have space (or quota) issues on your hard disk by any chance?
Nope, no quota whatsoever. Yes, the file grows big but there is plenty of free
space on the disk.
The machine is pretty slow, though, a dual-core thing. There's definitely
another case of a race
(the point of lock-up is
On Nov 26 18:09, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote:
> > I just checked in the change.
>
> Thank you. I will test it as soon as it's available in a snapshot.
>
> > ...especially since I can't reproduce this. I tried with cygserver
> > before and after my patch and in both cases your sem
Correction:
> cygrunsrv.exe -I cygserver -x /usr/sbin/cygserver.exe -a "-d -l 7"
cygrunsrv.exe -I cygserver -p /usr/sbin/cygserver.exe -a "-d -l 7"
Anton Lavrentiev
Contractor NIH/NLM/NCBI
> I just checked in the change.
Thank you. I will test it as soon as it's available in a snapshot.
> ...especially since I can't reproduce this. I tried with cygserver
> before and after my patch and in both cases your semaphore testcase
> worked as expected with -d -l 7.
I see. Maybe this wi
On Nov 23 18:59, Corinna Vinschen wrote:
> On Nov 23 17:47, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote:
> > > I agree. I'll do that in the next couple of days.
> >
> > Thank you. Please let me know when you do, so that I can
> > check the relevant snapshot out.
>
> Yes, I'll try.
I just checke
On Nov 23 17:47, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote:
> > I agree. I'll do that in the next couple of days.
>
> Thank you. Please let me know when you do, so that I can
> check the relevant snapshot out.
Yes, I'll try.
> Incidentally, have you been able to confirm the dead-locking
> tha
> I agree. I'll do that in the next couple of days.
Thank you. Please let me know when you do, so that I can
check the relevant snapshot out.
Incidentally, have you been able to confirm the dead-locking
that I reported earlier (below)? I just ran the patched cygserver
with the "-d -l 7" argume
On Nov 23 17:16, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote:
> > This should avoid the race (*and* work...)
> > Please give it a try.
>
> Thanks! I've tried both patches (pipe race + semadj), and they do seem to
> work!
Thanks for testing.
> Although (not being a party pooper :-), I think that
> This should avoid the race (*and* work...)
> Please give it a try.
Thanks! I've tried both patches (pipe race + semadj), and they do seem to work!
Although (not being a party pooper :-), I think that all the logic
around "pipe_instance" can now be dropped entirely, and benefit from eliminating
On Nov 23 14:33, Corinna Vinschen wrote:
> On Nov 23 14:10, Corinna Vinschen wrote:
> > On Nov 23 12:36, Corinna Vinschen wrote:
> > > On Nov 19 21:06, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote:
> > > > Hello again,
> > > >
> > > > I can now positively confirm the race condition in cygserver w.r.
On Nov 23 14:10, Corinna Vinschen wrote:
> On Nov 23 12:36, Corinna Vinschen wrote:
> > On Nov 19 21:06, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote:
> > > Hello again,
> > >
> > > I can now positively confirm the race condition in cygserver w.r.t. the
> > > named
> > > pipe used to serialize SYSV
On Nov 23 12:36, Corinna Vinschen wrote:
> On Nov 19 21:06, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote:
> > Hello again,
> >
> > I can now positively confirm the race condition in cygserver w.r.t. the
> > named
> > pipe used to serialize SYSV requests through the server. The race is due to
> > t
On Nov 19 21:06, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote:
> Hello again,
>
> I can now positively confirm the race condition in cygserver w.r.t. the named
> pipe used to serialize SYSV requests through the server. The race is due to
> that transport_layer_pipes::accept() (bool *const recoverab
Hello again,
I can now positively confirm the race condition in cygserver w.r.t. the named
pipe used to serialize SYSV requests through the server. The race is due to
that transport_layer_pipes::accept() (bool *const recoverable) (file:
transport_pipes.cc) does actually _create_ the pipe when pi
> For testing it would be most helpful if you would create a STC.
The test case attached from my earlier post from today, also shows
a race (dead-lock, actually) occurring in CYGSERVER, when it is run
with the "-d -l 7" command line (even when it is only one application,
the test case is using it)
; of code that include this variable, otherwise. And that seems rather
> critical.
You could build cygserver with the variable set to volatile and see if
it changes anything. But I doubt it.
> Right now what I observe, is that SYSV IPC is unreliable, and I'm yet to
> figure
>
erver, and noticed that pipe_instance
(transport_pipes.cc)
is not declared "volatile". This is strange because the compiler can rearrange
lines
of code that include this variable, otherwise. And that seems rather critical.
Right now what I observe, is that SYSV IPC is unreliable, and I
I'm looking to use IPC calls on cygwin (shared memory and semaphores).
The posix IPC api looks saner (easier), but it looks like it was only
brought in in cygwin 1.7 .
Am I better sticking to the SYSV IPC api? Or is the POSIX IPC api stable
enough to use?
--
Problem reports:
Hello,
I have tried to build an application with queues in UNIX flavor (using msgget
API). I have successfully ran cygwin server and enabled IPC. The program works
if I use 2-3 queues to send messages between threads (single thread reads from
one queue, multiple threads can write to any queue
On Sun, 19 Dec 2010 18:34:05 -0500
"Larry Hall \(Cygwin\)" wrote:
> Nothing. I could speculate as to the possible significance of your
> finding but it would likely be more productive for me to just point
> you at the problem-reporting page and ask that you follow the
> guidelines there, if you'
On 12/18/2010 4:45 PM, Bruce Cran wrote:
Hi,
I've been trying to get an application running which calls shmget -
despite running cygserver until now its always crashed with "Bad system
call". I stumbled upon the solution of copying the binary into /bin and
for some reason it works. Can anyone te
Hi,
I've been trying to get an application running which calls shmget -
despite running cygserver until now its always crashed with "Bad system
call". I stumbled upon the solution of copying the binary into /bin and
for some reason it works. Can anyone tell me what's special about /bin
that causes
cygserver service runs well but "ipcs" command report bad system call.
Other programs need ipc operator also can't run now.
I rollbacked to 1.7.0-062 and it seems everything goes fine
--
Problem reports: http://cygwin.com/problems.html
FAQ: http:/
Thanks a lot. The problem is resloved.
Cheers,
Y.Suresh Kumar.
On Wed, Apr 15, 2009 at 1:38 PM, Corinna Vinschen
wrote:
> On Apr 15 12:20, Yarlagadda Suresh wrote:
>> Is this problem fixed in release 1.7.0-46?
>
> Yes, sure. I just forgot to mention it in the release announcement.
>
>
> Corinna
On Apr 15 12:20, Yarlagadda Suresh wrote:
> Is this problem fixed in release 1.7.0-46?
Yes, sure. I just forgot to mention it in the release announcement.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT
Is this problem fixed in release 1.7.0-46?
Cheers,
Y. Suresh Kumar.
On Wed, Apr 1, 2009 at 11:33 AM, Christopher Faylor
wrote:
> On Wed, Apr 01, 2009 at 11:19:28AM +0530, Yarlagadda Suresh wrote:
>>Thanks a ton for your quick response.
>>
>>Could please let me know the patch version number, whic
On Wed, Apr 01, 2009 at 11:19:28AM +0530, Yarlagadda Suresh wrote:
>Thanks a ton for your quick response.
>
>Could please let me know the patch version number, which includes the
>fix?
Just wait for Corinna's Cygwin 1.7 release announcement that you'll see
here.
cgf
--
Unsubscribe info: htt
Thanks a ton for your quick response.
Could please let me know the patch version number, which includes the fix?
Cheers,
Suresh Kumar.
On Tue, Mar 31, 2009 at 8:37 PM, Corinna Vinschen
wrote:
> On Mar 31 14:08, Corinna Vinschen wrote:
>> On Mar 31 17:11, Yarlagadda Suresh wrote:
>> > Hi,
>> >
>
On Mar 31 14:08, Corinna Vinschen wrote:
> On Mar 31 17:11, Yarlagadda Suresh wrote:
> > Hi,
> >
> > I am using shmget()/shmat() methods for getting the shared memory.
> >
> > I had tried running the same program which is given in the previous
> > mention thread, the results are same as mentioned
http://cygwin.com/acronyms/#TOFU
On Mar 31 17:11, Yarlagadda Suresh wrote:
> Hi,
>
> I am using shmget()/shmat() methods for getting the shared memory.
>
> I had tried running the same program which is given in the previous
> mention thread, the results are same as mentioned over there.
I ju
Edition with
>> SP1.
>>
>> I have a program which does the following :
>>
>> 1. The main process gets shared memory, opens an index file (through
>> Btrieve API).
>
> How does it get shared memory? Does it use mmap() or does it use
> shmget()/shmat()? I assu
I).
How does it get shared memory? Does it use mmap() or does it use
shmget()/shmat()? I assume the latter, since you're talking about IPC.
> 2. If a record is found in the index file,the main process forks a child
> and the child process reads the index file and process the dat
Hi,
I am using CYGWIN V 1.5.25-15 on Windows 2008 Standard Server Edition with SP1.
I have a program which does the following :
1. The main process gets shared memory, opens an index file (through
Btrieve API).
2. If a record is found in the index file,the main process forks a child
and the
's not a core module is, of itself, sufficient
reason.
I see. I was not aware that this is not a core module.
With perl 5.10.0, IPC::Cmd became a core module, so *every* build of perl
5.10.0 ought to include that module.
perl-5.10.0-3 and all subsequent perl 5.10 releases indeed contain
gt; module - the fact that it's not a core module is, of itself, sufficient
> reason.
I see. I was not aware that this is not a core module.
> With perl 5.10.0, IPC::Cmd became a core module, so *every* build of perl
> 5.10.0 ought to include that module.
Thanks a lot.
Ronald
- Original Message -
From: "Ronald Fischer" <[EMAIL PROTECTED]>
To:
Sent: Monday, May 05, 2008 8:00 PM
Subject: Perl IPC::Cmd
I'm using
perl 5.8.7 for Solaris
perl 5.8.8 for Cygwin
perl 5.8.10 for Windows (native)
perl 5.8.10 ??
To my surprise, the Cygwin
I'm using
perl 5.8.7 for Solaris
perl 5.8.8 for Cygwin
perl 5.8.10 for Windows (native)
To my surprise, the Cygwin version of Perl does not include the standard module
IPC::Cmd, though the other two (in particular, the earlier 5.8.7 Perl) do. Is
there a particular reason, why IPC::C
On Aug 28 14:47, Dave Korn wrote:
> On 28 August 2007 14:28, Mehdi Rabah wrote:
>
> > Hi,
> >
> > I'm trying to compile a linux project with cygwin. There is a file
> > which use IPC and include all the necessary files
> >
> > #include
> &g
On 28 August 2007 14:28, Mehdi Rabah wrote:
> Hi,
>
> I'm trying to compile a linux project with cygwin. There is a file
> which use IPC and include all the necessary files
>
> #include
> #include
> #include
> #include
> #include
>
>
>
Hi,
I'm trying to compile a linux project with cygwin. There is a file
which use IPC and include all the necessary files
#include
#include
#include
#include
#include
but still, I have this error at compile time:
error: `semtimedop' undeclared (first use this function)
wha
n Sun, 2007-01-28 at 14:00 -0800, it wrote:
Thanks, I just tried specifying explicitly SSH, and still the same
error:
[EMAIL PROTECTED]:~/rsync# rsync -e ssh test test2
rsync: pipe: Connection refused (111)
rsync error: error in IPC code (code 1
e or local with local, ssh or no ssh
the same problem occurs.
=
[EMAIL PROTECTED]:~/rsync# rsync test test2
rsync: pipe: Connection refused (111)
rsync error: error in IPC code (code 14) at
/home/lapo/packaging/tmp/rsync-2.6.6/pipe.c(117)
[EMAIL
Greetings,
I'm having a problem with rsync. I want to sync my Windows box to a
Linux server using rsync and I get the following error when I try to do
any command. Remote or local.
[EMAIL PROTECTED]:~/rsync# rsync -a test test2
rsync: pipe: Connection refused (111)
rsync error: error i
Siegfried Heintze wrote:
I'm curious: does cygwin support the msgget, msgsnd, msgrcv & msgctl
functions from System V IPC?
The sample code I downloaded from the www.wrox.com (for the book Beginning
Linux Programming 3rd Edition chapter 14) compiles with no errors bug causes
a "5
I'm curious: does cygwin support the msgget, msgsnd, msgrcv & msgctl
functions from System V IPC?
The sample code I downloaded from the www.wrox.com (for the book Beginning
Linux Programming 3rd Edition chapter 14) compiles with no errors bug causes
a "5032 Bad System call&q
On Apr 9 11:40, Vincent Dedun wrote:
> >What's the error code you get?
>
> read just return less byte than expected, and it occurs only in this
> case.
Ok, that's nothing to worry about and something you have to expect
anyway. At least as long as the next attempt to read returns the
missing da
s realy related or just a coincidence. Sockets
have nothing to do with IPC, unless you're running on 9x, where the
Cygserver/Client connection is done using sockets.
but it has to do with file descriptors.
I could reproduce it several time, each time the socket read error
occurs when the tes
lave may have a socket read error if it was
> reading on the socket at the same time that testcase is launched.
I'm wondering if that's realy related or just a coincidence. Sockets
have nothing to do with IPC, unless you're running on 9x, where the
Cygserver/Client connection is
, as the socket read will fail only
when the testcase is launched.
Anyway, reproducing this would imply a server-and-client testcase,
exchanging data on their socket, and using IPC, like the testcase I
provided, and it depends on the children number. Just note it.
Tuned like this, I made a tes
On Apr 8 17:10, [EMAIL PROTECTED] wrote:
> it works for me too for the testcase i provided last time.
>
> But there is still some issues when you run several semaphore-using
> program at the same time.
[Insert swear-word here]
> to reproduce it :
> -compil last testcase with this modification
On Apr 4 18:05, Vincent Dedun wrote:
grepping cygserver debug output, show that, with 2 child process
sharing mutex, wakeup is called first, then 2 msleep are called. So
when msleep is called, wakeup has already been called, and msleep has
to sleep forever.
What you see is intermixed debug output
On Apr 4 18:05, Vincent Dedun wrote:
> grepping cygserver debug output, show that, with 2 child process
> sharing mutex, wakeup is called first, then 2 msleep are called. So
> when msleep is called, wakeup has already been called, and msleep has
> to sleep forever.
What you see is intermixed d
I just saw a strange stuff : in sysv_sem.cc (cygserver) at end of
semop
function (:done2 label), the mutex is released after waking up waiting
process, shouldn't it be the inverse ?
No, the mtx_unlock is correct. If you're looking for bugs, they are
very
likely in the bsd_* files in cygserver.
Original Message
>From: Corinna Vinschen
>Sent: 04 April 2005 15:26
> On Apr 4 14:45, Dave Korn wrote:
>> Incidentally, what's the difference between the cygwin0.dll and the
>> new-cygwin1.dll, anyone? Is the -0.dll the
>
> The cygwin0.dll is tweaked to run in the testsuite, while ano
On Apr 4 16:25, Corinna Vinschen wrote:
> On Apr 4 14:45, Dave Korn wrote:
> > Incidentally, what's the difference between the cygwin0.dll and the
> > new-cygwin1.dll, anyone? Is the -0.dll the
>
> The cygwin0.dll is tweaked to run in the testsuite, while another version
> of Cygwin is still
On Apr 4 14:45, Dave Korn wrote:
> Incidentally, what's the difference between the cygwin0.dll and the
> new-cygwin1.dll, anyone? Is the -0.dll the
The cygwin0.dll is tweaked to run in the testsuite, while another version
of Cygwin is still running.
Corinna
--
Corinna Vinschen
On Apr 4 15:13, Vincent Dedun wrote:
> i have no idea how to do this, i'm not a good system programmer.
gdb?
> further more, i have a slow computer, and recompiling cygwin is long.
> I even don't know how to active debugging (dprintf) on cygwin dll.
The debug output in cygserver is activated by
Dave Korn wrote:
> Incidentally, what's the difference between the cygwin0.dll and the
> new-cygwin1.dll, anyone? Is the -0.dll the
> specially-tweaked-for-running-make-check-without-clashing-with-the-existing-
> one one? I'm fairly sure it's the new-* dll that gets installed by "make
> instal
Original Message
>From: Vincent Dedun
>Sent: 04 April 2005 14:14
> i tried to test this, but when i modify cygwin sources and compil, my
> cygwin0.dll is not updated, i don't want to recompil everything each
> time, it take too longs.
cd /i686-pc-cygwin/winsup/cygwin
make all
will just
Corinna Vinschen wrote :
On Apr 4 08:52, Vincent Dedun wrote:
However, semaphores still doesn't work properly.
There is no more problem with semop not waiting, but with quick
semaphores locking unlocking.
I attach a new testcase, which is the same as previous one, except
each
child task will lock
On Apr 4 08:52, Vincent Dedun wrote:
> However, semaphores still doesn't work properly.
> There is no more problem with semop not waiting, but with quick
> semaphores locking unlocking.
>
> I attach a new testcase, which is the same as previous one, except each
> child task will lock the semaph
Corinna Vinschen wrote :
Thanks again for the testcase. It helped to track down the problem which
was a result of my previous check in. It should be solved in CVS now.
Since you're building from CVS anyway, I don't create another snapshot
for now. We're that close to 1.5.14 anyway...
Thanks a
On Apr 1 16:36, Vincent Dedun wrote:
> I recompiled from the cygwin cvs, and it solved my problem, my master
> now runs well.
>
> However, there is still a problem, sorry ;)
Thanks again for the testcase. It helped to track down the problem which
was a result of my previous check in. It shoul
or me, but it would be good if you
could test the next snapshot, which I just uploaded, nevertheless.
It's just incredible that nobody found this problem before.
Yes, I find this incredible as any unix server which use IPC (instead of
threads for exemple), will wants to support multiple con
On Apr 1 13:05, Vincent Dedun wrote:
> So I hope you wouldn't mind I attached a short testing program you can
> easily compil with gcc to reproduce the bug.
Cool, that's exactly what I was asking for. I was immediately able to
reproduce the problem and it turned out, that on fork() the socket
d
ll version is
1.5.14 build on March 30 2005.
I attach cygcheck.out as asked in the cygwin' problem webpage.
I work on windows version of drqueue, which is an opensource distributed
rendering management software (for use with maya rendering for exemple),
designed for unix, so it uses IPC an
g management software (for use with maya rendering for exemple),
> designed for unix, so it uses IPC ans sockets.
>
> The port works well for the most of it, except for the server itself
> (the master program).
> The unix version has no problem on all this, it works on linux, bsds, irix..
There seems to be odd problems with windows sp2 (and some sp1 with
undetermined updates).
I work on windows version of drqueue, which is an opensource distributed
rendering management software (for use with maya rendering for exemple),
designed for unix, so it uses IPC ans sockets.
The port
o make dansguardian (www.danguardian.org v.2.8.0.4) run on
> Cygwin/WindowsXP.
> I modified the "configure" script so that dansguardian gets compiled.
> Currently everything works ok (i.e. filtering...), _except_ writing into
> the log file and the url cache.
>
> Dansguardian uses IPC
Hello,
I'm trying to make dansguardian (www.danguardian.org v.2.8.0.4) run on
Cygwin/WindowsXP.
I modified the "configure" script so that dansguardian gets compiled.
Currently everything works ok (i.e. filtering...), _except_ writing into the
log file and the url cache.
Dansgu
At 11:46 AM 2/3/2005, you wrote:
>> -Original Message-
>> From: cygwin-owner On Behalf Of Christopher Faylor
>> Sent: 03 February 2005 16:29
>
>> On Thu, Feb 03, 2005 at 11:38:45AM +0100, Olivier Mesmeur wrote:
>> >Thanks, I am interesting to provide a patch but I don't know how to
>> >star
> -Original Message-
> From: cygwin-owner On Behalf Of Christopher Faylor
> Sent: 03 February 2005 16:29
> On Thu, Feb 03, 2005 at 11:38:45AM +0100, Olivier Mesmeur wrote:
> >Thanks, I am interesting to provide a patch but I don't know how to
> >start! I think that I need CVS source but wh
On Thu, 3 Feb 2005, Olivier Mesmeur wrote:
> >>Hi,
> >>
> >>We have a problem using JNI and IPC under cygwin.
> >>
> >>We compile a DLL using gcc but without -mno-cygwin option because we
> >>need IPC functionalities.
> >>
> >
On Thu, Feb 03, 2005 at 11:38:45AM +0100, Olivier Mesmeur wrote:
>Thanks, I am interesting to provide a patch but I don't know how to
>start! I think that I need CVS source but which components of cygwin I
>need to modify? And do you have an idea about the time needed to develop
>the patch?
http:/
> -Original Message-
> From: cygwin-owner On Behalf Of Olivier Mesmeur
> Sent: 03 February 2005 10:39
> >No, loading cygwin1.dll in this way is not supported. We need someone
> >interested in getting this working to provide a patch.
>
>
> Thanks, I am interesting to provide a patch but
>>Hi,
>>
>>We have a problem using JNI and IPC under cygwin.
>>
>>We compile a DLL using gcc but without -mno-cygwin option because we
>>need IPC functionalities.
>>
>>It's worked fine with previous version of cygwin (< 1.5.5), but n
At 05:48 AM 2/2/2005, you wrote:
>Hi,
>
>We have a problem using JNI and IPC under cygwin.
>
>We compile a DLL using gcc but without -mno-cygwin option because we
>need IPC functionalities.
>
>It's worked fine with previous version of cygwin (< 1.5.5), but now t
Hi,
We have a problem using JNI and IPC under cygwin.
We compile a DLL using gcc but without -mno-cygwin option because we
need IPC functionalities.
It's worked fine with previous version of cygwin (< 1.5.5), but now that
we are using cygwin version 1.5.9, java crashs when we launch
On Jan 4 10:21, Zachary Uram wrote:
> On Tue, 4 Jan 2005 15:03:51 +0100, Corinna Vinschen
> <[EMAIL PROTECTED]> wrote:
> > On Jan 4 05:57, Zachary Uram wrote:
> > > On Thu, 30 Dec 2004 17:59:17 +0100, Corinna Vinschen
> > > > ipc-deamon2 has been deprecated
On Tue, 4 Jan 2005 15:03:51 +0100, Corinna Vinschen
<[EMAIL PROTECTED]> wrote:
> On Jan 4 05:57, Zachary Uram wrote:
> > On Thu, 30 Dec 2004 17:59:17 +0100, Corinna Vinschen
> > > ipc-deamon2 has been deprecated. Use cygserver instead. It's part of the
> >
On Jan 4 05:57, Zachary Uram wrote:
> On Thu, 30 Dec 2004 17:59:17 +0100, Corinna Vinschen
> > ipc-deamon2 has been deprecated. Use cygserver instead. It's part of the
> > Cygwin base package and installed into /usr/sbin. Documentation is in
> > /usr/share/doc/Cygwin
Cygwin with cygipc-2.03-2.tar package
> > > > and when I run
> > > > /usr/bin/ipc-daemon2.exe it immediately exits, no error message is
> > > > printed,
> > > > i have a /tmp directory and when i run ipcs it says: Bad system call
> > > >
>
.tar package
> > > and when I run
> > > /usr/bin/ipc-daemon2.exe it immediately exits, no error message is
> > > printed,
> > > i have a /tmp directory and when i run ipcs it says: Bad system call
> > >
> > > When I do ps it also shows that no ipc-d
On Thu, 30 Dec 2004 17:59:17 +0100, Corinna Vinschen
<[EMAIL PROTECTED]> wrote:
> On Dec 29 22:50, Zachary Uram wrote:
> > Hello I am running the latest Cygwin with cygipc-2.03-2.tar package
> > and when I run
> > /usr/bin/ipc-daemon2.exe it immediately exits, no erro
On Dec 29 22:50, Zachary Uram wrote:
> Hello I am running the latest Cygwin with cygipc-2.03-2.tar package
> and when I run
> /usr/bin/ipc-daemon2.exe it immediately exits, no error message is printed,
> i have a /tmp directory and when i run ipcs it says: Bad system call
>
> Wh
Hello I am running the latest Cygwin with cygipc-2.03-2.tar package
and when I run
/usr/bin/ipc-daemon2.exe it immediately exits, no error message is printed,
i have a /tmp directory and when i run ipcs it says: Bad system call
When I do ps it also shows that no ipc-daemon2.exe is working.
I
Corinna Vinschen schrieb:
On Sep 4 13:38, Reini Urban wrote:
I experience a shmget problem with postgresql and try to debug that.
I created debug version of cygserver.
cd "src\obj\i686-pc-cygwin\winsup\cygserver"
insight cygserver.exe
I put a breakpoint at shmget()
break ../../../../winsup/cygserv
1 - 100 of 180 matches
Mail list logo
