Bug #100399 for Tk: t/async.t crashes

Mon Nov 17 04:16:37 2014 lamprecht [...] cpan.org - Ticket created

Subject:

t/async.t crashes

Message body is not shown because it is too large.

Mon Nov 17 16:09:04 2014 SREZIC [...] cpan.org - Correspondence added

On 2014-11-17 04:16:37, LAMPRECHT wrote: Show quoted text

> On a Ubuntu 14.04 with Compiz Wm the testsuite (t/async.t) sometimes > causes a crash. The test async.t passes nevertheless. > This is a copy of the systems crash report. I removed the coredump > data for readability. Let me know if you want me to attach the whole > file.

I can reproduce the crash also on FreeBSD (if coredumps are enabled, otherwise the crash happens unnoticed).

Mon Nov 17 16:09:04 2014 The RT System itself - Status changed from 'new' to 'open'

Mon Nov 17 16:22:55 2014 SREZIC [...] cpan.org - Correspondence added

On 2014-11-17 16:09:04, SREZIC wrote: Show quoted text

> On 2014-11-17 04:16:37, LAMPRECHT wrote:

> > On a Ubuntu 14.04 with Compiz Wm the testsuite (t/async.t) sometimes > > causes a crash. The test async.t passes nevertheless. > > This is a copy of the systems crash report. I removed the coredump > > data for readability. Let me know if you want me to attach the whole > > file.

> > I can reproduce the crash also on FreeBSD (if coredumps are enabled, > otherwise the crash happens unnoticed).

This is probably caused by the following change (from perl5160delta.pod): Now there is an extra pass during global destruction to fire destructors on any objects that might be left after the usual passes that check for objects referenced by scalars [perl #36347]. A possible workaround is to replace CORE::exit() by POSIX::_exit(0). But this feels rather unclean, maybe I can find another solution.

Mon Nov 17 16:45:43 2014 SREZIC [...] cpan.org - Correspondence added

On 2014-11-17 16:22:55, SREZIC wrote: Show quoted text

> On 2014-11-17 16:09:04, SREZIC wrote:

> > On 2014-11-17 04:16:37, LAMPRECHT wrote:

> > > On a Ubuntu 14.04 with Compiz Wm the testsuite (t/async.t) > > > sometimes > > > causes a crash. The test async.t passes nevertheless. > > > This is a copy of the systems crash report. I removed the coredump > > > data for readability. Let me know if you want me to attach the > > > whole > > > file.

> > > > I can reproduce the crash also on FreeBSD (if coredumps are enabled, > > otherwise the crash happens unnoticed).

> > This is probably caused by the following change (from > perl5160delta.pod): > > Now there is an extra pass during global destruction to fire > destructors on any objects that might be left after the usual passes > that check for objects referenced by scalars [perl #36347]. > > A possible workaround is to replace CORE::exit() by POSIX::_exit(0). > But this feels rather unclean, maybe I can find another solution.

→ See experimental branch XXX-workaround-eager-global-destruction

Mon Nov 17 16:59:10 2014 ch.l.ngre [...] online.de - Correspondence added

Subject:	Re: [rt.cpan.org #100399] t/async.t crashes
Date:	Mon, 17 Nov 2014 22:58:58 +0100
To:	bug-Tk [...] rt.cpan.org
From:	Ch Lamprecht <ch.l.ngre [...] online.de>

Am 17.11.2014 um 22:45 schrieb Slaven_Rezic via RT: Show quoted text

> <URL: https://rt.cpan.org/Ticket/Display.html?id=100399 > > > On 2014-11-17 16:22:55, SREZIC wrote:

>> >> Now there is an extra pass during global destruction to fire >> destructors on any objects that might be left after the usual passes >> that check for objects referenced by scalars [perl #36347]. >> >> A possible workaround is to replace CORE::exit() by POSIX::_exit(0). >> But this feels rather unclean, maybe I can find another solution.

> > → See experimental branch XXX-workaround-eager-global-destruction >

Works here - no more coredumps.

Sun Dec 14 15:19:53 2014 SREZIC [...] cpan.org - Correspondence added

On 2014-11-17 16:59:10, ch.l.ngre@online.de wrote: Show quoted text

> Am 17.11.2014 um 22:45 schrieb Slaven_Rezic via RT:

> > <URL: https://rt.cpan.org/Ticket/Display.html?id=100399 > > > > > On 2014-11-17 16:22:55, SREZIC wrote:

> >> > >> Now there is an extra pass during global destruction to fire > >> destructors on any objects that might be left after the usual passes > >> that check for objects referenced by scalars [perl #36347]. > >> > >> A possible workaround is to replace CORE::exit() by POSIX::_exit(0). > >> But this feels rather unclean, maybe I can find another solution.

> > > > → See experimental branch XXX-workaround-eager-global-destruction > >

> > Works here - no more coredumps. >

The workaround is now in master. Unfortunately I have no idea for a real fix --- effectively it means that one has to avoid forking after a Tk window is created, or to quit child processes always with POSIX::_exit. I added an entry in the ToDo file. Regards, Slaven

Sun Dec 14 15:19:54 2014 SREZIC [...] cpan.org - Status changed from 'open' to 'patched'

Sat Jan 31 14:07:17 2015 SREZIC [...] cpan.org - Correspondence added

On 2014-12-14 15:19:53, SREZIC wrote: Show quoted text

> On 2014-11-17 16:59:10, ch.l.ngre@online.de wrote:

> > Am 17.11.2014 um 22:45 schrieb Slaven_Rezic via RT:

> > > <URL: https://rt.cpan.org/Ticket/Display.html?id=100399 > > > > > > > On 2014-11-17 16:22:55, SREZIC wrote:

> > >> > > >> Now there is an extra pass during global destruction to fire > > >> destructors on any objects that might be left after the usual > > >> passes > > >> that check for objects referenced by scalars [perl #36347]. > > >> > > >> A possible workaround is to replace CORE::exit() by > > >> POSIX::_exit(0). > > >> But this feels rather unclean, maybe I can find another solution.

> > > > > > → See experimental branch XXX-workaround-eager-global-destruction > > >

> > > > Works here - no more coredumps. > >

> > The workaround is now in master. Unfortunately I have no idea for a > real fix --- effectively it means that one has to avoid forking after > a Tk window is created, or to quit child processes always with > POSIX::_exit. > > I added an entry in the ToDo file. >

Tk 804.032_501 is released.

Sat Jan 31 14:07:19 2015 SREZIC [...] cpan.org - Status changed from 'patched' to 'resolved'

Sat Jan 31 14:07:19 2015 SREZIC [...] cpan.org - Fixed in 804.032_501 added