Skip Menu |

This queue is for tickets about the Tk CPAN distribution.

Report information
The Basics
Id: 5783
Status: resolved
Priority: 0/
Queue: Tk

People
Owner: Nobody in particular
Requestors: slaven [...] rezic.de
Cc:
AdminCc:

Bug Information
Severity: Critical
Broken in: 804.026
Fixed in: (no value)



Subject: fork/CORE::exit does not work anymore
The fork issue is still in the Tk804.026 release. Here a small test case: $ /usr/perl5.8.4d/bin/perl -MTk -e '$mw = tkinit; if (fork == 0) { CORE::exit } MainLoop' X Error of failed request: BadIDChoice (invalid resource ID chosen for this connection) Major opcode of failed request: 1 (X_CreateWindow) Resource id in failed request: 0x3000003 Serial number of failed request: 66 Current serial number in output stream: 28 Xlib: unexpected async reply (sequence 0x46)! A workaround is to use POSIX::_exit instead of CORE::exit, which prevents calling of END and DESTROY in the child process. A better solution would be to apply my patch for this issue. Is your objection regarding to many call-levels between C and perl still valid? Then I may prepare another patch. Regards, Slaven
Subject: [cpan #5783] fork/CORE::exit does not work anymore
To: bug-Tk [...] rt.cpan.org
Date: Wed, 24 Mar 2004 15:18:06 +0000
From: Nick Ing-Simmons <nick.ing-simmons [...] elixent.com>
RT-Send-Cc:
Slaven_Rezic via RT <bug-Tk@rt.cpan.org> writes: Show quoted text
>This message about Tk was sent to you by SREZIC <SREZIC@cpan.org> via >rt.cpan.org > >Full context and any attached attachments can be found at: <URL: >https://rt.cpan.org/Ticket/Display.html?id=5783 > > >The fork issue is still in the Tk804.026 release. Here a small test case: > >$ /usr/perl5.8.4d/bin/perl -MTk -e '$mw = tkinit; if (fork == 0) { CORE::exit >} MainLoop' X Error of failed request: BadIDChoice (invalid resource ID chosen >for this connection) Major opcode of failed request: 1 (X_CreateWindow) >Resource id in failed request: 0x3000003 Serial number of failed request: 66 >Current serial number in output stream: 28 >Xlib: unexpected async reply (sequence 0x46)! > >A workaround is to use POSIX::_exit instead of CORE::exit, which prevents >calling of END and DESTROY in the child process. A better solution would be to >apply my patch for this issue.
Which patch is that? Show quoted text
>Is your objection regarding to many call-levels >between C and perl still valid?
MPTK and piles of legacy code use 'exit' in callbacks so that must be made to work. exit() MUST return up every level of the core tk call stack or it core dumps. Many many tk C functions have stored C stack addresses in "global" variables if the returns are by passed then these are not de-linked and any tk calls in DESROY END etc are a catastrope. Show quoted text
>Then I may prepare another patch. > >Regards, Slaven
From: srezic [...] cpan.org
[nick.ing-simmons@elixent.com - Wed Mar 24 10:18:13 2004]: Show quoted text
> Slaven_Rezic via RT <bug-Tk@rt.cpan.org> writes:
> >This message about Tk was sent to you by SREZIC <SREZIC@cpan.org> via > >rt.cpan.org > > > >Full context and any attached attachments can be found at: <URL: > >https://rt.cpan.org/Ticket/Display.html?id=5783 > > > > >The fork issue is still in the Tk804.026 release. Here a small test
> case:
> > > >$ /usr/perl5.8.4d/bin/perl -MTk -e '$mw = tkinit; if (fork == 0) {
> CORE::exit
> >} MainLoop' X Error of failed request: BadIDChoice (invalid resource
> ID chosen
> >for this connection) Major opcode of failed request: 1
> (X_CreateWindow)
> >Resource id in failed request: 0x3000003 Serial number of failed
> request: 66
> >Current serial number in output stream: 28 > >Xlib: unexpected async reply (sequence 0x46)! > > > >A workaround is to use POSIX::_exit instead of CORE::exit, which
> prevents
> >calling of END and DESTROY in the child process. A better solution
> would be to
> >apply my patch for this issue.
> > Which patch is that? >
> >Is your objection regarding to many call-levels > >between C and perl still valid?
> > MPTK and piles of legacy code use 'exit' in callbacks so that must be > made to work. > > exit() MUST return up every level of the core tk call stack or it core > dumps. > Many many tk C functions have stored C stack addresses in "global" > variables > if the returns are by passed then these are not de-linked and any > tk calls in DESROY END etc are a catastrope. >
> >Then I may prepare another patch. > > > >Regards, Slaven
> >
I think this bug can be closed. I cannot reproduce it anymore with Tk804.027 and perl 5.8.6 on a Linux Redhat 8.0 box. Regards, Slaven