segfaults in both 0.8.6/0.11.6 and 0.8.5/0.11.5

[anonymous]

hi, i'm seeing repeated segfaults lately with rtorrent. i upgraded to the latest as a precaution. here is the initial backtrace:

[Throttle  30/off KB] [Rate  30.1/194.9 KB] [Port: 6890]                                                                                                                      [U 7/16] [D 38/0] [H 0/32] [S 1/54/768] [F 104/128]
Program received signal SIGABRT, Aborted.
0x3050debc in kill () from /lib/libc.so.0
(gdb) backtrace
#0  0x3050debc in kill () from /lib/libc.so.0
#1  0x30552d20 in abort () from /lib/libc.so.0
#2  0x30552310 in ?? () from /lib/libc.so.0
#3  0x30551570 in malloc () from /lib/libc.so.0
#4  0x304773ec in operator new () from /usr/lib/libstdc++.so.6
#5  0x30192a0c in std::vector<torrent::Block, std::allocator<torrent::Block> >::_M_fill_insert () from /usr/lib/libtorrent.so.11
#6  0x301923d4 in torrent::BlockList::BlockList () from /usr/lib/libtorrent.so.11
#7  0x3019b4d4 in ?? () from /usr/lib/libtorrent.so.11
#8  0x301c9768 in ?? () from /usr/lib/libtorrent.so.11
#9  0x301c99c8 in ?? () from /usr/lib/libtorrent.so.11
#10 0x301c9bbc in ?? () from /usr/lib/libtorrent.so.11
#11 0x301f2f48 in ?? () from /usr/lib/libtorrent.so.11
#12 0x301ea2d0 in ?? () from /usr/lib/libtorrent.so.11
#13 0x301ef478 in ?? () from /usr/lib/libtorrent.so.11
#14 0x301f061c in ?? () from /usr/lib/libtorrent.so.11
#15 0x301850d8 in std::for_each<__gnu_cxx::__normal_iterator<torrent::Event**, std::vector<torrent::Event*, std::allocator<torrent::Event*> > >, torrent::poll_check_t<std::mem_fun_t<void, torrent::Event> > > ()
   from /usr/lib/libtorrent.so.11
#16 0x30183d40 in torrent::PollSelect::perform () from /usr/lib/libtorrent.so.11
#17 0x1007c0b8 in core::PollManagerSelect::poll (this=0x101212a8, timeout=Cannot access memory at address 0x0
) at poll_manager_select.cc:120
#18 0x1003afc4 in main (argc=<value optimized out>, argv=<value optimized out>) at main.cc:321
(gdb)

let me know if you need any memory locations examined etc.

thanks, -matt

[anonymous]

also, some additional info.

libc is uclibc 0.9.30.1 w/soft fpu.

kernel is 2.6.24.7 powerpc, w/debian patches.

-matt

[anonymous]

finally, libtorrent was compiled with '--enable-aligned'.

-mat

[anonymous]

your libtorrent version looks old to me.

[anonymous]

sorry, libtorrent 0.12.5/0.12.6. same torrent seems to get it every time.

-matt

[anonymous]

Run it in gdb and post the "bt full". Since it's crashing in a malloc call, you're either running out of memory or something else funky is going on, if uclibc has malloc debugging facilities it'd be worth enabling those. In particular the malloc argument would be interesting.

[anonymous]

will do, thanks for the tip. i've got a desktop machine with faster specs (x86/glibc, 4gb of ram, 0.8.2,/0.12.2) than this embedded system (powerpc/uclibc, 256mb of ram), and it doesnt seem to have the same issue.

shortly after this issue arose, i realized my libcurl install was broken due to an upgrade to openssl9.8m. i've since recompiled curl 7.20, libsigc++ 2.2.3, and rtorrent 0.8.6/0.12.6. i haven't hit the issue since, but i havent tried the problem torrents yet.

i'll test overnight tonight.

-matt

[anonymous]

regarding uclibc malloc debugging:

from  http://www.uclibc.org/downloads/Glibc_vs_uClibc_Differences.txt: 4.1) glibc's malloc() implementation has behavior that is tunable via the MALLOC_CHECK_ environment variable. This is primarily used to provide extra malloc debugging features. These extended malloc debugging features are not available within uClibc. There are many good malloc debugging libraries available for Linux (dmalloc, electric fence, valgrind, etc) that work much better than the glibc extended malloc debugging. So our omitting this functionality from uClibc is not a great loss.

-matt

[anonymous]

it still segfaults, even with updated/rebuilt support libraries:

[Throttle  30/off KB] [Rate   0.6/ 54.9 KB] [Port: 6890]                                                                                                                      [U 3/16] [D 20/0] [H 0/32] [S 0/28/768] [F 104/128]
Program received signal SIGABRT, Aborted.
0x30514ebc in kill () from /lib/libc.so.0
(gdb) bt full
#0  0x30514ebc in kill () from /lib/libc.so.0
No symbol table info available.
#1  0x30559d20 in abort () from /lib/libc.so.0
No symbol table info available.
#2  0x30559310 in ?? () from /lib/libc.so.0
No symbol table info available.
#3  0x30558570 in malloc () from /lib/libc.so.0
No symbol table info available.
#4  0x3047e3ec in operator new () from /usr/lib/libstdc++.so.6
No symbol table info available.
#5  0x3018cf10 in torrent::Rate::insert () from /usr/lib/libtorrent.so.11
No symbol table info available.
#6  0x301f0390 in ?? () from /usr/lib/libtorrent.so.11
No symbol table info available.
#7  0x301f7068 in ?? () from /usr/lib/libtorrent.so.11
No symbol table info available.
#8  0x3018c0d8 in std::for_each<__gnu_cxx::__normal_iterator<torrent::Event**, std::vector<torrent::Event*, std::allocator<torrent::Event*> > >, torrent::poll_check_t<std::mem_fun_t<void, torrent::Event> > > ()
   from /usr/lib/libtorrent.so.11
No symbol table info available.
#9  0x3018acf4 in torrent::PollSelect::perform () from /usr/lib/libtorrent.so.11
No symbol table info available.
#10 0x1007bf90 in core::PollManagerSelect::poll (this=0x101202a8, timeout=Cannot access memory at address 0x0
) at poll_manager_select.cc:120
        maxFd = 170
        t = {tv_sec = 0, tv_usec = 730000}
#11 0x1003ae9c in main (argc=<value optimized out>, argv=<value optimized out>) at main.cc:321
        firstArg = <value optimized out>

(gdb) frame 3
#3  0x30558570 in malloc () from /lib/libc.so.0

(gdb) info frame
Stack level 3, frame at 0x7f8ec890:
 pc = 0x30558570 in malloc; saved pc 0x3047e3ec
 called by frame at 0x7f8ec8b0, caller of frame at 0x7f8ec850
 Arglist at 0x7f8ec850, args: 
 Locals at 0x7f8ec850, Previous frame's sp is 0x7f8ec890
 Saved registers:
  r22 at 0x7f8ec868, r23 at 0x7f8ec86c, r24 at 0x7f8ec870, r25 at 0x7f8ec874, r26 at 0x7f8ec878, r27 at 0x7f8ec87c, r28 at 0x7f8ec880, r29 at 0x7f8ec884, r30 at 0x7f8ec888, r31 at 0x7f8ec88c, pc at 0x7f8ec894,
  lr at 0x7f8ec894

sorry if its not very useful. i can try compiling with -g if that would help.

-matt

[anonymous]

i've got another bt that is almost identical to the one above.

supposedly one other difference between glibc and uclibc is that malloc(0) returns a valid pointer in glibc, and returns NULL under uclibc. not sure how this relates, just throwin' it out there.

thanks, -matt

[sav]

Perhaps you can help the next patch jdrexler ( http://ttdpatch.net/~jdrexler/rt/experimental/fix-no-posix_memalign.diff)

[anonymous]

Well the crash is in malloc, called from operator new in a libstdc++ routine. That means you either ran out of memory, or libstdc++ has a bug or at least changed semantics from what rtorrent expects.

Since it's a simple std::deque::push_front, it can practically only be a bug or you running out of memory. With 256 MB RAM, running out is not too unlikely, especially if mmapped files count towards the limit (in other words, does it support swap memory?). Check the various process memory limit in your shell (bash: ulimit -a), and make sure rtorrent's max_memory_usage is sufficiently low.

[anonymous]

hey, thanks for the patch. i will try that tonight. i did not have this problem before i upgraded to 256mb. i was using 128mb before. i have approximately 250MB of swap configured on the system. it has been seldom used since the upgrade. i have not seen any segfaults or swapping on other system apps (samba, openssh). swap doesn't appear to be used at all on rtorrent. i have seen no oom-killer or swapping. rtorrent happily handled around 900KB/s from other torrents; this crash happens even with low (50KB/s) speeds, but again, only with these two suspect torrents.

thanks for your time and advice, -matt

[anonymous]

hi sav, i tried to use the patches with 0.12.6/0.8.6 with no luck. nowhere in that version is there a mention of allocators.h, and grepping the whole source for context lines doesnt seem to match up either. is this intended for 0.12.5/0.8.5, or svn, or...?

thanks, -matt

[anonymous]

hi sav, i see that it applies against svn. thanks. will give svn trunk a try.

-matt

[anonymous]

now i'm hitting http://libtorrent.rakshasa.no/ticket/2127. openembedded doesn't seem to have a cppunit recipe. i could add it, i suppose. is libcppunit a certainty for the next major stable release?

-matt

[anonymous]

there is a cppunit recipe actually. i'm seeing an error that i believe is related to the memalign patch:

| Making all in tracker
| make[3]: Entering directory `/home/matt/devel/tmp/work/ppc405-angstrom-linux-uclibc/libtorrent-0.8.6+svnr1148-r1/libtorrent/src/tracker'
| /bin/bash ../../powerpc-angstrom-linux-uclibc-libtool --tag=CXX   --mode=compile ccache powerpc-angstrom-linux-uclibc-g++ -mcpu=405 -DHAVE_CONFIG_H -I. -I../.. -I. -I./.. -I../..  -isystem/home/matt/devel/tmp/staging/ppc405-angstrom-linux-uclibc/usr/include  -isystem/home/matt/devel/tmp/staging/ppc405-angstrom-linux-uclibc/usr/include -fexpensive-optimizations -fomit-frame-pointer -frename-registers -O2 -ggdb3 -fpermissive -fvisibility-inlines-hidden -g -DDEBUG -fvisibility=hidden   -I/home/matt/devel/tmp/staging/ppc405-angstrom-linux-uclibc/usr/include/sigc++-2.0 -I/home/matt/devel/tmp/staging/ppc405-angstrom-linux-uclibc/usr/lib/sigc++-2.0/include   -MT tracker_dht.lo -MD -MP -MF .deps/tracker_dht.Tpo -c -o tracker_dht.lo tracker_dht.cc
| /bin/bash ../../powerpc-angstrom-linux-uclibc-libtool --tag=CXX   --mode=compile ccache powerpc-angstrom-linux-uclibc-g++ -mcpu=405 -DHAVE_CONFIG_H -I. -I../.. -I. -I./.. -I../..  -isystem/home/matt/devel/tmp/staging/ppc405-angstrom-linux-uclibc/usr/include  -isystem/home/matt/devel/tmp/staging/ppc405-angstrom-linux-uclibc/usr/include -fexpensive-optimizations -fomit-frame-pointer -frename-registers -O2 -ggdb3 -fpermissive -fvisibility-inlines-hidden -g -DDEBUG -fvisibility=hidden   -I/home/matt/devel/tmp/staging/ppc405-angstrom-linux-uclibc/usr/include/sigc++-2.0 -I/home/matt/devel/tmp/staging/ppc405-angstrom-linux-uclibc/usr/lib/sigc++-2.0/include   -MT tracker_http.lo -MD -MP -MF .deps/tracker_http.Tpo -c -o tracker_http.lo tracker_http.cc
| powerpc-angstrom-linux-uclibc-libtool: compile:  ccache powerpc-angstrom-linux-uclibc-g++ -mcpu=405 -DHAVE_CONFIG_H -I. -I../.. -I. -I./.. -I../.. -isystem/home/matt/devel/tmp/staging/ppc405-angstrom-linux-uclibc/usr/include -isystem/home/matt/devel/tmp/staging/ppc405-angstrom-linux-uclibc/usr/include -fexpensive-optimizations -fomit-frame-pointer -frename-registers -O2 -ggdb3 -fpermissive -fvisibility-inlines-hidden -g -DDEBUG -fvisibility=hidden -I/home/matt/devel/tmp/staging/ppc405-angstrom-linux-uclibc/usr/include/sigc++-2.0 -I/home/matt/devel/tmp/staging/ppc405-angstrom-linux-uclibc/usr/lib/sigc++-2.0/include -MT tracker_dht.lo -MD -MP -MF .deps/tracker_dht.Tpo -c tracker_dht.cc  -fPIC -DPIC -o .libs/tracker_dht.o
| powerpc-angstrom-linux-uclibc-libtool: compile:  ccache powerpc-angstrom-linux-uclibc-g++ -mcpu=405 -DHAVE_CONFIG_H -I. -I../.. -I. -I./.. -I../.. -isystem/home/matt/devel/tmp/staging/ppc405-angstrom-linux-uclibc/usr/include -isystem/home/matt/devel/tmp/staging/ppc405-angstrom-linux-uclibc/usr/include -fexpensive-optimizations -fomit-frame-pointer -frename-registers -O2 -ggdb3 -fpermissive -fvisibility-inlines-hidden -g -DDEBUG -fvisibility=hidden -I/home/matt/devel/tmp/staging/ppc405-angstrom-linux-uclibc/usr/include/sigc++-2.0 -I/home/matt/devel/tmp/staging/ppc405-angstrom-linux-uclibc/usr/lib/sigc++-2.0/include -MT tracker_http.lo -MD -MP -MF .deps/tracker_http.Tpo -c tracker_http.cc  -fPIC -DPIC -o .libs/tracker_http.o
| In file included from ../../rak/priority_queue_default.h:42,
|                  from ./../dht/dht_router.h:41,
|                  from tracker_dht.cc:43:
| ../../rak/allocators.h: In static member function 'static T* rak::cacheline_allocator<T>::alloc_size(size_t)':
| ../../rak/allocators.h:109: error: 'uintptr_t' was not declared in this scope
| make[3]: *** [tracker_dht.lo] Error 1
| make[3]: *** Waiting for unfinished jobs....

-matt

[anonymous]

#include <stdint.h>

in allocators.h seemed to fix the build.

-matt

[anonymous]

matt@deep-thought:~/devel/tmp/work/ppc405-angstrom-linux-uclibc/libtorrent-0.8.6+svnr1148-r1/libtorrent$ cat config.h|grep MEM
#define HAVE_MEMORY_H 1
/* #undef HAVE_POSIX_MEMALIGN */

-matt

[anonymous]

egh, got my versions wrong again. fixed.

-matt

[anonymous]

also needed to specify -lpthreads when building rtorrent from svn.

got 'em installed and testing.

thanks, -matt

[anonymous]

haha oh boy. now i had three rtorrents crash instead of one. it was a nice idea, though.

-matt

[anonymous]

and the fun thing about my installed gdb:

dlopen failed on 'libthread_db.so.1' - File not found
GDB will not be able to debug pthreads.

-matt

[sav]

Replying to anonymous:

hi sav, i tried to use the patches with 0.12.6/0.8.6 with no luck. nowhere in that version is there a mention of allocators.h, and grepping the whole source for context lines doesnt seem to match up either. is this intended for 0.12.5/0.8.5, or svn, or...? thanks, -matt

For what embedded system you are building rtorrent?

I'm using openwrt (kernel 2.6 for brcm47) on the device ASUS WL500GP V1

libtorrent/rtorrent 0.12.6/0.8.6 to svn r1130 version works without problems (See  https://dev.openwrt.org/ticket/6685).

I also tried all subsequent releases including r1148, to r1143 - OK, since r1144 to r1148 crached as you.

[anonymous]

the system is a 'dht-walnut' ppc405 embedded board, using uclibc.

kernel: 2.6.24.7, w/debian etchnhalf patchset uclibc: 9.30.1, softfpu gcc: 4.4.1, -mcpu=405 binutils: 2.19.51.0.3 libstdc++: 4.4.1 openssl: 0.9.8m curl: 7.20.0 libsigc++: 2.2.3

-matt

[anonymous]

also, rtorrent has handled 100's of gigabytes of traffic without crashing. it is only two (probably one) specific torrent that causes the crash.

-matt

[anonymous]

svn r1148 w/memalign patch also crashed on the same torrents.

-matt

[sav]

Replying to anonymous:

svn r1148 w/memalign patch also crashed on the same torrents. -matt

Example same torrents, some what? You can link to - try on his and see if I have to fall ;-)

[rakshasa]

Replying to sav:

Example same torrents, some what? You can link to - try on his and see if I have to fall ;-)

That's one of the worst machine-translated sentence I've seen in a long time. Still, if you can post the torrent would be nice.

[anonymous]

problematic torrents causing segfault

[anonymous]

tar.gz of torrents is posted above -matt

[sav]

Replying to anonymous:

tar.gz of torrents is posted above -matt

I loaded all in OpenWrt? for asus wl500gp v1 rtorrent r1130 - OK!

[anonymous]

hmm. i've had rtorrent do 7+ cpu hours on my nas since the last crash....seems as long as i avoid those specific torrents i'm in good shape. thanks for testing. maybe it is arch dependent?

-matt

[sav]

Replying to anonymous:

hmm. i've had rtorrent do 7+ cpu hours on my nas since the last crash....seems as long as i avoid those specific torrents i'm in good shape. thanks for testing. maybe it is arch dependent? -matt

I had similar problems with my Asus. I used the flags gcc -fno-inline -fno-strict-aliasing when compiling libtorrent - the problem disappeared. Valid only up to version libtorrent r1143, after - to crashing.

[anonymous]

i re-compiled 0.8.6/0.12.6 using -fno-inline and -fno-strict-aliasing. rtorrent has now locked up 2x within a couple minutes on those same two problematic torrents:

[Throttle  30/off KB] [Rate  27.0/ 64.9 KB] [Port: 6890]                                                                                                                     [U 4/16] [D 18/0] [H 0/32] [S 0/29/768] [F 104/128]
Program received signal SIGSTOP, Stopped (signal).
0x3062f2d4 in ?? () from /lib/libc.so.0
(gdb) bt
#0  0x3062f2d4 in ?? () from /lib/libc.so.0
#1  0x3062e570 in malloc () from /lib/libc.so.0
#2  0x3062e570 in malloc () from /lib/libc.so.0
#3  0x305543ec in operator new () from /usr/lib/libstdc++.so.6
#4  0x30204b04 in __gnu_cxx::new_allocator<std::pair<int, unsigned long long> >::allocate () from /usr/lib/libtorrent.so.11
#5  0x30204b48 in std::_Deque_base<std::pair<int, unsigned long long>, std::allocator<std::pair<int, unsigned long long> > >::_M_allocate_node () from /usr/lib/libtorrent.so.11
#6  0x30204b94 in std::deque<std::pair<int, unsigned long long>, std::allocator<std::pair<int, unsigned long long> > >::_M_push_front_aux () from /usr/lib/libtorrent.so.11
#7  0x30204c34 in std::deque<std::pair<int, unsigned long long>, std::allocator<std::pair<int, unsigned long long> > >::push_front () from /usr/lib/libtorrent.so.11
#8  0x30203eb4 in torrent::Rate::insert () from /usr/lib/libtorrent.so.11
#9  0x3027f40c in ?? () from /usr/lib/libtorrent.so.11
#10 0x3028b2f4 in ?? () from /usr/lib/libtorrent.so.11
#11 0x30293d90 in ?? () from /usr/lib/libtorrent.so.11
#12 0x30201da0 in std::mem_fun_t<void, torrent::Event>::operator() () from /usr/lib/libtorrent.so.11
#13 0x302020d4 in ?? () from /usr/lib/libtorrent.so.11
#14 0x3020216c in std::for_each<__gnu_cxx::__normal_iterator<torrent::Event**, std::vector<torrent::Event*, std::allocator<torrent::Event*> > >, torrent::poll_check_t<std::mem_fun_t<void, torrent::Event> > > ()
   from /usr/lib/libtorrent.so.11
#15 0x30200fb8 in torrent::PollSelect::perform () from /usr/lib/libtorrent.so.11
#16 0x10094454 in core::PollManagerSelect::poll (this=0x101632a8, timeout={m_time = 99302}) at poll_manager_select.cc:120
#17 0x1004e91c in main (argc=<value optimized out>, argv=<value optimized out>) at main.cc:321

-matt

[anonymous]

also, it is locked up at 99% cpu, with no network/disk activity. an strace of the first lockup showed nothing. ui is not responsive.

-matt

[anonymous]

i compiled libtorrent/rtorrent again w/-ggdb3, unstripped, and without the two compiler directives you mentioned.

i think i got a much more usable backtrace this way. this is it crashing (not the lockup). i will post the exact torrent that's doing it below. there are many trackers used, though i don't know if it's related to that.

(gdb) bt full
#0  0x30514ebc in kill () from /lib/libc.so.0
No symbol table info available.
#1  0x30559d20 in abort () from /lib/libc.so.0
No symbol table info available.
#2  0x30559310 in ?? () from /lib/libc.so.0
No symbol table info available.
#3  0x30558570 in malloc () from /lib/libc.so.0
No symbol table info available.
#4  0x3047e3ec in operator new () from /usr/lib/libstdc++.so.6
No symbol table info available.
#5  0x3018cf10 in torrent::Rate::insert (this=0x10214088, bytes=3938) at /home/matt/devel/tmp/staging/ppc405-angstrom-linux-uclibc//usr/include/c++/ext/new_allocator.h:89
No locals.
#6  0x301e4434 in torrent::ThrottleList::node_used (this=0x10127930, node=0x10214080, used=3938) at throttle_list.cc:188
        quota = <value optimized out>
#7  0x301f0378 in torrent::PeerConnectionBase::down_chunk (this=0x10213fc8) at peer_connection_base.cc:428
        quota = <value optimized out>
        bytesTransfered = 3938
        transfer = (torrent::BlockTransfer *) 0x10227b68
        itr = {m_chunk = 0x10126528, m_iterator = {_M_current = 0x101cc488}, m_first = 64, m_last = 2425}
#8  0x301f7068 in torrent::PeerConnection<(torrent::Download::ConnectionType)0>::event_read (this=0x10213fc8) at peer_connection_leech.cc:407
No locals.
#9  0x3018c0d8 in std::for_each<__gnu_cxx::__normal_iterator<torrent::Event**, std::vector<torrent::Event*, std::allocator<torrent::Event*> > >, torrent::poll_check_t<std::mem_fun_t<void, torrent::Event> > > (__first=Cannot 
access memory at address 0x6
)
    at /home/matt/devel/tmp/staging/ppc405-angstrom-linux-uclibc//usr/include/c++/bits/stl_function.h:533
No locals.
#10 0x3018acf4 in torrent::PollSelect::perform (this=0x10120358, readSet=0x10126418, writeSet=0x101264a0, exceptSet=0x10126528) at poll_select.cc:165
No locals.
#11 0x1007bf90 in core::PollManagerSelect::poll (this=0x101202a8, timeout=Cannot access memory at address 0x0
) at poll_manager_select.cc:120
        maxFd = 62
        t = {tv_sec = 0, tv_usec = 100939}
#12 0x1003ae9c in main (argc=<value optimized out>, argv=<value optimized out>) at main.cc:321
        firstArg = <value optimized out>

-matt

[anonymous]

single torrent repeatedly causing segfault on uclibc/ppc405

[anonymous]

also, i have a gdb instance detached, waiting at the prompt, from the last 'bt full'. if any more info is needed, let me know, and i can examine memory locations etc.

/home/matt/devel/tmp/staging/ppc405-angstrom-linux-uclibc//usr/include/c++/bits/stl_function.h:533

  template<typename _Ret, typename _Tp>
    class mem_fun_t : public unary_function<_Tp*, _Ret>
    {
    public:
      explicit
      mem_fun_t(_Ret (_Tp::*__pf)())
      : _M_f(__pf) { }

      _Ret
      operator()(_Tp* __p) const
      { return (__p->*_M_f)(); }   <---- line 533

    private:
      _Ret (_Tp::*_M_f)();
    };

it's a bit beyond me, but might save someone from downloading uclibc source.

thanks, -matt

[anonymous]

sorry, that stl_function.h is from libstdc++ 4.4.1, not uclibc as mentioned above.

-matt

[anonymous]

update on this: the problem hasn't appeared before, or since. only the torrent attached to this ticket has caused the issue to arise.

thanks, -matt

[allen]

I got the same problem on nas router , just only some torrents can cause segfault

[anonymous]

Replying to allen:

I got the same problem on nas router , just only some torrents can cause segfault with 0.8.0/0.12.0,

[anonymous]

noticed that my kernel doesn't have support for EPOLL compiled in, so i think its falling back to select(). maybe this doesnt effect epoll(), so thats why it wasn't reproduced on my x86 sys?

-matt