Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be available on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 811483 - perl5db.pl failed on Fedora 16 when debug scripts which executes fork() calls
Summary: perl5db.pl failed on Fedora 16 when debug scripts which executes fork() calls
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: perl
Version: 16
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Marcela Mašláňová
QA Contact: Fedora Extras Quality Assurance
URL: http://www.nntp.perl.org/group/perl.p...
Whiteboard:
Depends On:
Blocks: 807951
TreeView+ depends on / blocked
 
Reported: 2012-04-11 08:50 UTC by Xibo Ning
Modified: 2012-04-11 12:39 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-04-11 11:31:35 UTC
Type: Bug


Attachments (Terms of Use)
Simple script to test this bug (328 bytes, application/x-perl)
2012-04-11 08:50 UTC, Xibo Ning
no flags Details

Description Xibo Ning 2012-04-11 08:50:16 UTC
Created attachment 576710 [details]
Simple script to test this bug

Description of problem:
perl5db.pl failed on Fedora 16 when debug scripts which executes fork() calls

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. download test case in attachment
2. perl -d test.pl
3. 
  
Actual results:
don't open a new xterm window

Expected results:
open a new xterm window

Additional info:

Comment 1 Xibo Ning 2012-04-11 08:52:18 UTC
On Fedora 16, although environment variable 'TERM' has value 'xterm', xterm isn't
installed. So, when debug scripts which will execute fork(), perl5db.pl will fail
and quit when it executes the following codes, enters line 1493 ~ 1500, because
function xterm_get_fork_TTY need xterm program:

1487 if (not defined &get_fork_TTY)
1488 {
1489     if ( defined $remoteport ) {
1490
1491         *get_fork_TTY = \&socket_get_fork_TTY;
1492     }
1493     elsif (defined $ENV{TERM}
1494
1495         and $ENV{TERM} eq 'xterm'
1496         and defined $ENV{DISPLAY}
1497       )
1498     {
1499         *get_fork_TTY = \&xterm_get_fork_TTY;
1500     }
1501     elsif ( $^O eq 'os2' ) {
1502         *get_fork_TTY = \&os2_get_fork_TTY;
1503     }
1504     elsif ( $^O eq 'darwin'
1505             and defined $ENV{TERM_PROGRAM}
1506             and $ENV{TERM_PROGRAM}
1507                 eq 'Apple_Terminal'
1508             )
1509     {
1510         *get_fork_TTY = \&macosx_get_fork_TTY;
1511     }
1512 } ## end if (not defined &get_fork_TTY...

Comment 2 Petr Pisar 2012-04-11 11:31:35 UTC
How did you come the idea that TERM environment variable carries terminal emulator executable name? The TERM defines type of terminal. Not a binary. What is `VT100' or `linux'?

The current perl debuger code is just an ugly hack which must resolve upstream. Ask Free Desktop project for support in adding portable way how to spawn new terminal (emulator).

Comment 3 Xibo Ning 2012-04-11 12:39:07 UTC
Good idea. I will.


Note You need to log in before you can comment on or make changes to this bug.