On Fri, Jul 17, 2009 at 10:55:13PM +, Eric Blake wrote:
>Eric Blake byu.net> writes:
>>Of course, given the code, that meant I wasn't using libsigsegv like I
>>thought I was. So, with my typo corrected, I'm (unfortunately) still
>>seeing libsigsegv interference:
>>
>>$ ./foo fclose -1, errno
- Original Message -
From: "Christopher Faylor"
Hmmm don't quite follow you there Chris, could you elaborate on what you
mean by "per program"?
Does "per-process" make it any clearer? Each process can start 256
subprocesses.
Yes that does, thanks :)
--
Problem reports: http
Eric Blake wrote:
> And I'm not sure what to do in gdb to try and get more useful information:
'step' rather than 'next'. Requires cygwin1.dbg.
cheers,
DaveK
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation:
Eric Blake byu.net> writes:
> > As I said above, I assume that MVFS has a problem similar to what we
> > have for remote HPFS. It's not sufficient to set only the minimal
> > set of access flags in calls to NtCreateFile/NtOpenFile in some
> > circumstances. I can't tell where the problem is for
Eric Blake byu.net> writes:
> Of course, given the code, that meant I wasn't using libsigsegv like I
thought
> I was. So, with my typo corrected, I'm (unfortunately) still seeing
libsigsegv
> interference:
>
> $ ./foo
> fclose -1, errno 9
> Aborted (core dumped)
Even more depressing - this
On Fri, Jul 17, 2009 at 11:03:34PM +0100, Steven Hartland wrote:
>On Fri, 17 Jul 2009 14:25:33 -0400 Christopher Faylor wrote:
>> The process limit is 256 per program. You should see an EAGAIN errno
>> being set if the process limit is hit. The overall per-user process
>> limit is controlled by W
Eric Blake byu.net> writes:
> Now, upgrade to the latest snapshot, 20090717.
>
> Without libsigsegv, things operate as before. But with libsigsegv, I now
see...
Aargh. I spoke too soon. For my previous mail, I fat-fingered my command
line, and ended up compiling with:
$ gcc
Eric Blake wrote:
> This post is so cgf can exhale his bated breath from his recent commit:
> That is, libsigsegv no longer causes an unwanted abort. And the latest
> libsigsegv.git package still passes 'make check'. So in other words, it
> looks
> like you fixed a real bug, and without causi
th the SEH
chain is not nice.
Now, upgrade to the latest snapshot, 20090717.
Without libsigsegv, things operate as before. But with libsigsegv, I now see...
wait for it...
(Sorry for dragging this on, but you DID say you were waiting with bated
breath. :)...
$ ./foo
fclose -1, errno 9
- Original Message -
From: "Christopher Faylor"
The process limit is 256 per program. You should see an EAGAIN errno
being set if the process limit is hit. The overall per-user process
limit is controlled by Windows.
Hmmm don't quite follow you there Chris, could you elaborate on w
İsmail Dönmez wrote:
Hi,
I got a weird problem with Cygwin. I am using Cygwin 1.7 on Windows 7
RC (x64) and noticed that configure scripts are real slow and tried
some simple tests and to my surprise
mkdir /foo
takes up to 18 seconds! But interestingly time(1) is lying to me :
[~]> time mkdir
On Fri, Jul 17, 2009 at 06:36:16PM +0200, Corinna Vinschen wrote:
>On Jul 17 11:44, Christopher Faylor wrote:
>> On Fri, Jul 17, 2009 at 05:29:20PM +0200, Corinna Vinschen wrote:
>> >On Jul 17 15:23, Dave Korn wrote:
>> >> Corinna Vinschen wrote:
>> >> > Do we have to take other handlers than the O
On Fri, Jul 17, 2009 at 07:13:21PM +0100, Steven Hartland wrote:
>Having a strange issue where process creation seems to fail for no good
>reason. I think I've hit a process creation limit.
>
>Googling around I found:
>http://www.cygwin.com/ml/cygwin/1998-01/msg00249.html
>
>Is it still the case t
Having a strange issue where process creation seems to
fail for no good reason. I think I've hit a process
creation limit.
Googling around I found:
http://www.cygwin.com/ml/cygwin/1998-01/msg00249.html
Is it still the case that cygwin is limited to a max
number of processes and is this on a user
> I'd like to give Ralph a self-indulgent gold star for the first time
> ever suggestion that I have a thick skin.
>
> Oh, and now that I think of it, he deserves one for his setup.exe
> contributions too. He's a tireless supporter of the setup.exe command
> line.
Done.
--
Problem reports:
Christopher Faylor wrote:
> On Fri, Jul 17, 2009 at 05:29:20PM +0200, Corinna Vinschen wrote:
>> On Jul 17 15:23, Dave Korn wrote:
>>> Nope, they don't, but that will probably not be the case forever,
> Right, and I don't know how you could make the claim that Cygwin apps
> don't install SEH ha
Hi,
I got a weird problem with Cygwin. I am using Cygwin 1.7 on Windows 7
RC (x64) and noticed that configure scripts are real slow and tried
some simple tests and to my surprise
mkdir /foo
takes up to 18 seconds! But interestingly time(1) is lying to me :
[~]> time mkdir /foo
mkdir /foo 0.00s
On Jul 16 17:15, Eric Blake wrote:
> Corinna Vinschen cygwin.com> writes:
> > Eric Blake wrote:
> > > Maybe for MVFS it would be better to
> > > return EBUSY instead of letting unlink succeed when the handle is
> > > still open by another process:
> >
> > That would be something I could add, but
On Jul 17 11:44, Christopher Faylor wrote:
> On Fri, Jul 17, 2009 at 05:29:20PM +0200, Corinna Vinschen wrote:
> >On Jul 17 15:23, Dave Korn wrote:
> >> Corinna Vinschen wrote:
> >> > Do we have to take other handlers than the OS handlers and the Cygwin
> >> > handlers into account? Cygwin apps do
On Fri, Jul 17, 2009 at 04:22:01PM +, Eric Blake wrote:
>Christopher Faylor cygwin.com> writes:
>>Right, and I don't know how you could make the claim that Cygwin apps
>>don't install SEH handlers. We can't possibly know how every Cygwin
>>app does this. Obviously there's at least one app ou
Christopher Faylor cygwin.com> writes:
> Right, and I don't know how you could make the claim that Cygwin apps
> don't install SEH handlers. We can't possibly know how every Cygwin app
> does this. Obviously there's at least one app out there which has
> decided that it needs to use Windows-spe
On Fri, Jul 17, 2009 at 05:29:20PM +0200, Corinna Vinschen wrote:
>On Jul 17 15:23, Dave Korn wrote:
>> Corinna Vinschen wrote:
>> > Do we have to take other handlers than the OS handlers and the Cygwin
>> > handlers into account? Cygwin apps don't install SEH handlers, do
>> > they? Or do C++ ap
Eric Blake wrote:
>
> You shouldn't need the hack at all, once the next cygwin snapshot
> is made available.
>
Oh! This fast!
I just thought I would have to live with this longer.
Thanks,
Marc
--
View this message in context:
http://www.nabble.com/.-*-lock-files-under-X%2C-for-files-I-edit---
On Jul 17 15:23, Dave Korn wrote:
> Corinna Vinschen wrote:
> > Do we have to take other handlers than the OS handlers and the Cygwin
> > handlers into account? Cygwin apps don't install SEH handlers, do
> > they? Or do C++ apps?
>
> Nope, they don't, but that will probably not be the case for
Dave Korn googlemail.com> writes:
> That looks fairly robust to me, shouldn't give us any problems. Question
> is, what does the code that hooks and unhooks the exception handler look like,
> and where does it get called from?
static void
do_install_main_exception_filter ()
{
/* We cannot i
> My emacs crashed (Memory Full).
> I don't know whether this may be related.
> It had not done so for long.
> This might well be a side-effect of this purify-flag...
Yes, messing with purify-flag is dangerous.
> Maybe I could set it to nil on some later function?
>
> Otherwise, my hack seems t
Eric Blake wrote:
> static int (*cygwin_exception_handler) (EXCEPTION_RECORD *, void *, CONTEXT
> *,
> void *);
>
> /* Our exception handler. */
> static int
> libsigsegv_exception_handler (EXCEPTION_RECORD *exception, void *frame,
> CONTEXT
> *context, void *dispatch)
> {
> EXCEPTION_POIN
Marc Girod wrote:
>
> Just two fixes for now:
>
My emacs crashed (Memory Full).
I don't know whether this may be related.
It had not done so for long.
This might well be a side-effect of this purify-flag...
Maybe I could set it to nil on some later function?
Otherwise, my hack seems to work we
Corinna Vinschen cygwin.com> writes:
> Do we have to take other handlers than the OS handlers and the Cygwin
> handlers into account? Cygwin apps don't install SEH handlers, do
> they? Or do C++ apps?
I believe that libsigsegv does its magic by installing an SEH handler.
libsigsegv is a C li
Corinna Vinschen wrote:
> On Jul 17 14:38, Dave Korn wrote:
>> Corinna Vinschen wrote:
>>> Assuming that skipping the OS handlers is OK,
>> What if they are tryfinally handlers rather than tryexcept? Bad
>> things might happen? It might be useful to know what those functions are
>
>
On Jul 17 14:38, Dave Korn wrote:
> Corinna Vinschen wrote:
> > AFAICS, the problem is that _my_tls.el is not the active SEH handler at
> > this point, but it is already part of the chain,
> > _cygtls::init_exception_handler doesn't check for validity and just
> > overwrites the entry in an invalid
Corinna Vinschen cygwin.com> writes:
> && !is_mvfs (RtlEqualUnicodePathPrefix (&fsname, &ro_u_mvfs, FALSE))
>
> This checks for a MVFS prefix instead of equality of the entire string.
Progess report. I can confirm that with cygwin1.dll built from the latest CVS,
emacs can now create and des
On Fri, 17 Jul 2009, Dave Korn wrote:
I wanted to "save" one, I did that by leaving the power on indefinitely ...
You had power? Luxury! I had to keep pedaling the bicycle!
-s
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentatio
Corinna Vinschen wrote:
> AFAICS, the problem is that _my_tls.el is not the active SEH handler at
> this point, but it is already part of the chain,
> _cygtls::init_exception_handler doesn't check for validity and just
> overwrites the entry in an invalid way.
Argh. Yes, there's no way we can
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Corinna Vinschen on 7/17/2009 1:15 AM:
> Can we be sure that every version of MVFS has this obvious bug in
> the name?
Given that it's a bug in the first place, probably not.
> I'd rather replace the following line in mount.cc,
> fs_inf
From: "Steven Hartland"
From: Christopher Faylor
On Jul 16 17:18, Christopher Faylor wrote:
> On Thu, Jul 16, 2009 at 09:55:52PM +0200, Corinna Vinschen wrote:
> >On Jul 16 17:47, Dave Korn wrote:
> >> You might want to try again with a watchpoint:
> >>
> >> watch *(unsigned int*)0x88ce68
> >>
> >> ... and see how and where that head entry ge
From: Corinna Vinschen
Will Parsons writes:
Is there no way of just creating the file without using crontab -e?
>>>
>>>Sure. I've been editing crontabs for years and have never once used
>>>crontab -e. What I do:
>>>
>>>crontab -l > crontab.lst edit crontab.lst crontab crontab.lst
>>
>> I always just use the togg
On Jul 17 01:17, Eric Blake wrote:
> Eric Blake byu.net> writes:
>
> > Does the fact that MVFS is including the trailing NUL in fsname.Length, but
> > ro_u_mvfs is not, relevant to RtlEqualUnicodeString returning false, even
> > though the two Buffers are identical over their MaximumLength?
> >
41 matches
Mail list logo
