Just wanted to confirm upgrading to 1.7.0-25 ( with the SEH fix )
fixes this issue under Windows 2008 R2.
Thanks again to those involved in identifying and fixing this issue.
Regards
Steve
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/
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
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
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
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
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
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 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
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
Corinna Vinschen wrote:
> So this exception handler is installed as part of the Perl threads DLL
> initialization. But appanrelty the address is not valid anymore when
> leaving the DLL initialization.
> Is it possible that we have to remove the exception handler before
> dll_dllcrt0_1 returns?
On Thu, Jul 16, 2009 at 09:55:52PM +0200, Corinna Vinschen wrote:
>On Jul 16 17:47, Dave Korn wrote:
>> Corinna Vinschen wrote:
>>
>> > And that's what I get in the Perl testcase:
>> >
>> > (gdb) x/xw 0x7efdd000
>> > 0x7efdd000: 0x0088ce68
>> > (gdb) x/2xw 0x0088ce68
>> > 0x88ce68:
On Jul 16 17:47, Dave Korn wrote:
> Corinna Vinschen wrote:
>
> > And that's what I get in the Perl testcase:
> >
> > (gdb) x/xw 0x7efdd000
> > 0x7efdd000: 0x0088ce68
> > (gdb) x/2xw 0x0088ce68
> > 0x88ce68: 0x0088400c 0x6103ce20 <-- Cygwin exception handler
> > (gdb) x
On Thu, Jul 16, 2009 at 06:12:20PM +0200, Corinna Vinschen wrote:
>On Jul 15 21:42, Dave Korn wrote:
>> ... get the head pointer:
>>
>> (gdb) x/xw 0x7ffde000
>> 0x7ffde000: 0x0022ce68
>>
>> ... on the stack, as you might expect, and walk the chain, first word of each
>> record is the 'next' p
Corinna Vinschen wrote:
> And that's what I get in the Perl testcase:
>
> (gdb) x/xw 0x7efdd000
> 0x7efdd000: 0x0088ce68
> (gdb) x/2xw 0x0088ce68
> 0x88ce68: 0x0088400c 0x6103ce20 <-- Cygwin exception handler
> (gdb) x/2xw 0x0088400c
> 0x88400c: 0x
On Jul 15 23:01, Christopher Faylor wrote:
> On Thu, Jul 16, 2009 at 04:07:23AM +0200, Reini Urban wrote:
> >2009/7/15 Steven Hartland:
> >> This may or may not help:
> >>
> >> According to VC++ debugger it always dies with:
> >> Unhandled exception at 0x610d089d in perl.exe: 0xC005: Access vio
On Jul 15 21:42, Dave Korn wrote:
> ... get the head pointer:
>
> (gdb) x/xw 0x7ffde000
> 0x7ffde000: 0x0022ce68
>
> ... on the stack, as you might expect, and walk the chain, first word of each
> record is the 'next' pointer, second is the handler function:
>
> (gdb) x/2xw 0x0022ce68
> 0x22
On Jul 16 10:42, Dave Korn wrote:
> Corinna Vinschen wrote:
>
> >
> > Btw., *everybody* can test on Windows Server 2008:
> > http://www.microsoft.com/downloads/details.aspx?familyid=B6E99D4C-A40E-4FD2-A0F7-32212B520F50
>
> Ooh, that's handy. Perhaps more relevant: the R2 candidate?
>
> http:
Corinna Vinschen wrote:
>
> Btw., *everybody* can test on Windows Server 2008:
> http://www.microsoft.com/downloads/details.aspx?familyid=B6E99D4C-A40E-4FD2-A0F7-32212B520F50
Ooh, that's handy. Perhaps more relevant: the R2 candidate?
http://www.microsoft.com/downloads/details.aspx?familyid=
On Jul 16 04:21, Reini Urban wrote:
> 2009/7/16 Reini Urban:
> > 2009/7/15 Steven Hartland:
> >> This may or may not help:
> >>
> >> According to VC++ debugger it always dies with:
> >> Unhandled exception at 0x610d089d in perl.exe: 0xC005: Access violation
> >> reading location 0x0004.
> >
On Thu, Jul 16, 2009 at 04:07:23AM +0200, Reini Urban wrote:
>2009/7/15 Steven Hartland:
>> This may or may not help:
>>
>> According to VC++ debugger it always dies with:
>> Unhandled exception at 0x610d089d in perl.exe: 0xC005: Access violation
>> reading location 0x0004.
>>
>> According
2009/7/16 Reini Urban:
> 2009/7/15 Steven Hartland:
>> This may or may not help:
>>
>> According to VC++ debugger it always dies with:
>> Unhandled exception at 0x610d089d in perl.exe: 0xC005: Access violation
>> reading location 0x0004.
>>
>> According to gdb 0x610d089d = thread.cc:113
>
>
2009/7/15 Steven Hartland:
> This may or may not help:
>
> According to VC++ debugger it always dies with:
> Unhandled exception at 0x610d089d in perl.exe: 0xC005: Access violation
> reading location 0x0004.
>
> According to gdb 0x610d089d = thread.cc:113
Thanks!
This looks like almost ce
Steven Hartland wrote:
>
> - Original Message - From: "Dave Korn"
>> (gdb) b 113 if ((*object) == 0)
>> No symbol "object" in current context.
>> (gdb)
>>
>> Ah, that's bad. It might work on a DLL compiled with -O0 -g, but
>> here we
>> have a problem that the function gets inlined every
- Original Message -
From: "Dave Korn"
(gdb) b 113 if ((*object) == 0)
No symbol "object" in current context.
(gdb)
Ah, that's bad. It might work on a DLL compiled with -O0 -g, but here we
have a problem that the function gets inlined everywhere it's called. So
instead I set an unc
On Jul 15 21:42, Dave Korn wrote:
> Corinna Vinschen wrote:
> > On Jul 15 20:32, Dave Korn wrote:
> >> Yes. That's why I said "examine the SEH chain", not "look at the call
> >> stack". I reckoned that doing so might provide any insight into why the
> >> myfault was not invoked. For instance,
Corinna Vinschen wrote:
> On Jul 15 20:32, Dave Korn wrote:
>> Yes. That's why I said "examine the SEH chain", not "look at the call
>> stack". I reckoned that doing so might provide any insight into why the
>> myfault was not invoked. For instance, you might see something hooked into
>> the S
On Jul 15 20:32, Dave Korn wrote:
> Yes. That's why I said "examine the SEH chain", not "look at the call
> stack". I reckoned that doing so might provide any insight into why the
> myfault was not invoked. For instance, you might see something hooked into
> the SEH chain ahead of Cygwin's han
Christopher Faylor wrote:
> On Wed, Jul 15, 2009 at 05:58:25PM +0100, Dave Korn wrote:
>> Christopher Faylor wrote:
>>> On Wed, Jul 15, 2009 at 05:03:43PM +0100, Dave Korn wrote:
Corinna Vinschen wrote:
> What happens is that this statement
>
> if ((*object)->magic != magic)
- Original Message -
From: "Christopher Faylor"
The point is that this is generating the equivalent of a SEGV without
ever hitting Cygwin's "SEH" code. Setting a breakpoint on the line
would likely just show you the call stack but would not provide any
insight into why the myfault was no
On Wed, Jul 15, 2009 at 05:58:25PM +0100, Dave Korn wrote:
>Christopher Faylor wrote:
>> On Wed, Jul 15, 2009 at 05:03:43PM +0100, Dave Korn wrote:
>>> Corinna Vinschen wrote:
>>>
What happens is that this statement
if ((*object)->magic != magic)
in the function thread.cc
On Jul 15 12:23, Christopher Faylor wrote:
> On Wed, Jul 15, 2009 at 05:21:39PM +0200, Corinna Vinschen wrote:
> > SNIP
> >#include
> >#include
> >#include
> >
> >pthread_attr_t attr;
> >
> >void *thr (void *arg)
> >{
> > printf ("I'm a thread\n");
> > return NULL;
> >}
> >
> >int mai
Christopher Faylor wrote:
> On Wed, Jul 15, 2009 at 05:03:43PM +0100, Dave Korn wrote:
>> Corinna Vinschen wrote:
>>
>>> What happens is that this statement
>>>
>>> if ((*object)->magic != magic)
>>>
>>> in the function thread.cc:verifyable_object_isvalid throws an exception
>>> because *object i
On Wed, Jul 15, 2009 at 05:21:39PM +0200, Corinna Vinschen wrote:
>On Jul 15 01:41, Steven Hartland wrote:
>>
>> - Original Message - From: "Christopher Faylor"
>>
>
>http://cygwin.com/acronyms/#PCYMTNQREAIYR
>
>>> On Wed, Jul 15, 2009 at 12:36:56AM +0100, Steven Hartland wrote:
This
On Wed, Jul 15, 2009 at 05:03:43PM +0100, Dave Korn wrote:
>Corinna Vinschen wrote:
>
>> What happens is that this statement
>>
>> if ((*object)->magic != magic)
>>
>> in the function thread.cc:verifyable_object_isvalid throws an exception
>> because *object is NULL. This should be covered by
Corinna Vinschen wrote:
> What happens is that this statement
>
> if ((*object)->magic != magic)
>
> in the function thread.cc:verifyable_object_isvalid throws an exception
> because *object is NULL. This should be covered by the myfault handler
> in this function but for some reason it isn't
On Jul 15 01:41, Steven Hartland wrote:
>
> - Original Message - From: "Christopher Faylor"
>
http://cygwin.com/acronyms/#PCYMTNQREAIYR
>> On Wed, Jul 15, 2009 at 12:36:56AM +0100, Steven Hartland wrote:
>>> This may or may not help:
>>>
>>> According to VC++ debugger it always dies wit
- Original Message -
From: "Christopher Faylor"
To:
Sent: Wednesday, July 15, 2009 1:03 AM
Subject: Re: perl threads on 2008 R2 64bit = crash ( was: perl 5.10 threads on
1.5.25 = instant crash )
On Wed, Jul 15, 2009 at 12:36:56AM +0100, Steven Hartland wrote:
This may
On Wed, Jul 15, 2009 at 12:36:56AM +0100, Steven Hartland wrote:
>This may or may not help:
>
>According to VC++ debugger it always dies with:
>Unhandled exception at 0x610d089d in perl.exe: 0xC005: Access violation
>reading location 0x0004.
No, sorry, it really doesn't help. The VC++ de
This may or may not help:
According to VC++ debugger it always dies with:
Unhandled exception at 0x610d089d in perl.exe: 0xC005: Access violation
reading location 0x0004.
According to gdb 0x610d089d = thread.cc:113
So running it through gdb it hits this break point ~ 280 times before i
- Original Message -
From: "Christopher Faylor"
No joy here with 1.7 either, just crashes out instantly.
Running Windows Server 2008 R2 Standard 64bit build 7100 on dual E5520
with 18GB RAM showing 16 cores if that may be of interest.
gdb is not much help, so not sure what to try
On Tue, Jul 14, 2009 at 09:36:24PM +0100, Steven Hartland wrote:
>- Original Message -
>From: "Corinna Vinschen"
... and the script works fine on Windows 7 Build 7201 running under
Cygwin 1.7.
>
>No joy here with 1.7 either, just crashes out instantly.
>
>Running Windows Server
- Original Message -
From: "Corinna Vinschen"
... and the script works fine on Windows 7 Build 7201 running under
Cygwin 1.7.
No joy here with 1.7 either, just crashes out instantly.
Running Windows Server 2008 R2 Standard 64bit build 7100 on dual E5520
with 18GB RAM showing 16 cores
On Jul 14 20:38, Steven Hartland wrote:
> - Original Message - From: "Corinna Vinschen"
>
>> On Jul 14 14:55, Christopher Faylor wrote:
>>> On Tue, Jul 14, 2009 at 07:18:44PM +0100, Steven Hartland wrote:
>>> >On Tue, 14 Jul 2009 19:16:46 +0100, Dave Korn wrote:
>>> >>> sub dothread { pri
- Original Message -
From: "Corinna Vinschen"
On Jul 14 14:55, Christopher Faylor wrote:
On Tue, Jul 14, 2009 at 07:18:44PM +0100, Steven Hartland wrote:
>On Tue, 14 Jul 2009 19:16:46 +0100, Dave Korn wrote:
>>> sub dothread { print STDERR "I'm a thread!\n" }
>>> [/test]
>>
>> WFM wit
On Jul 14 14:55, Christopher Faylor wrote:
> On Tue, Jul 14, 2009 at 07:18:44PM +0100, Steven Hartland wrote:
> >On Tue, 14 Jul 2009 19:16:46 +0100, Dave Korn wrote:
> >>> sub dothread { print STDERR "I'm a thread!\n" }
> >>> [/test]
> >>
> >> WFM with perl 5.10.0 on both 1.5 and 1.7.
> >
> >Than
On Tue, Jul 14, 2009 at 07:18:44PM +0100, Steven Hartland wrote:
>On Tue, 14 Jul 2009 19:16:46 +0100, Dave Korn wrote:
>>> sub dothread { print STDERR "I'm a thread!\n" }
>>> [/test]
>>
>> WFM with perl 5.10.0 on both 1.5 and 1.7.
>
>Thanks Dave, maybe a Windows Server 2008 R2 64bit issue?
FYI,
- Original Message -
From: "Dave Korn"
sub dothread { print STDERR "I'm a thread!\n" }
[/test]
WFM with perl 5.10.0 on both 1.5 and 1.7.
Thanks Dave, maybe a Windows Server 2008 R2 64bit issue?
Regards
Steve
--
Problem reports: http://cygwin.com/problems.html
FAQ:
Steven Hartland wrote:
> [test]
> #!/bin/perl -w
>
> use warnings;
> use strict;
> use threads;
>
> print STDERR "Testing threads...\n";
> my $thrd = threads->create( \&dothread );
> $thrd->join();
> print STDERR "Testing done\n";
>
> sub dothread { print STDERR "I'm a thread!\n" }
> [/test]
Compiled at Jul 8 2007 19:12:08
%ENV:
CYGWIN=""
@INC:
/usr/lib/perl5/5.8/cygwin
/usr/lib/perl5/5.8
/usr/lib/perl5/site_perl/5.8/cygwin
/usr/lib/perl5/site_perl/5.8
/usr/lib/perl5/site_perl/5.8
/usr/lib/perl5/vendor_perl/5.8/cygwin
/usr/lib/perl5/vendor_perl/5.8
Been looking around but cant find any mention of it so asking here:
Is there a known issue with the latest 1.5.25 + perl 5.10 threads,
as doing anything with threads here causes an instant crash.
[test]
#!/bin/perl -w
use warnings;
use strict;
use threads;
print STDERR "Testing threads...\n";
m
55 matches
Mail list logo
