On Jul 15 09:08, Eric Blake wrote:
> On 07/15/2015 08:24 AM, Ken Brown wrote:
> >> Got it. What's needed is a Cygwin-specific fault-*.h file which exposes
> >> how to fetch the stack pointer register from mcontext_t. As you can see
> >> from the plethora of fault-*.h files in the src subdir, this
On 07/15/2015 08:24 AM, Ken Brown wrote:
>> Got it. What's needed is a Cygwin-specific fault-*.h file which exposes
>> how to fetch the stack pointer register from mcontext_t. As you can see
>> from the plethora of fault-*.h files in the src subdir, this is highly
>> system-specific anyway.
>>
>>
On 7/15/2015 8:44 AM, Corinna Vinschen wrote:
On Jul 15 09:51, Corinna Vinschen wrote:
Hi guys,
On Jul 14 22:07, Ken Brown wrote:
Entering directory
'/home/kbrown/src/cyglibsigsegv/libsigsegv-2.10-1.x86_64/build/tests'
Test passed.
PASS: sigsegv1.exe
Test passed.
PASS: sigsegv2.exe
Doing SIGSE
On Jul 15 09:51, Corinna Vinschen wrote:
> Hi guys,
>
> On Jul 14 22:07, Ken Brown wrote:
> > Entering directory
> > '/home/kbrown/src/cyglibsigsegv/libsigsegv-2.10-1.x86_64/build/tests'
> > Test passed.
> > PASS: sigsegv1.exe
> > Test passed.
> > PASS: sigsegv2.exe
> > Doing SIGSEGV pass 1.
> > S
Hi guys,
On Jul 14 22:07, Ken Brown wrote:
> On 7/14/2015 6:03 PM, Eric Blake wrote:
> >On 07/08/2015 01:39 PM, Warren Young wrote:
> >>A search for "sigaltstack” on code.openhub.net found only 95 projects with
> >>this string in their source code, almost entirely consisting of *receivers*
> >>o
On 7/14/2015 6:03 PM, Eric Blake wrote:
On 07/08/2015 01:39 PM, Warren Young wrote:
- New API sigaltstack, plus definitions for SA_ONSTACK, SS_ONSTACK, SS_DISABLE,
MINSIGSTKSZ, SIGSTKSZ.
Since these were entirely missing before, this can’t be tested without
rebuilding software, right? Whe
On 07/08/2015 01:39 PM, Warren Young wrote:
>> - New API sigaltstack, plus definitions for SA_ONSTACK, SS_ONSTACK,
>> SS_DISABLE,
>> MINSIGSTKSZ, SIGSTKSZ.
>
> Since these were entirely missing before, this can’t be tested without
> rebuilding software, right? When rebuilt, existing Cygwin pa
On Jul 8 13:39, Warren Young wrote:
> On Jul 5, 2015, at 3:34 PM, Corinna Vinschen
> wrote:
> > ...RLIMIT_STACK...RLIM_INFINITY.
>
> This should fix the Emacs crash you reference later in this message
> without rebuilding Emacs, right?
>
> I’m not an Emacs user, as you know, but is there an ST
On 7/8/2015 3:39 PM, Warren Young wrote:
On Jul 5, 2015, at 3:34 PM, Corinna Vinschen wrote:
...RLIMIT_STACK...RLIM_INFINITY.
This should fix the Emacs crash you reference later in this message without
rebuilding Emacs, right?
I’m not an Emacs user, as you know, but is there an STC for the
On Jul 5, 2015, at 3:34 PM, Corinna Vinschen wrote:
> ...RLIMIT_STACK...RLIM_INFINITY.
This should fix the Emacs crash you reference later in this message without
rebuilding Emacs, right?
I’m not an Emacs user, as you know, but is there an STC for the Emacsizens to
try on their systems?
> - N
On Jul 7 15:37, Ken Brown wrote:
> On 7/7/2015 2:49 PM, Corinna Vinschen wrote:
> >I spoke too soon. This *is* a result of the alternate stack handling.
> >When the exception occurs while running on the alternate stack, the OS
> >exception handler checks if the stack pointer is valid, and since i
On 7/7/2015 2:49 PM, Corinna Vinschen wrote:
I spoke too soon. This *is* a result of the alternate stack handling.
When the exception occurs while running on the alternate stack, the OS
exception handler checks if the stack pointer is valid, and since it's
not in the stackarea as stored in the T
On Jul 7 14:05, Ken Brown wrote:
> On 7/7/2015 11:49 AM, Corinna Vinschen wrote:
> >On Jul 6 18:34, Corinna Vinschen wrote:
> >>On Jul 6 11:54, Ken Brown wrote:
> >>>On 7/6/2015 10:45 AM, Corinna Vinschen wrote:
> If you want to know how big your current stack *actually* is, you can
> ut
On 7/7/2015 11:49 AM, Corinna Vinschen wrote:
On Jul 6 18:34, Corinna Vinschen wrote:
On Jul 6 11:54, Ken Brown wrote:
On 7/6/2015 10:45 AM, Corinna Vinschen wrote:
If you want to know how big your current stack *actually* is, you can
utilize pthread_getattr_np on Linux and Cygwin, like this
On Jul 6 18:34, Corinna Vinschen wrote:
> On Jul 6 11:54, Ken Brown wrote:
> > On 7/6/2015 10:45 AM, Corinna Vinschen wrote:
> > >If you want to know how big your current stack *actually* is, you can
> > >utilize pthread_getattr_np on Linux and Cygwin, like this:
> > >
> > >#include
> > >
> > >
On Jul 6 11:54, Ken Brown wrote:
> On 7/6/2015 10:45 AM, Corinna Vinschen wrote:
> >Does emacs call setrlimit by any chance?
>
> Yes, that's the problem. The initialization code contains essentially the
> following:
>
> if (!getrlimit (RLIMIT_STACK, &rlim))
> {
> long newlim;
>
On 7/6/2015 10:45 AM, Corinna Vinschen wrote:
Does emacs call setrlimit by any chance?
Yes, that's the problem. The initialization code contains essentially the
following:
if (!getrlimit (RLIMIT_STACK, &rlim))
{
long newlim;
/* Approximate the amount regex.c needs per unit o
On Jul 6 09:32, Ken Brown wrote:
> On 7/6/2015 9:15 AM, Ken Brown wrote:
> >On 7/6/2015 6:01 AM, Corinna Vinschen wrote:
> >>You can utilize tib and m for testing in emacs as well. Just do this:
> >>
> >> #include
> >>
> >> NT_TIB *tib;
> >> MEMORY_BASIC_INFORMATION m;
> >>
> >> [...]
>
Hi Ken,
On Jul 6 09:15, Ken Brown wrote:
> Hi Corinna,
>
> On 7/6/2015 6:01 AM, Corinna Vinschen wrote:
> >On Jul 5 22:15, Ken Brown wrote:
> >
> >I have no explanation for this. What OS? What does rlim_cur contain?
> >What does peflags -x print for this executable?
>
> I'm on W7 64-bit. Th
On 7/6/2015 9:15 AM, Ken Brown wrote:
Hi Corinna,
On 7/6/2015 6:01 AM, Corinna Vinschen wrote:
Hi Ken,
thanks for further testing this.
On Jul 5 22:15, Ken Brown wrote:
On 7/5/2015 5:34 PM, Corinna Vinschen wrote:
This test release needs some good testing!
I repeated the emacs experime
Hi Corinna,
On 7/6/2015 6:01 AM, Corinna Vinschen wrote:
Hi Ken,
thanks for further testing this.
On Jul 5 22:15, Ken Brown wrote:
On 7/5/2015 5:34 PM, Corinna Vinschen wrote:
This test release needs some good testing!
I repeated the emacs experiment discussed in the "[ANNOUNCEMENT] TES
Hi Ken,
thanks for further testing this.
On Jul 5 22:15, Ken Brown wrote:
> On 7/5/2015 5:34 PM, Corinna Vinschen wrote:
> >This test release needs some good testing!
>
> I repeated the emacs experiment discussed in the "[ANNOUNCEMENT] TEST
> RELEASE: Cygwin 2.1.0-0.1" thread. In the 32-bit
On 7/5/2015 5:34 PM, Corinna Vinschen wrote:
This test release needs some good testing!
I repeated the emacs experiment discussed in the "[ANNOUNCEMENT] TEST RELEASE:
Cygwin 2.1.0-0.1" thread. In the 32-bit case, the results were more-or-less the
same as before: I forced a stack overflow, em
Hi Cygwin friends and users,
I released another TEST version of Cygwin. The version number is
2.1.0-0.4.
This test release needs some good testing!
While the changes are still mostly interesting for developers, the
under-the-hood changes will potentially impact existing applications.
I'd like
24 matches
Mail list logo
