Alright, I'm aware of the "check for invalid memory region and throw
exception" issue present when debugging pthread applications under gdb
and that the actual segfault is innocuous. However, the following solutions:
1. "handle SIGSEGV nostop"
"handle SIGTRAP nostop"
2. (hit continue on every
On Mon, May 08, 2006 at 02:01:00AM -0700, Brian Dessent wrote:
>
> Rather than work-arounds, why not just use a recent build of gdb that
> doesn't suffer from this problem? The issue was fixed in CVS earlier
> this year. But do note that it requires functionality not present in
> Cygwin 1.5.19,
On Mon, May 08, 2006 at 02:44:37AM -0700, [EMAIL PROTECTED] wrote:
>
> On Mon, May 08, 2006 at 02:01:00AM -0700, Brian Dessent wrote:
> >
> > Rather than work-arounds, why not just use a recent build of gdb that
> > doesn't suffer from this problem? The issue was fixed in CVS earlier
> > this ye
One thing about this 4-27 snap, and I noticed it with 4-03 as well (which I
reverted from a while ago) is that disk i/o appears to be ridiculously slow
in comparison to 1.5.19. In rough estimation, I'd have to say a 50% reduction
in I/O throughput. I notice it while working with mass updating of f
I suggest doing a google search on the following terms:
"cygwin temporarily unavailable desktop heap"
Or here's a pointer to one:
http://www.cygwin.com/ml/cygwin/2002-02/msg01068.html
On Mon, May 08, 2006 at 06:00:52PM -0700, Virgil Adumitroaie wrote:
> fork: Resource temporarily unavailable"
Warning - LONG and network code related - do not read if not interested
or not versed.
I'm trying to currently debug an issue where readv() seems to be filling
iovec's with bad data or otherwise overflowing when having to deal with a
large receive buffer. I say large receive buffer because I can
Don't try to get shares working like that through sshd. You'll be missing hair
afterwards.
Specify the share as a mount point with mount.
And then add your .bashrc:
if ! ls /mount_point/. 2>&1 >/dev/null; then
/c/WINDOWS/system32/net USE /USER:username '\\share' password
fi
Yep, about as
On Tue, May 09, 2006 at 07:00:57AM -0700, Mark Pizzolato wrote:
> > 67
> > 68 for (error = 0; !error; ) {
> > 69 error = 1;
> > 70
> > 71 if ((hl = n_recv_iov(s, packet, NE(packet), 60))
> >== (size_t)-1)
> > 72
On Tue, May 09, 2006 at 03:54:16PM +0100, Dave Korn wrote:
> > You cannot
> > even use the idiom of "well let me just get the rest of this here and I'll
> > make a request for the dropped data after."
>
> Yes you absolutely can. Who said you can't? You're just not trying. It
> works fine.
We
On Wed, May 10, 2006 at 01:38:58AM -0400, Christopher Faylor wrote:
> Would you be willing to try building a cygwin DLL with Corinna's
>
> 2006-04-04 Corinna Vinschen <[EMAIL PROTECTED]>
>
> * net.cc (fdsock): Raise default SO_RCVBUF/SO_SNDBUF buffer sizes to
> the same values
On Tue, May 09, 2006 at 10:11:35PM -0700, [EMAIL PROTECTED] wrote:
>
> So far so good, but if anyone sees anything glaring might as well point it
> out - although this is not really CW related at this point.
>
> -cl
Just to follow up on this.. I did take your advice fully Dave, and decided
to ju
On Thu, May 11, 2006 at 09:09:33PM +0200, Klaas Thoelen wrote:
>
> This seems a little strange to me. Does anybody know what's wrong here?
>
> Thanks and regards,
> Klaas Thoelen
It's just a classic mistake, pretty easily fixed with the following:
> datum.h
> **
Add this:
#ifndef DATUM_H
I wrote this script to help people streamline testing snapshot issues
when they identify an issue in a snapshot but do not necessarily know
where the issue might have occured (for instance they do not iteratively
keep up on snapshot releases). Based on the snapshots available at
"http://www.cygwin.
I'm trying to debug a sever slowdown seen between 0309 and 0313 snapshots. I
noticed
this when upgrading to the latest and had to trace it back (part of the impetus
for
writing the script I mentioned earlier). It appears to affect all file
operations
within a shell, but not necessarily within a
On Sun, May 14, 2006 at 01:24:04PM -0700, [EMAIL PROTECTED] wrote:
> not even slowdown that could be explained by typical fork overhead, it's
> literally
> 200% the difference.
>
> >From 20060313 and any snapshot above that, I see the exact same behavior.
> >From any
> below *and including* 2006
On Sun, May 14, 2006 at 01:49:49PM -0700, [EMAIL PROTECTED] wrote:
> On Sun, May 14, 2006 at 01:24:04PM -0700, [EMAIL PROTECTED] wrote:
> > not even slowdown that could be explained by typical fork overhead, it's
> > literally
> > 200% the difference.
> >
> > >From 20060313 and any snapshot above
On Fri, May 12, 2006 at 12:49:36PM -0700, Brian Dessent wrote:
>
> It has nothing to do with file locking, but rather locking in the sense
> of thread-safety. A programmer can call the _unlocked version of a
> number of functions when he is sure that the application only has one
> thread, and avo
On Wed, May 10, 2006 at 02:01:35PM -0400, Christopher Faylor wrote:
> There are a few reported problems with the current snapshots that
> require some debugging:
>
> 1) http://cygwin.com/ml/cygwin/2006-04/msg00718.html
>
> I would appreciate knowing if anyone can duplicate 1) above and
> I'd like
> Hmm. I don't see any reason for you to have included my message,
> ignored it, and then used this thread to 1) reiterate observations you
> made in another message and/or 2) discuss something unrelated to my
> request.
>
> cgf
I don't see any reason for your rude reply to me. Read your own mes
BTW, isn't is possible to just make the console window created start
without SW_VISIBLE? While it would still be created - it would be
created invisbly.
-cl
On Mon, May 15, 2006 at 01:08:07PM -0400, Harig, Mark wrote:
> The new console-hiding code causes the console window to be automatically
>
On Mon, May 15, 2006 at 11:16:12AM -0700, George wrote:
> Friendly is a girl with a nice smile holding my hand and pressing my
> keys for me while serving me rum drinks with little umbrellas in them.
See the real issue here is how we can configure rxvt to provide the above.
> No?
>
> Ok, how ab
On Tue, May 16, 2006 at 11:03:01AM -0400, Jeff Lange wrote:
> well I've given up on that, now I'm hacking away at puttycyg to make
> it do what I need it to do, like send out the correct high F keys, and
> adding an argument to make it full screen on startup. =)
>
> Thanks,
> -Jeff
Do you use a 6
On Tue, May 16, 2006 at 09:08:28AM -0500, Tom Rodman wrote:
> If I revert to the April 3 snapshot it works fine. For the 4/27
> snapshot, it's repeatable, the commands above resulted in fork errors
> when I tried it just after after a reboot today, and again after all
> cygwin processes had been ki
> From: Corinna Vinschen
> To: cygwin at cygwin dot com
> Subject: Re: listen/accept/fork behavior problem between cygwin1 1.5.18 and
> cygwin1.dll 1.5.19
> Message-ID: <[EMAIL PROTECTED]>
> Reply-To: cygwin at cygwin dot com
>
> On Mar 9 17:54, BRC wrote:
> > Hi,
> >
> > I have a perl based s
On Sat, May 20, 2006 at 06:42:07PM +0300, Jagan Mohan wrote:
> I'm doing a little something for the earth, and I thought I'd invite
> you to join me:
>
> http://friends.earthscreen.com/?r=cQGEWBETCSZWBmEOAiEE&i=gmail&[EMAIL
> PROTECTED]&p=1&z=1&tc=11
"How does it work? It's simple! Sign up at f
On Sun, May 21, 2006 at 07:14:52AM -0700, Brian Dessent wrote:
> Richard Schmitt wrote:
>
> > - downloaded the latest gdb (6.4), built it and installed it.
> > [...]
> > doesn't suffer from this problem? The issue was fixed in CVS earlier
> > this year. But do note that it requires functionality
On Sun, May 21, 2006 at 04:39:18PM -0400, Christopher Faylor wrote:
> >6.4 works, but I've found that no matter what, initializing the
> >following:
>
> There is no way that 6.4 is going to fix this problem since, as Brian
> noted, its release predates the fix that I checked in to deal with the
>
On Sun, May 21, 2006 at 06:40:45PM -0400, Christopher Faylor wrote:
> Again, Brian answered the question correctly. Building a 6.4 version of
> gdb is not going to solve this problem.
>
> cgf
Okay, so what is the exact answer?
Is it: CVS HEAD build of gdb will fix the issue?
-cl
--
Unsubscrib
On Sun, May 21, 2006 at 10:19:06PM -0400, Igor Peshansky wrote:
> Noticed a problem today: if you start a Windows process in bash and press
> Ctrl-C, the Ctrl-C will be delivered to the process, but then bash (or the
> Cygwin wrapper that waits for the Windows process) will simply hang until
> the
On Mon, May 22, 2006 at 06:50:38PM -0700, David Christensen wrote:
> 3. Last but not least, the open-source software (OSS) movement used to
> have at its core the concept of "Freedom", including "Freedom of
> Speech". OSS projects were simply assumed by the OSS community to
> allow fr
On Wed, May 24, 2006 at 01:49:53AM -0700, Brian Dessent wrote:
> Sigh. We've been through this ad nauseum in the archives. This is how
> it's supposed to work, there's nothing wrong here. Gdb doesn't know any
> better though, and reports it as a SIGSEGV, when it is not. Did you not
> notice tha
On Wed, May 24, 2006 at 11:40:58AM +0100, Dave Korn wrote:
> > Actually, is this really a fault in gdb? Cygwin is throwing a SIGSEGV
> > signal, correct? GDB does what it's told, stops on SIGSEGV by default.
> >
> > -cl
>
> But it doesn't interact properly with cygwin's exception handling -> si
On Wed, May 24, 2006 at 07:06:32PM +0100, Dave Korn wrote:
> YES, THERE IS A WAY!
>
> WHAT IS MORE YOU HAVE ALREADY HAD IT EXPLAINED TO YOU A DOZEN TIMES IN THIS
> THREAD!
>
> THE WAY IS TO USE AN UP-TO-DATE GDB!
BTW:
Myself, I had just updated to CVS gdb. Currently it looks like SIGINT
On Thu, May 25, 2006 at 12:34:10PM -0500, mwoehlke wrote:
> Here is what I am talking about:
> ~$ mount h:/mwoehlke/src /usr/src
> mount: defaulting to '--no-executable' flag for speed since native path
>references a remote share. Use '-f' option to override.
>
On Thu, May 25, 2006 at 02:11:09PM -0400, Christopher Faylor wrote:
> Language, please. Warning #1.
Feel the power.
> >Cut people some slack for once - they're on the same side as you trying to
> >achieve the same goals.
>
> What you apparently are failing to realize is that while people
> cert
On Sun, May 28, 2006 at 01:04:52PM +0200, Ralf Habacker wrote:
> I just downloaded cywin snapshot 2005-06-27 and got running designer and
> uic without any problem, so it looks like there is no need to deep
> more into this stuff. I will follow the next time if this problems takes
> places again.
> That's just a tad old there, Ralf.
> Tried any of the more recent snapshots at http://www.cygin.com/snapshots/ ?
Mistype.
http://www.cygwin.com/snapshots/
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation:
On Wed, Jun 14, 2006 at 10:40:25PM +0200, Corinna Vinschen wrote:
>
> Thanks very much for your testcase. I applied a patch to Cygwin, please
> give the next developer snapshot from http://cygwin.com/snapshots/ a try.
>
> Corinna
Thank you Corinna. This appears to work much better and expected.
On Thu, Jun 15, 2006 at 09:58:40AM +0200, Corinna Vinschen wrote:
> > thread + select(). One thing I notice is that if a read() is in progress
> > and one
> > is currently sitting in select(), all other read()s in seperate select()s
> > will
> > then stall if the former read() times out or takes
On Thu, Jun 15, 2006 at 01:20:40AM -0700, Kyle McKay wrote:
> 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.
Same here.
> Finally, it NEVER works no matter what if you are debugging a pr
This doesn't look like a cygwin problem to me at all. Look at the first 20
lines of your debug output again.
-cl
On Thu, Jun 15, 2006 at 04:46:23AM -0700, marct wrote:
> "Read from socket failed: Connection reset by peer"
AKA "you sent bunk data, try again."
> $ ssh -vvv localhost
> OpenSSH_4.
It should also be noted that some of the latest snapshot, or code that
still exists in the latest snapshot, will fail under 4.1.1. Specifically:
declaration of objects within a label statement.
-cl
On Mon, Jun 26, 2006 at 09:52:41PM +0100, Joe Schmoe wrote:
> Thanks to all that encouragement, I
On Mon, Jun 26, 2006 at 04:35:30PM -0700, Linda Walsh wrote:
> I've got a weird situation with rsync. I'm trying to
> transfer some files from a network share mounted as "B:\".
Anything strange about the filenames in those directories?
Colons or otherwise?
--
Unsubscribe info: http://cygwi
Do you like pain?
-cl
On Wed, Jun 28, 2006 at 04:01:57PM +0530, hulge hulge wrote:
> hi all
> while compiling kernel i am getting following error
> when i run command make bzImage
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problem
On Sat, Jul 01, 2006 at 03:42:00PM -0400, Joe Smith wrote:
>
> "Christopher Faylor" <[EMAIL PROTECTED]> wrote in
> >
> >No. The mailing list descriptions really are accurate. If you don't
> >have a patch, then you shouldn't be sending email to cygwin-patches.
> >
>
> Most cygwin development di
-/* undocumented in wsock32.dll */
-extern "C" unsigned int WINAPI inet_network (const char *);
-
extern "C" unsigned int
cygwin_inet_network (const char *cp)
@@ -157,7 +152,5 @@ cygwin_inet_network (const char *cp)
if (efault.faulted (EFAULT))
return INADDR_NONE;
- unsigned int res = in
Is it just me or is cygwin fork(), or a support syscall underneath,
terribly slow for some reason? While building projects using libtool
(which using heavy sh, hence fork() calls) I regularly have to fire off
'make -j16's just to get around waiting ages when using a single make job.
-cl
--
Unsubs
On Fri, Sep 01, 2006 at 11:12:59AM +0100, Dave Korn wrote:
> > Is it just me or is cygwin fork(), or a support syscall underneath,
> > terribly slow for some reason?
>
> Some reason == "lack of O/S support".
Yes I can understand that. I'm assuming there is some CreateProcess()
magic happening
On Fri, Sep 01, 2006 at 11:12:59AM +0100, Dave Korn wrote:
> On 01 September 2006 11:02, [EMAIL PROTECTED] wrote:
>
> > Is it just me or is cygwin fork(), or a support syscall underneath,
> > terribly slow for some reason?
>
> Some reason == "lack of O/S support".
Basically, this is what I'm
On Fri, Sep 01, 2006 at 10:33:47AM -0400, Igor Peshansky wrote:
> While Cygwin is an *emulation* layer, and emulation is inherently slower
> than straight execution, there are other potential reasons for the
> slowness. Check your anti-virus and firewall software settings. If
> possible, exclude
On Fri, Sep 01, 2006 at 08:37:09AM -0700, [EMAIL PROTECTED] wrote:
>
> 1157123322 + echo blah1
> 1157123322 blah1
> <3 seconds of doing absolutely nothing here>
> 1157123325 + test -z ''
> 1157123325 + echo blah2
> 1157123325 blah2
I just also copied the same libtool to 3 different hard drives, o
On Fri, Sep 01, 2006 at 11:54:03AM -0400, Christopher Faylor wrote:
> >It's definitely none of those as I don't run any firewall or antivirus
> >software whatsoever on this box. Windows 2003 Server, minimal set of
> >services. The machine literally sits at 0% CPU unless I'm using it.
>
> Try using
On Fri, Sep 01, 2006 at 09:09:11AM -0700, [EMAIL PROTECTED] wrote:
> On Fri, Sep 01, 2006 at 11:54:03AM -0400, Christopher Faylor wrote:
> > >It's definitely none of those as I don't run any firewall or antivirus
> > >software whatsoever on this box. Windows 2003 Server, minimal set of
> > >service
On Fri, Sep 01, 2006 at 09:34:15AM -0700, [EMAIL PROTECTED] wrote:
> BTW:
> I started up filemon to watch what was going on from it's standpoint, and it
> shows a huge number of READs on libtool, all SUCCESS, but the offset is always
> 1 higher than previous, with a length of 1. Like it's literally
On Fri, Sep 01, 2006 at 10:04:51AM -0700, [EMAIL PROTECTED] wrote:
> I've since removed the setmode() calls within a bash build and am testing now.
>
> UPDATE:
> SOLVED.
>
> Filemon now shows bash reading in 8k chunks. There is now no 3 second delay on
> reading the rest of the bash script (which
On Fri, Sep 01, 2006 at 01:24:57PM -0400, Christopher Faylor wrote:
> >In regards to setting the fd to textmode as a way of stripping CRs.
> >Only problem is that it's making 213,110 syscalls for a 213k libtool
> >script. That cannot be an efficient way to remove CRs from input.
>
> Opening a fil
56 matches
Mail list logo
