World Crash (x64)

[John Adams]

I just realized the Linux box I built for VGOEmu this weekend is an x64 box. Not sure if that's supported yet, but it compiled

Reason I mention that is the error I see is about multiarch -

[quote]18:24:32.241 E UDP Either there is a lot of packet loss or the client is no t acking this packet

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff5852700 (LWP 11704)]
__memmove_ssse3 () at ../sysdeps/x86_64/multiarch/memcpy-ssse3.S:2819
2819 ../sysdeps/x86_64/multiarch/memcpy-ssse3.S: No such file or directory.
[/quote]

Code: Select all

(gdb) bt
#0  __memmove_ssse3 () at ../sysdeps/x86_64/multiarch/memcpy-ssse3.S:2819
#1  0x000000000042185e in std::__copy_move<false, true, std::random_access_iterator_tag>::__copy_m<ClientSocketData*> (__first=0x68cdc8, __last=0x68cdc0,
    __result=0x68cdc0) at /usr/include/c++/4.8/bits/stl_algobase.h:372
#2  0x000000000042093a in std::__copy_move_a<false, ClientSocketData**, ClientSocketData**> (__first=0x68cdc8, __last=0x68cdc0, __result=0x68cdc0)
    at /usr/include/c++/4.8/bits/stl_algobase.h:390
#3  0x000000000041f63f in std::__copy_move_a2<false, __gnu_cxx::__normal_iterator<ClientSocketData**, std::vector<ClientSocketData*, std::allocator<ClientSocketData*> > >, __gnu_cxx::__normal_iterator<ClientSocketData**, std::vector<ClientSocketData*, std::allocator<ClientSocketData*> > > > (__first=..., __last=...,
    __result=...) at /usr/include/c++/4.8/bits/stl_algobase.h:428
#4  0x000000000041e39d in std::copy<__gnu_cxx::__normal_iterator<ClientSocketData**, std::vector<ClientSocketData*, std::allocator<ClientSocketData*> > >, __gnu_cxx::__normal_iterator<ClientSocketData**, std::vector<ClientSocketData*, std::allocator<ClientSocketData*> > > > (__first=..., __last=..., __result=...)
    at /usr/include/c++/4.8/bits/stl_algobase.h:460
#5  0x000000000041cf66 in std::vector<ClientSocketData*, std::allocator<ClientSocketData*> >::erase (this=0x669318 <net+472>, __position=...)
    at /usr/include/c++/4.8/bits/vector.tcc:138
#6  0x000000000041a575 in UDPServer::HandleWrite (this=0x669140 <net>)
    at ../common/UDPServer.cpp:573
#7  0x00000000004187d3 in WriterThread (data=0x669140 <net>)
---Type <return> to continue, or q <return> to quit---
    at ../common/UDPServer.cpp:116
#8  0x00000000004183f0 in ThreadRun (arg=0x68a710) at ../common/Thread.cpp:77
#9  0x00007ffff768cf6e in start_thread (arg=0x7ffff5852700)
    at pthread_create.c:311
#10 0x00007ffff6b999cd in clone ()
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113

[theFoof]

viewtopic.php?f=22&t=359&p=2264#p2264 looks like the same crash. Maybe change the outgoing.erase(outgoing.begin()); call to outgoing.pop_front(); (whoops pop_front is deque not vector) it looks fine how it is though.

[John Adams]

Cool, I see no one noticed yours either. Let's see if we can get this fixed.

But...

[quote] ../sysdeps/x86_64/multiarch/memcpy-ssse3.S: No such file or directory.[/quote]

[Xen]

I've run the emu on my 64-bit Ubuntu VM and haven't run into that crash.

[John Adams]

Yeah I haven't seen it since either. Love those kinds of bugs.

[theFoof]

I'm actually going to convert some of these vectors over to std::deques, we're inserting/removing stuff from the beginning in some cases so those should perform better. I think the other client crash will be easy to fix as well.

proof! http://baptiste-wicht.com/posts/2012/12 ... deque.html

[John Adams]

Foof, you asked me this here and I just stumbled back upon this post from you about the deques.

Does my last post in that thread hint that the deque's are to blame? You asked about how long this was happening, and it very well could be 2 weeks ago.