Assertation faults, patches & valgrind

[xcb567]

Hi all

Been having MC-Server running here for a short while until I got hit by the "Assertation fault" mentioned in Mobs spawning.
Thought it might be useful for the devs to have the output from valgrind when it happens, so uploaded them at /2012-11-21_2037/errors/
The svn-1060 folder are from a clean svn checkout, the other folder is after the patches below was applied

In case patches of upstream updates of jsoncpp, lua and cryptopp are of interest those are at /2012-11-21_2037/patches/


Edit: There's also a tiny patch for reviving the MagicCarpet plugin

[xoft]

Rev 1057 should have the assertion all fixed, does it work for you or do you still get them?

Also, could you possible sum up the differences in the library upgrades? Just to list the reasons why we should upgrade, rather than staying with the version that's working okay for us.

[xcb567]

Rev 1057 should have the assertion all fixed, does it work for you or do you still get them?

The assertions still appear in the r1060 debug build, the release build is ok.

Also, could you possible sum up the differences in the library upgrades? Just to list the reasons why we should upgrade, rather than staying with the version that's working okay for us. :)

Mostly upstream bugfixes, the major revision/version changes:

Jsoncpp (r139 -> r250)

• Bug #2934500: Removed experimental ValueAllocator, it caused static initialization/destruction order issues.
  
• Bug #3139677: JSON [1 2 3] was incorrectly parsed as [1, 3]. Error is now correctly detected.
  
• Fixed a hard to debug crash on OS X related to sscanf format strings.
  
• Made two security fixes.
  
• Fixed a parsing bug in decodeNumber
  
• Another round of attempting to fix VC++ errors...
  
• Bug#3306345: minor typo in Path::resolve()
  
• Bug#2407932: strpbrk() could fail for NULL pointer.

CryptoPP (r520 -> r533)

• Bug #6: Disable some inline assembler code from crypto++ causing compiler segfault
  
• Fixed some gcc 4.6 compile errors
  
• Bug#76: fix for Valgrind error

Lua (v5.1.4 -> v5.1.5)

• Wrong code generation for some particular boolean expressions.
  
• luaV_settable may invalidate a reference to a table and try to reuse it.
  
• GarbageCollector may get stuck during parsing and avoids proper resizing of the string table, making its lists grow too much and degrading performance.
  
• io.read("*n","*n") may return garbage if second read fails.
  
• Newindex metamethod may not work if metatable is its own metatable.
  
• Parser may collect a prototype while building it.

[xoft]

Assertions are exactly for debugging - they are operations that verify that things are what the programmer assumes them to be, but these checks are too costly to perform in runtime. Instead, it is expected that the developers catch all of their occurences in debug mode. That's why they don't appear in release mode.

Can you post a gdb stack trace of such an assert? I'm very interested in what the circumstances were when it happenned.

The library upgrades look useful enough (and most importantly, not-breaking-anything enough ), so I'll integrate them when I have time. Or ask FakeTruth to give you write access to the svn

[xcb567]

Assertions are exactly for debugging - they are operations that verify that things are what the programmer assumes them to be, but these checks are too costly to perform in runtime. Instead, it is expected that the developers catch all of their occurences in debug mode. That's why they don't appear in release mode.

Can you post a gdb stack trace of such an assert? I'm very interested in what the circumstances were when it happenned.

A clean checkout of r1061 (with or without lib updates) is currently running here

The library upgrades look useful enough (and most importantly, not-breaking-anything enough ), so I'll integrate them when I have time. Or ask FakeTruth to give you write access to the svn

Thanks, svn write access is not necessary. I won't have that much to contribute to the code

---

Assertation:

Code:

[f0d12700|18:35:32] Assertion failed: m_ReadPos < m_BufferSize, file source/ByteBuffer.cpp, line 578
MCServer: source/ByteBuffer.cpp:578: void cByteBuffer::CheckValid() const: Assertion `0' failed.

Program received signal SIGABRT, Aborted.
[Switching to Thread 0x7ffff0d12700 (LWP 14701)]
0x00007ffff70cd475 in *__GI_raise (sig=<optimized out>)
    at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
64    ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.

Threads:

Code:

Id   Target Id         Frame
  14   Thread 0x7ffff0d12700 (LWP 14701) "MCServer" 0x00007ffff70cd475 in *__GI_raise (
    sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
* 13   Thread 0x7ffff1513700 (LWP 14700) "MCServer" 0x00007ffff716773d in read ()
    at ../sysdeps/unix/syscall-template.S:82
  12   Thread 0x7ffff1d14700 (LWP 14699) "MCServer" 0x00007ffff714487d in nanosleep ()
    at ../sysdeps/unix/syscall-template.S:82
  11   Thread 0x7ffff25e2700 (LWP 14698) "MCServer" 0x00007ffff74303cd in accept ()
    at ../sysdeps/unix/syscall-template.S:82
  8    Thread 0x7ffff3919700 (LWP 14695) "MCServer" sem_wait ()
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_wait.S:86
  7    Thread 0x7ffff411a700 (LWP 14694) "MCServer" sem_wait ()
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_wait.S:86
  6    Thread 0x7ffff491b700 (LWP 14693) "MCServer" sem_wait ()
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_wait.S:86
  5    Thread 0x7ffff511c700 (LWP 14692) "MCServer" sem_wait ()
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_wait.S:86
  4    Thread 0x7ffff591d700 (LWP 14691) "MCServer" sem_wait ()
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_wait.S:86
  3    Thread 0x7ffff6899700 (LWP 14690) "MCServer" 0x00007ffff74303cd in accept ()
    at ../sysdeps/unix/syscall-template.S:82
  2    Thread 0x7ffff709a700 (LWP 14689) "MCServer" sem_wait ()
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_wait.S:86
  1    Thread 0x7ffff7fe4720 (LWP 14686) "MCServer" 0x00007ffff714487d in nanosleep ()
    at ../sysdeps/unix/syscall-template.S:82

Thread #14:

Code:

#0  0x00007ffff70cd475 in *__GI_raise (sig=<optimized out>)
    at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0x00007ffff70d06f0 in *__GI_abort () at abort.c:92
#2  0x00007ffff70c6621 in *__GI___assert_fail (assertion=0x82e94f "0", file=<optimized out>,
    line=578, function=0x82ea20 "void cByteBuffer::CheckValid() const") at assert.c:81
#3  0x00000000006c7f0b in cByteBuffer::CheckValid (this=0xd46e40) at source/ByteBuffer.cpp:578
#4  0x00000000006297e9 in cProtocol125::ParsePlayerOnGround (this=0xd46df0)
    at source/Protocol/Protocol125.cpp:1189
#5  0x0000000000628305 in cProtocol125::ParsePacket (this=0xd46df0, a_PacketType=10 '\n')
    at source/Protocol/Protocol125.cpp:921
#6  0x0000000000622442 in cProtocol132::ParsePacket (this=0xd46df0, a_PacketType=10 '\n')
    at source/Protocol/Protocol132.cpp:473
#7  0x0000000000627f8e in cProtocol125::DataReceived (this=0xd46df0,
    a_Data=0x7ffff0d11610 "\n\001", a_Size=2) at source/Protocol/Protocol125.cpp:868
#8  0x0000000000621299 in cProtocol132::DataReceived (this=0xd46df0,
    a_Data=0x7ffff0d118d0 "L-\351\020\026nSB\334c\212Y\022K{\264\212j\235\334\304>\200\327G\006\213/6\377\370\337\017\373\250\v\345\353\"'S\341K\221~\373S\017\065\036NJ`J\241\373\233\254l\027\323pu\260\027\247\033N\361z\270{\240\031\321\360\377\177", a_Size=2) at source/Protocol/Protocol132.cpp:188
#9  0x000000000062b2ca in cProtocolRecognizer::DataReceived (this=0xd58860,
    a_Data=0x7ffff0d118d0 "L-\351\020\026nSB\334c\212Y\022K{\264\212j\235\334\304>\200\327G\006\213/6\377\370\337\017\373\250\v\345\353\"'S\341K\221~\373S\017\065\036NJ`J\241\373\233\254l\027\323pu\260\027\247\033N\361z\270{\240\031\321\360\377\177", a_Size=2)
    at source/Protocol/ProtocolRecognizer.cpp:82
#10 0x0000000000713727 in cClientHandle::DataReceived (this=0xd46830,
    a_Data=0x7ffff0d118d0 "L-\351\020\026nSB\334c\212Y\022K{\264\212j\235\334\304>\200\327G\006\213/6\377\370\337\017\373\250\v\345\353\"'S\341K\221~\373S\017\065\036NJ`J\241\373\233\254l\027\323pu\260\027\247\033N\361z\270{\240\031\321\360\377\177", a_Size=2) at source/ClientHandle.cpp:1739
#11 0x0000000000659c88 in cSocketThreads::cSocketThread::ReadFromSockets (this=0xd58a80,
    a_Read=0x7ffff0d11d20) at source/OSSupport/SocketThreads.cpp:600
#12 0x0000000000659644 in cSocketThreads::cSocketThread::Execute (this=0xd58a80)
    at source/OSSupport/SocketThreads.cpp:517
#13 0x000000000065bdde in cIsThread::thrExecute (a_Param=0xd58a80)
    at source/OSSupport/IsThread.h:62
#14 0x00007ffff7428b50 in start_thread (arg=<optimized out>) at pthread_create.c:304
#15 0x00007ffff717370d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#16 0x0000000000000000 in ?? ()

Thread #13:

Code:

#0  0x00007ffff716773d in read () at ../sysdeps/unix/syscall-template.S:82
#1  0x00007ffff710ce68 in _IO_new_file_underflow (fp=0x7ffff741c6c0) at fileops.c:606
#2  0x00007ffff710e54e in _IO_default_uflow (fp=0x0) at genops.c:440
#3  0x00007ffff7105a2b in _IO_getc (fp=0x7ffff741c6c0) at getc.c:41
#4  0x00007ffff7b6e63d in __gnu_cxx::stdio_sync_filebuf<char, std::char_traits<char> >::underflow()
    () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#5  0x00007ffff7b509c3 in std::basic_istream<char, std::char_traits<char> >& std::getline<char, std::char_traits<char>, std::allocator<char> >(std::basic_istream<char, std::char_traits<char> >&, std::basic_string<char, std::char_traits<char>, std::allocator<char> >&, char) ()
   from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#6  0x00000000006f3f4c in cRoot::InputThread (a_Params=0x7fffffffe140) at source/Root.cpp:75
#7  0x000000000065b34a in cThread::MyThread (a_Param=0xb84dd0) at source/OSSupport/Thread.cpp:124
#8  0x00007ffff7428b50 in start_thread (arg=<optimized out>) at pthread_create.c:304
#9  0x00007ffff717370d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#10 0x0000000000000000 in ?? ()

[xoft]

Wow. There was a very very slight chance for an error. It had a very specific set of preconditions - it could occur only once every 64 KiB read from the client (usually once in 10 minutes), and the client protocol would need to be sending a boolean value at that specific moment.
And yet you managed to hit that
Should be fixed in rev 1063.

[xoft]

I've applied the CryptoPP patch; with the rest I'm not sure whether to do it - they're not as much patches as totally new code drops.