Summary: | net-p2p/bittorrent-3.2.1b-r2 segfaults and other problems | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | FieldySnuts <sgtphou> |
Component: | Current packages | Assignee: | Patrick Kursawe (RETIRED) <phosphan> |
Status: | RESOLVED NEEDINFO | ||
Severity: | normal | CC: | carpaski, liquidx |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | 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. |
Description
FieldySnuts
2003-05-18 14:19:06 UTC
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 |