winpdb cannot spawn process to debug. It shows failure message after several seconds. Reproducible: Always Steps to Reproduce: 1. Make a simple test.py script as the following: #!/usr/bin/env python def main(): print 'asdf' a = int('asdf') # raise an exception if __name__ == '__main__': main() 2. Run command "_winpdb test.py" Actual Results: 1. See the winpdb gui shown up, and a message "*** Spawning debuggee..." in the console window (in the right-bottom of the gui, not the terminal). And "State: SPAWNING" in the status bar. 2. After several seconds, a message "*** Debugee failed to start in a timely manner." shown in the console window. And the state message in the status bar changed to "State: DETACHED". Expected Results: It should enter the "ATTACHED" state after launch, and ready to debug.
I emerged winpdb-1.0.6-r1, but it still doesn't work. It still reports "Debugee failed to start in a timely manner". Output of `emerge info` followed: Portage 2.0.51.22-r3 (default-linux/x86/2005.1, gcc-3.4.4, glibc-2.3.5-r2, 2.6.13-suspend2-r4 i686) ================================================================= System uname: 2.6.13-suspend2-r4 i686 Intel(R) Pentium(R) M processor 1.73GHz Gentoo Base System version 1.6.13 ccache version 2.3 [enabled] dev-lang/python: 2.4.2 sys-apps/sandbox: 1.2.12 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.15.92.0.2-r10 sys-devel/libtool: 1.5.20 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=pentium-m -mtune=pentium-m -fforce-addr -momit-leaf-frame-pointer -fomit-frame-pointer -ftracer -pipe -ffast-math" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" CXXFLAGS="-O2 -march=pentium-m -mtune=pentium-m -fforce-addr -momit-leaf-frame-pointer -fomit-frame-pointer -ftracer -pipe -ffast-math -fvisibility-inlines-hidden" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig ccache distlocks sandbox sfperms strict userpriv usersandbox" GENTOO_MIRRORS="http://ftp.gentoo.or.kr/ ftp://mirror.pacific.net.au/linux/Gentoo ftp://gg3.net/pub/linux/gentoo/ http://gentoo.gg3.net/ ftp://gentoo.netnitco.net/pub/mirrors/gentoo/source/" LDFLAGS="-Wl,-O1 -Wl,--enable-new-dtags -Wl,--sort-common -s" LINGUAS="en" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 X aac acpi alsa apache2 audiofile authdaemond avi bash-completion berkdb bitmap-fonts bzip2 cdb cdr cjk crypt cups curl directfb divx4linux emboss encode exif expat fam fbcon fontconfig foomaticdb gd gif glut gpm gstreamer gtk gtk2 hal i8x0 imagemagick imlib immqt-bc irda jikes jpeg lcms libg++ libsamplerate libwww logrotate mad matroska mhash mmx mmx2 mmxext mng mozilla mozsvg mp3 mpeg ncurses nls nptl nsplugin ntl offensive ogg oggvorbis opengl pam pcre pdflib png quicktime readline real sdl sms spell sqlite sse sse2 ssl subversion svg tcpd tetex threads truetype truetype-fonts type1-fonts udev unicode vhosts vorbis win32codecs wxwindows xosd xv xvid xvmc zlib linguas_en userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LC_ALL
If you start it with no arguments do you get the GUI?
(In reply to comment #2) > If you start it with no arguments do you get the GUI? Yes, I can get the GUI, no matter with or without the arguments. But it still failed to start debuggee even if I choose my script from the menu "File -> Launch".
Quote from the official website of winpdb (http://www.digitalpeers.com/pythondebugger/): """ Known Issues with Winpdb 1.0.6 * Launch command fails on some systems. To work around read the section "Attaching to a Running Script" in the Launching and Attaching help page. """ Followed the "Attaching to a Running Script" guide, I launch the debuggee in localhost: $ _winpdb.py -d -r test.py then in another terminal, launch the debugger: $_winpdb.py -olocalhost -a test.py and success. So, I believe this bug is related to the upstream. Let's wait for the next release of winpdb :)
Well, version 1.0.8 doesn't fix this yet. But I really think that this is an upstream problem. Feel free to reopen this bug as soon as there's a new version available which contains a fix for this problem or if there's a patch for it. Sorry...
