VGOEmulator.net

Posted: **Mon Apr 14, 2014 6:43 am**

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

Posted: **Mon Apr 14, 2014 7:01 am**

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.

Posted: **Mon Apr 14, 2014 7:17 am**

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]

Posted: **Wed Apr 16, 2014 7:08 am**

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

Posted: **Wed Apr 16, 2014 7:30 am**

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

Posted: **Wed Apr 16, 2014 10:30 pm**

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

Posted: **Wed Apr 30, 2014 9:38 pm**

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.

VGOEmulator.net

World Crash (x64)

World Crash (x64)

Re: World Crash (x64)

Re: World Crash (x64)

Re: World Crash (x64)

Re: World Crash (x64)

Re: World Crash (x64)

Re: World Crash (x64)