Possible Crash Bug
Just an update on some testing (thanks for leaving some debug info in the build, it helped me trace some of it down)
running an strace shows the segmentation fault just after a thread starts... so I looked further into it and it appears that memcpy() is failing in the libc file that it's dynamically using.
I should have a backtrace available for you the next time I can taunt it to crash (can't ever seem to do it when i need it!), on a more serious note the access violation (which seems like is what's happening, writing to memory outside of the user space) would not seem apparent if you ran steamcast as root, as root has no limits on memory space. (FreeBSD exempt in this, as memory limits are global).
Backtrace on Exception:
#0 0x4f3a5ffc in memcpy () from /lib/tls/libc.so.6
#1 0xb7fd1053 in string_char_traits<char>::copy ()
from /usr/lib/libstdc++-libc6.2-2.so.3
#2 0x0807b703 in basic_string<char, string_char_traits<char>, __default_alloc_template<true, 0> >::Rep::copy ()
#3 0x08079308 in basic_string<char, string_char_traits<char>, __default_alloc_template<true, 0> >::replace ()
#4 0x080780a9 in basic_string<char, string_char_traits<char>, __default_alloc_template<true, 0> >::append ()
#5 0x08078225 in basic_string<char, string_char_traits<char>, __default_alloc_template<true, 0> >::operator+= ()
#6 0x0804cf41 in Base64Decode ()
#7 0x08055537 in parse_request_header ()
#8 0x0805ed76 in MTClientThreadWorker ()
#9 0x4f4e798c in start_thread () from /lib/tls/libpthread.so.0
#10 0x4f3f97da in clone () from /lib/tls/libc.so.6
running an strace shows the segmentation fault just after a thread starts... so I looked further into it and it appears that memcpy() is failing in the libc file that it's dynamically using.
I should have a backtrace available for you the next time I can taunt it to crash (can't ever seem to do it when i need it!), on a more serious note the access violation (which seems like is what's happening, writing to memory outside of the user space) would not seem apparent if you ran steamcast as root, as root has no limits on memory space. (FreeBSD exempt in this, as memory limits are global).
Backtrace on Exception:
#0 0x4f3a5ffc in memcpy () from /lib/tls/libc.so.6
#1 0xb7fd1053 in string_char_traits<char>::copy ()
from /usr/lib/libstdc++-libc6.2-2.so.3
#2 0x0807b703 in basic_string<char, string_char_traits<char>, __default_alloc_template<true, 0> >::Rep::copy ()
#3 0x08079308 in basic_string<char, string_char_traits<char>, __default_alloc_template<true, 0> >::replace ()
#4 0x080780a9 in basic_string<char, string_char_traits<char>, __default_alloc_template<true, 0> >::append ()
#5 0x08078225 in basic_string<char, string_char_traits<char>, __default_alloc_template<true, 0> >::operator+= ()
#6 0x0804cf41 in Base64Decode ()
#7 0x08055537 in parse_request_header ()
#8 0x0805ed76 in MTClientThreadWorker ()
#9 0x4f4e798c in start_thread () from /lib/tls/libpthread.so.0
#10 0x4f3f97da in clone () from /lib/tls/libc.so.6
-
Jay
- Will work for food (Administrator)
- Posts: 3025
- Joined: Mon Jan 14, 2002 12:48 am
- Location: Next Door
- Contact:
interesting, I guess I need to put more memory checks in. Also I need to stop using the stack for memory. Perhaps with some tweaking here we can fix this issue. As a side note, Freebsd gave me the same problem and I had to move some memory off the stack.
I'll get this in the next version. As far as timeframes are concerned I hope it won't be too long from now.
I'll get this in the next version. As far as timeframes are concerned I hope it won't be too long from now.
- Jay
And in case no one has mentioned it, thanks to WhiteWolf for his helpful troubleshooting.
I had these issues on redhat enterprise 3. I haven't run it lately, but just did run it for two days as root, and it was stable over that period. I probably didn't run it as root before, as I generallly wouldn't. If you pump out a new version, I'll definitely give it a work out and report back. Unfortunately, not as detailed as WhiteWolf can do!
I had these issues on redhat enterprise 3. I haven't run it lately, but just did run it for two days as root, and it was stable over that period. I probably didn't run it as root before, as I generallly wouldn't. If you pump out a new version, I'll definitely give it a work out and report back. Unfortunately, not as detailed as WhiteWolf can do!