Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MSWin32/perl -de1 hang up #12244

Closed
p5pRT opened this issue Jul 3, 2012 · 7 comments
Closed

MSWin32/perl -de1 hang up #12244

p5pRT opened this issue Jul 3, 2012 · 7 comments

Comments

@p5pRT
Copy link
Collaborator

@p5pRT p5pRT commented Jul 3, 2012

Migrated from rt.perl.org#113960 (status was 'resolved')

Searchable as RT113960$

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jul 3, 2012

From @xlat

Created by @xlat

I was running "perl -de1" to enter into the debugger and was
unable to got it's prompt and cpu/memory usage were growing up.
I finnaly found that a file c​:\dev\tty was existing on my system
(must be a mistake outside of perl).
If I delete this file the debugger ran as expected.

It is because in perl5db.pl at line 1399 a test for '-e /dev/tty'
doesn't care that '$^O eq MSWin32' and use '/dev/tty' it rather
than 'con' for the $console.

Thanks.

Perl Info

Flags:
    category=core
    severity=low

Site configuration information for perl 5.16.0:

Configured by Nicolas at Fri Jun 22 15:32:32 2012.

Summary of my perl5 (revision 5 version 16 subversion 0) configuration:

  Platform:
    osname=MSWin32, osvers=5.1, archname=MSWin32-x86-multi-thread
    uname=''
    config_args='undef'
    hint=recommended, useposix=true, d_sigaction=undef
    useithreads=define, usemultiplicity=define
    useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
    use64bitint=undef, use64bitall=undef, uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='cl', ccflags ='-nologo -GF -W3 -MD -Zi -DNDEBUG -O1 -DWIN32
-D_CONSOLE -DNO_STRICT -D_CRT_SECURE_NO_DEPRECATE
-D_CRT_NONSTDC_NO_DEPRECATE  -DPERL_TEXTMODE_SCRIPTS
-DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO',
    optimize='-MD -Zi -DNDEBUG -O1',
    cppflags='-DWIN32'
    ccversion='14.00.50727.762', gccversion='', gccosandvers=''
    intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
    d_longlong=undef, longlongsize=8, d_longdbl=define, longdblsize=8
    ivtype='long', ivsize=4, nvtype='double', nvsize=8,
Off_t='__int64', lseeksize=8
    alignbytes=8, prototype=define
  Linker and Libraries:
    ld='link', ldflags ='-nologo -nodefaultlib -debug -opt:ref,icf
-libpath:"c:\perl\5.16.0\lib\CORE"  -machine:x86
"/manifestdependency:type='Win32'
name='Microsoft.Windows.Common-Controls' version='6.0.0.0'
processorArchitecture='*' publicKeyToken='6595b64144ccf1df'
language='*'"'
    libpth=\lib
    libs=oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib
comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib
netapi32.lib uuid.lib ws2_32.lib mpr.lib winmm.lib  version.lib
odbc32.lib odbccp32.lib comctl32.lib msvcrt.lib
    perllibs=oldnames.lib kernel32.lib user32.lib gdi32.lib
winspool.lib  comdlg32.lib advapi32.lib shell32.lib ole32.lib
oleaut32.lib  netapi32.lib uuid.lib ws2_32.lib mpr.lib winmm.lib
version.lib odbc32.lib odbccp32.lib comctl32.lib msvcrt.lib
    libc=msvcrt.lib, so=dll, useshrplib=true, libperl=perl516.lib
    gnulibc_version=''
  Dynamic Linking:
    dlsrc=dl_win32.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' '
    cccdlflags=' ', lddlflags='-dll -nologo -nodefaultlib -debug
-opt:ref,icf  -libpath:"c:\perl\5.16.0\lib\CORE"  -machine:x86
"/manifestdependency:type='Win32'
name='Microsoft.Windows.Common-Controls' version='6.0.0.0'
processorArchitecture='*' publicKeyToken='6595b64144ccf1df'
language='*'"'

Locally applied patches:



@INC for perl 5.16.0:
    C:/Perl/site/5.16.0/lib
    C:/Perl/5.16.0/lib
    .


Environment for perl 5.16.0:
    HOME (unset)
    LANG (unset)
    LANGUAGE (unset)
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=C:\Program Files\Microsoft Visual Studio
9.0\Common7\IDE;C:\Program Files\Microsoft Visual Studio
9.0\VC\BIN;C:\Program Files\Microsoft Visual Studio
9.0\Common7\Tools;C:\WINDOWS\Microsoft.NET\Framework\v3.5;C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727;C:\Program
Files\Microsoft Visual Studio 9.0\VC\VCPackages;C:\Program
Files\Microsoft
SDKs\Windows\v6.0A\bin;C:\WINDOWS;C:\WINDOWS\SYSTEM32;C:\WINDOWS\System32\Wbem;C:\Program
Files\wscite;C:\Program Files\IDM Computer
Solutions\UltraEdit\;C:\Program Files\Subversion;C:\Program
Files\TortoiseSVN\bin;C:\Python25\;C:\Perl\bin;C:\Perl\site\bin;C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727;C:\PROGRA~1\ATT\Graphviz\bin;C:\Program
Files\Sybase\Shared\PowerBuilder;C:\Program Files\Sybase\SQL Anywhere
9\win32;C:\Program
Files\Sybase\Shared\ASA9\win32;C:\gnuwin32\bin;c:\ruby\bin;C:\Program
Files\CollabNet Subversion Client;C:\Program Files\SQL Anywhere
11\bin32;C:\WINDOWS\Microsoft.NET\Framework\v3.5;C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727;C:\Program
Files\TortoiseGit\bin;C:\Program Files\Sybase\Adaptive Server Anywhere
6.0\win32;C:\Program Files\Sybase\SQL Anywhere 7\win32;C:\Program
Files\Sybase\Shared\Web Targets;C:\Program Files\Cppcheck\;C:\Program
Files\Sybase\SQL Anywhere 8\win32;C:\Program
Files\Sybase\Shared\win32;C:\Program Files\Sybase\Shared\Sybase
Central 4.1;C:\Program Files\Sybase\PowerDynamo\win32;C:\Program
Files\Sybase\Shared\DataDirect;C:\Program Files\Sybase\InfoMaker
9.0\Tutorial;C:\Program Files\SQL Anywhere 12\bin32;C:\Program
Files\Sybase\PowerBuilder
12.5;C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319;;C:\Lua\5.1;C:\Lua\5.1\clibs;C:\WINDOWS;C:\WINDOWS\SYSTEM32;C:\WINDOWS\System32\Wbem;C:\Program
Files\wscite;C:\Program Files\IDM Computer
Solutions\UltraEdit-32\;C:\Program Files\Subversion;C:\Program
Files\TortoiseSVN\bin;C:\Python25\;C:\Perl\bin;C:\Perl\site\bin;C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727;C:\PROGRA~1\ATT\Graphviz\bin;C:\Program
Files\Sybase\Shared\PowerBuilder;C:\Program Files\Sybase\SQL Anywhere
9\win32;C:\Program
Files\Sybase\Shared\ASA9\win32;C:\EmbeddingPerl\perl\bin;C:\EmbeddingPerl\perl\shared;C:\Program
Files\Common Files\ConceptWare\ASA\v9Auth
    PERL_BADLANG (unset)
    SHELL (unset)

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Dec 31, 2016

From @jkeenan

On Tue, 03 Jul 2012 09​:12​:15 GMT, xlat@​cpan.org wrote​:

This is a bug report for perl from xlat@​cpan.org,
generated with the help of perlbug 1.39 running under perl 5.16.0.

-----------------------------------------------------------------
[Please describe your issue here]
I was running "perl -de1" to enter into the debugger and was
unable to got it's prompt and cpu/memory usage were growing up.
I finnaly found that a file c​:\dev\tty was existing on my system
(must be a mistake outside of perl).
If I delete this file the debugger ran as expected.

It is because in perl5db.pl at line 1399 a test for '-e /dev/tty'
doesn't care that '$^O eq MSWin32' and use '/dev/tty' it rather
than 'con' for the $console.

Thanks.

Let me see if I can correctly re-state this problem.

You invoked the perl debugger, whose source code is found in lib/perl5db.pl. As of now (commit 8df0224), starting at line 1530 of that file, there is an if-elsif-else block where we try to determine what the console should be on various systems. The first 'elsif' is​:

#####
1540 elsif ( -e "/dev/tty" ) {
1541 $console = "/dev/tty";
1542 }
#####

... which was triggered on your system because there accidentally existed a file c​:\dev\tty thereon. Consequently, we didn't reach the *second* 'elsif' block​:

#####
1548 elsif ( $^O eq 'dos' or -e "con" or $^O eq 'MSWin32' ) {
1549 $console = "con";
1550 }
#####

Is that a correct analysis?

Thank you very much.
--
James E Keenan (jkeenan@​cpan.org)

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Dec 31, 2016

The RT System itself - Status changed from 'new' to 'open'

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jan 2, 2017

From @xlat

Hi, yes that is correct.
Just a small precision​: on windows platforms /dev/tty is relative to the
current drive which in my case was my system drive c​: but it is not
necessary always the case.

Thank you.

Le 31 déc. 2016 02​:43, "James E Keenan via RT" <perlbug-followup@​perl.org>
a écrit :

On Tue, 03 Jul 2012 09​:12​:15 GMT, xlat@​cpan.org wrote​:

This is a bug report for perl from xlat@​cpan.org,
generated with the help of perlbug 1.39 running under perl 5.16.0.

-----------------------------------------------------------------
[Please describe your issue here]
I was running "perl -de1" to enter into the debugger and was
unable to got it's prompt and cpu/memory usage were growing up.
I finnaly found that a file c​:\dev\tty was existing on my system
(must be a mistake outside of perl).
If I delete this file the debugger ran as expected.

It is because in perl5db.pl at line 1399 a test for '-e /dev/tty'
doesn't care that '$^O eq MSWin32' and use '/dev/tty' it rather
than 'con' for the $console.

Thanks.

Let me see if I can correctly re-state this problem.

You invoked the perl debugger, whose source code is found in lib/perl5db.pl.
As of now (commit 8df0224), starting at
line 1530 of that file, there is an if-elsif-else block where we try to
determine what the console should be on various systems. The first 'elsif'
is​:

#####
1540 elsif ( -e "/dev/tty" ) {
1541 $console = "/dev/tty";
1542 }
#####

... which was triggered on your system because there accidentally existed a
file c​:\dev\tty thereon. Consequently, we didn't reach the *second*
'elsif' block​:

#####
1548 elsif ( $^O eq 'dos' or -e "con" or $^O eq 'MSWin32' ) {
1549 $console = "con";
1550 }
#####

Is that a correct analysis?

Thank you very much.
--
James E Keenan (jkeenan@​cpan.org)

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jan 2, 2017

From @jkeenan

On Mon, 02 Jan 2017 21​:25​:37 GMT, xlat@​cpan.org wrote​:

Le 31 déc. 2016 02​:43, "James E Keenan via RT" <perlbug-followup@​perl.org>
a écrit :

On Tue, 03 Jul 2012 09​:12​:15 GMT, xlat@​cpan.org wrote​:

This is a bug report for perl from xlat@​cpan.org,
generated with the help of perlbug 1.39 running under perl 5.16.0.

-----------------------------------------------------------------
[Please describe your issue here]
I was running "perl -de1" to enter into the debugger and was
unable to got it's prompt and cpu/memory usage were growing up.
I finnaly found that a file c​:\dev\tty was existing on my system
(must be a mistake outside of perl).
If I delete this file the debugger ran as expected.

It is because in perl5db.pl at line 1399 a test for '-e /dev/tty'
doesn't care that '$^O eq MSWin32' and use '/dev/tty' it rather
than 'con' for the $console.

Thanks.

Let me see if I can correctly re-state this problem.

You invoked the perl debugger, whose source code is found in lib/perl5db.pl.
As of now (commit 8df0224), starting at
line 1530 of that file, there is an if-elsif-else block where we try to
determine what the console should be on various systems. The first 'elsif'
is​:

#####
1540 elsif ( -e "/dev/tty" ) {
1541 $console = "/dev/tty";
1542 }
#####

... which was triggered on your system because there accidentally existed a
file c​:\dev\tty thereon. Consequently, we didn't reach the *second*
'elsif' block​:

#####
1548 elsif ( $^O eq 'dos' or -e "con" or $^O eq 'MSWin32' ) {
1549 $console = "con";
1550 }
#####

Is that a correct analysis?
Hi, yes that is correct.
Just a small precision​: on windows platforms /dev/tty is relative to the
current drive which in my case was my system drive c​: but it is not
necessary always the case.

Thank you.

P5P​: Would it be sufficient to move the test for '/dev/tty' to be the final 'elsif' branch? Or is there some other way to identify a Unix-like OS?

Thank you very much.

--
James E Keenan (jkeenan@​cpan.org)

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jan 4, 2017

From @arc

James E Keenan via RT <perlbug-followup@​perl.org> wrote​:

P5P​: Would it be sufficient to move the test for '/dev/tty' to be the final 'elsif' branch? Or is there some other way to identify a Unix-like OS?

Yes, that sounds like a sensible way to proceed.

Thanks, applied (with authorship assigned to you) as
f1cba94.

--
Aaron Crane ** http​://aaroncrane.co.uk/

@p5pRT p5pRT closed this Jan 4, 2017
@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jan 4, 2017

@arc - Status changed from 'open' to 'resolved'

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
1 participant
You can’t perform that action at this time.