headers
Pedro Alves | 1 Mar 2007 01:15
Picon
Favicon

Re: GDB Ctrl-C Interrupt Fails WORKAROUND

Christopher Layne escreveu:
> On Thu, Jun 15, 2006 at 11:04:56AM -0400, Christopher Faylor wrote:
>>> I'm happy for you that CTRL-C works for you.  It does not work for me.
>>>
>>> I'm almost never running gdb from a genuine DOS command prompt.   
>>> Sometimes via ssh, sometimes via a terminal emulator.  CTRL-C doesn't  
>>> work in those.
>>>
>>> Also, if you have "tty" in your CYGWIN variable it doesn't work even  
>> >from a DOS command prompt.
>>
>> Which is exactly what I theorized above.  So, characterizing CTRL-C as
>> not working in gdb is rather an overstatement without more details.
>>
>> Now you know that you can use a standard console window for debugging
>> and all will be well.
>>
>>> Lacking the ability to interrupt a running program severely limits  
>>> gdb's usefulness.  Fortunately there's a workaround available.
>> Yep.  Use a console window.
>>

Is there a reason DebugBreakProcess can't be used from inside
gdb if sending a ctrl-c with GenerateConsoleCtrlEvent (CTRL_C_EVENT, pid)
doesn't work?

> 
> Where in the cygwin source tree would the best place be to look for
> where SIGINT handling is being done at the tty/pty level so that I can
> remove this pointless limitation from my builds?
(Continue reading)

Permalink | Reply | 5 comments |
headers
Christopher Faylor | 1 Mar 2007 01:35
Favicon

Re: GDB Ctrl-C Interrupt Fails WORKAROUND

On Thu, Mar 01, 2007 at 12:15:12AM +0000, Pedro Alves wrote:
>Is there a reason DebugBreakProcess can't be used from inside
>gdb if sending a ctrl-c with GenerateConsoleCtrlEvent (CTRL_C_EVENT, pid)
>doesn't work?

I suppose that it could be used for that but it might be tricky figuring
out when it was required and when it wasn't.  You wouldn't want to
interrupt the process twice if it already saw the CTRL-C.  Although,
maybe if you used this you could tell the inferior process not to
process CTRL-C at all via some CreateProcess setting.

cgf
Permalink | Reply | 4 comments |
headers
Pedro Alves | 1 Mar 2007 02:12
Picon
Favicon

Re: GDB Ctrl-C Interrupt Fails WORKAROUND

Christopher Faylor escreveu:
> On Thu, Mar 01, 2007 at 12:15:12AM +0000, Pedro Alves wrote:
>> Is there a reason DebugBreakProcess can't be used from inside
>> gdb if sending a ctrl-c with GenerateConsoleCtrlEvent (CTRL_C_EVENT, pid)
>> doesn't work?
> 
> I suppose that it could be used for that but it might be tricky figuring
> out when it was required and when it wasn't.  You wouldn't want to
> interrupt the process twice if it already saw the CTRL-C.  Although,
> maybe if you used this you could tell the inferior process not to
> process CTRL-C at all via some CreateProcess setting.
> 

What about doing it the other way around?  Use DebugBreakProcess if
available, and fallback to GenerateConsoleCtrlEvent?  Is there anything
internal to Cygwin that uses it?  We could teach gdb that the next
BreakPoint inside kernel32 (, or whatever dll DebugBreakProcess breaks in,)
is mapped to SIGINT, remap the event, and switch to the main thread, so
the user doesn't see we stopped inside kernel32.

Cheers,
Pedro Alves
Permalink | Reply | 3 comments |
headers
Christopher Faylor | 1 Mar 2007 03:58
Favicon

Re: GDB Ctrl-C Interrupt Fails WORKAROUND

On Thu, Mar 01, 2007 at 01:12:21AM +0000, Pedro Alves wrote:
>Christopher Faylor escreveu:
>>On Thu, Mar 01, 2007 at 12:15:12AM +0000, Pedro Alves wrote:
>>>Is there a reason DebugBreakProcess can't be used from inside gdb if
>>>sending a ctrl-c with GenerateConsoleCtrlEvent (CTRL_C_EVENT, pid)
>>>doesn't work?
>>
>>I suppose that it could be used for that but it might be tricky
>>figuring out when it was required and when it wasn't.  You wouldn't
>>want to interrupt the process twice if it already saw the CTRL-C.
>>Although, maybe if you used this you could tell the inferior process
>>not to process CTRL-C at all via some CreateProcess setting.
>
>What about doing it the other way around?  Use DebugBreakProcess if
>available, and fallback to GenerateConsoleCtrlEvent?

?  Maybe we're not talking about the same thing but I don't see why it
matters what the order of function calls is.  If the inferior process
has already responded to a CTRL-C you don't want it to get another
interrupt.

>Is there anything internal to Cygwin that uses it?  We could teach gdb
>that the next BreakPoint inside kernel32 (, or whatever dll
>DebugBreakProcess breaks in,) is mapped to SIGINT, remap the event, and
>switch to the main thread, so the user doesn't see we stopped inside
>kernel32.

I think if gdb sends a break because it saw a CTRL-C and then gets a
break from the sub-process it is safe for gdb to assume that the
interrupt was a CTRL-C without needing to check where the break hit.  I
(Continue reading)

Permalink | Reply | 2 comments |
headers
neo napster | 1 Mar 2007 06:31
Picon
Favicon

Re: 100% CPU Usage and Error Message: Error, messageQ semaphore not equal to zero.

Hi,

Thanks for your instant reply. I have a few queries regarding cygserver and cygipc. We have just started
looking into our programs to see what the impact will be to move from cygipc to cygserver. 

1. Can you please give us an idea of the things that need to be done to move from cygipc to cygserver. Our
programs are coded in C.

2. We were trying to just get the cygserver up and running. We have successfully installed cyserver. But,
when starting Cygserver, the following error occurs:

"System Error 3 has Occured ---   The System cannot find the path specified".

I have checked services.msc for the cygserver service, it is installed correctly and the path to the
exectuable is pointing to cygrunsrv.exe in the correct folder. What could be the problem?

Thanks and Regards,
Neo.

----- Original Message ----
From: Corinna Vinschen <corinna-cygwin <at> cygwin.com>
To: cygwin <at> cygwin.com
Sent: Friday, 23 February, 2007 6:13:04 PM
Subject: Re: 100% CPU Usage and Error Message: Error, messageQ semaphore not equal to zero.

On Feb 23 17:55, neo napster wrote:
> Hi,
>  
> I am using the below system configuration:
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rakesh Kumar | 1 Mar 2007 06:43
Picon
Favicon

Regarding mount command inside CYGWIN

Hello,

I'm running a command inside Cygwin

	 mount -b /cygdrive/c/cygwin/rakesh /cygdrive/c/cygwin/rakesh/usr/cygnus

But I get the following errorÂ…

	mount: /cygdrive/c/cygwin/rakesh/usr/cygnus: Invalid argument

Is the mount command wrongly given??

Regards,
Rakesh

_________________________________________________________________
Latest updates from the world of sports 
http://content.msn.co.in/Sports/Default
Permalink | Reply | 2 comments |
headers
Christopher Layne | 1 Mar 2007 06:53

Re: Regarding mount command inside CYGWIN

On Thu, Mar 01, 2007 at 11:13:00AM +0530, Rakesh Kumar wrote:
> Hello,
> 
> I'm running a command inside Cygwin
> 
> 	 mount -b /cygdrive/c/cygwin/rakesh 
> 	 /cygdrive/c/cygwin/rakesh/usr/cygnus
> 
> But I get the following error?
> 
> 	mount: /cygdrive/c/cygwin/rakesh/usr/cygnus: Invalid argument
> 
> Is the mount command wrongly given??
> 
> Regards,
> Rakesh
> 

Yes.

You need a win32 path for the mount source.

man mount.

-cl
Permalink | Reply | 0 comments |
headers
Marco Atzeri | 1 Mar 2007 09:15
Picon
Favicon

Re: Strange message from updatedb


--- Phil Edwards <phil.m.edwards <at> gmail.com> ha
scritto:

> > Try replacing spaces ' ' with dots '.' in the
> paths specified with --prunepaths.
> > In a regexp a dot matches any character.
> 
> I had tried that, but
>   
> --prunepaths='/cygdrive/c/System.Volume.Information'
> still caused the corresponding directory to be
> searched.  I didn't have
> time to look further then, maybe somebody else will
> beat me to it.
> 

for me it is working as expected

updatedb --localpaths='/' --prunepaths='/proc
/cygdrive/c/cygwin /cygdrive/c/Doc
uments.and.Settings/marco/Local.Settings/Temp
/cygdrive/c/Documents.and.Setti
ngs/marco/Local.Settings/Temporary.Internet.Files
/cygdrive/c/Documents.and.S
ettings/marco/Local.Settings/Application.Data/Mozilla/Firefox/Profiles/1qhnuu
xo.default/Cache /cygdrive/c/RECYCLER
/cygdrive/c/System.Volume.Information /cyg
drive/f /cygdrive/h /cygdrive/s /cygdrive/u'
(Continue reading)

Permalink | Reply | 0 comments |
headers
Hugh McMaster | 1 Mar 2007 09:58
Picon

Re: Deprecating ntea

Hi Corinna,

On 28/02/07, Corinna Vinschen wrote:
> I think it's time to remove the CYGWIN=ntea setting from Cygwin.
> (see http://cygwin.com/cygwin-ug-net/using-cygwinenv.html)

How will that affect my system path variable, say 'CYGWIN=tty nontea
nosmbntsec nontsec'?

If so, please explain in a bit more detail.

Thankyou,

Hugh
Permalink | Reply | 2 comments |
headers
Corinna Vinschen | 1 Mar 2007 10:50
Favicon

Re: Deprecating ntea

On Mar  1 19:58, Hugh McMaster wrote:
> Hi Corinna,
> 
> On 28/02/07, Corinna Vinschen wrote:
> >I think it's time to remove the CYGWIN=ntea setting from Cygwin.
> >(see http://cygwin.com/cygwin-ug-net/using-cygwinenv.html)
> 
> How will that affect my system path variable, say 'CYGWIN=tty nontea
> nosmbntsec nontsec'?

It doesn't.  You can just remove "nontea".  You can do this today
already since it's the default anynway.

> If so, please explain in a bit more detail.

I have no idea what details you're missing.  You don't use ntea, so
you're not affected.

Corinna

--

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat
Permalink | Reply | 1 comment |

Gmane