I have various problems such as segfaults and what appear to be python errors with net-p2p/bittorrent-3.2.1b-r2. (unimportant note: bittorrent isn't really a p2p app) Example: $ btdownloadcurses.py --url "http://gentoo.twobit.net/misc/aa-20030513.iso.torrent" Segmentation fault I get this with quotes and without. I have the full .iso in the current directory. $ btdownloadgui.py --url http://gentoo.twobit.net/misc/aa-20030513.iso.torrent Exception in thread Thread-1: Traceback (most recent call last): File "/usr/lib/python2.2/threading.py", line 408, in __bootstrap self.run() File "/usr/lib/python2.2/threading.py", line 396, in run apply(self.__target, self.__args, self.__kwargs) File "/usr/bin/btdownloadgui.py", line 219, in next download(params, d.chooseFile, d.updateStatus, d.finished, d.error, doneflag, 100, d.newpath) File "/usr/lib/python2.2/site-packages/BitTorrent/download.py", line 106, in dow nload h = urlopen(config['url']) File "/usr/lib/python2.2/urllib2.py", line 138, in urlopen return _opener.open(url, data) File "/usr/lib/python2.2/urllib2.py", line 322, in open '_open', req) File "/usr/lib/python2.2/urllib2.py", line 301, in _call_chain result = func(*args) File "/usr/lib/python2.2/urllib2.py", line 450, in <lambda> lambda r, proxy=url, type=type, meth=self.proxy_open: \ File "/usr/lib/python2.2/urllib2.py", line 457, in proxy_open if '@' in host: TypeError: iterable argument required The GUI comes up, but nothing whatsoever happens. I'm not familar at all with bittorrent, and through no fault of anyone related to gentoo, the documents are very poor or nonexistant. I updated python to the latest, then rebuilt bittorrent, still the same results. Anyone else seeing these problems? Note below my CFLAGS are quite strict. However I tried all this with "-march=athlon-mp -O3 -pipe" and still get the exact same results. Portage 2.0.47-r10 (default-1.0, gcc-3.2.3, glibc-2.2.5-r2,2.2.5-r8) ================================================================= System uname: 2.4.20 i686 AuthenticAMD GENTOO_MIRRORS="http://gentoo.linux.no/ ftp://ftp.tu-clausthal.de/pub/linux/gentoo / http://ftp.gentoo.or.kr/ http://gentoo.gnukorea.org/ ftp://ftp.dale.ro/pub/mirro rs/ftp.ibiblio.org/pub/Linux/distributions/gentoo/ ftp://ftp.snt.utwente.nl/pub/os /linux/gentoo/ ftp://ftp.rez-gif.supelec.fr/pub/Linux/distrib/gentoo/ " CONFIG_PROTECT="/etc /var/qmail/control /usr/share/config /usr/kde/2/share/config /usr/kde/3/share/config /usr/X11R6/lib/X11/xkb:/usr/kde/3.1/share/config:/usr/shar e/config" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" PORTDIR="/home/portage" DISTDIR="/home/portage/distfiles" PKGDIR="/home/portage/packages" PORTAGE_TMPDIR="/home/portage/tmp" PORTDIR_OVERLAY="" USE="x86 oss apm avi crypt cups jpeg libg++ mikmod mpeg ncurses quicktime spell xm l2 xv aalib berkdb bonobo directfb esd gdbm ggi gif gnome-libs gtkhtml guile imlib java ldap libwww motif mozilla nls opengl pam png python qt readline scanner sdl slang ssl svga tcltk tcpd tetex tiff X gtk gtk2 gpm gnome -alsa -arts 3dnow cdr en code kde mmx oggvorbis pdflib perl sse truetype xmms ipv6" COMPILER="" CHOST="i686-pc-linux-gnu" CFLAGS="-march=athlon-mp -O3 -pipe -fexpensive-optimizations -fomit-frame-pointer -D__SMP__ -mmmx -msse -m3dnow -mfpmath=sse,387" CXXFLAGS="-march=athlon-mp -O3 -pipe -fexpensive-optimizations -fomit-frame-pointe r -D__SMP__ -mmmx -msse -m3dnow -mfpmath=sse,387" ACCEPT_KEYWORDS="x86 ~x86" MAKEOPTS="-j3" AUTOCLEAN="yes" SYNC="rsync://rsync.gentoo.org/gentoo-portage" FEATURES="sandbox ccache" Thanks!
what if you compile python with -march=athlon-xp ? bittorrent its just a python script really, so re-emerging doesn't really make a diff.
I've just made an error. I did an emerge -C python, and of course now I can't emerge python because I don't have python. I do have the same python package sitting around (created with emerge -b), how do I install it manually?
Right. Got it back. Okay I recompiled python with -march=athlon-xp , however I am still seeing the same problems.
I am using -march=athlon-xp -O3 -pipe and have no problems at all. Looks like bittorrent is just the point where broken python builds show up more likely than with other programs. Joe, could you please try python with extremely harmless flags (like -mcpu=686 -Os -pipe)?
I tried CFLAGS="-march=i686 -O1 -pipe" and got the same results. I also changed MAKEOPTS to -j1 instead of -j3, same problems.
Just to make sure about what we are talking here - which python version are you using?
I am using dev-lang/python-2.2.2-r1 .
Works fine for me on two different machines... A few other wild guesses: What says "bttest.py"? What are your proxy settings? What happens when you remove the .iso file?
bttest.py: Many pages of trying/passed, ending in "everything passed". I do have proxy settings: $ echo $http_proxy 127.0.0.1:3128 echo $ftp_proxy 127.0.0.1:3128 echo $rsync_proxy 127.0.0.1:3128 As for removing the ISO, what I'll try here is starting this in a directory without the iso, like in the topic of #gentoo : btdownloadcurses.py --url http://gentoo.twobit.net/misc/aa-20030513.iso.torrent $ btdownloadcurses.py --url http://gentoo.twobit.net/misc/aa-20030513.iso.torrent Segmentation fault Attaching an strace log of this same command.
Created attachment 12244 [details] Output of strace btdownloadcurses.py --url http://gentoo.twobit.net/misc/aa-20030513.iso.torrent 2> strace-1.txt WITHOUT the iso in the current directory.
The next steps in my strace after the point where yours segfaulted are: rt_sigaction(SIGTSTP, {SIG_IGN}, {0x4442d290, [], SA_RESTART|0x4000000}, 8) = 0 write(1, "\33)0\0337\33[?47h\33[1;24r\33[m\33[4l\33[H\33[2J"..., 565) = 565 rt_sigaction(SIGTSTP, {0x4442d290, [], SA_RESTART|0x4000000}, NULL, 8) = 0 rt_sigaction(SIGWINCH, NULL, {0x4442d290, [], 0x4000000}, 8) = 0 rt_sigaction(SIGWINCH, {0x4442d290, [], 0x4000000}, NULL, 8) = 0 rt_sigaction(SIGWINCH, NULL, {0x4442d290, [], 0x4000000}, 8) = 0 rt_sigaction(SIGWINCH, {0x4442d290, [], 0x4000000}, NULL, 8) = 0 gettimeofday({1053582048, 466811}, NULL) = 0 getpid() = 16109 open("/etc/resolv.conf", O_RDONLY) = 3 .... So nothing really suspicious here. Which glibc version are you using, and did you compile it with the aggressive flags you mentioned? Can you perhaps generate a core file and do a traceback?
glibc 2.2.5-r8 , and I did not use the agressive flags. "-march=athlon-xp -O3 -pipe" if i remember correctly. As far as cores and backtraces, that just crossed over my "hey I know how to do that line", but with a little assistance I would be happy to provide the information.
Ok.... one problem could be that your python executable is most likely stripped. So the only thing we can try to find out without having to rebuild python with symbols or debugging information is: Did the program fail within itself or in a libc function? Try the following: ulimit -c unlimited run_the_crashing_program gdb /path/to/python core Then you should see something similar to: Core was generated by `./coredumper'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libc.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/ld-linux.so.2 #0 0x441b7627 in strcpy () from /lib/libc.so.6 (gdb) Then type "up" until it complains about not being able to go further up. I am not yet sure what I will do with the information I get from this, but perhaps it will give an idea where the problem is located.
Still waiting...
bug state was reset
