Topic: terminate called after throwing an instance of 'std::bad_alloc'

[Rosencrantz]

Got this one after I got precursors compiling on the amd64. I'm mostly just posting this for reference  while I figure out what's causing this. It happened while connecting to a dedicated server, same error whether I connected to kashmir or locally.

Code: [Select]

terminate called after throwing an instance of 'std::bad_alloc'
  what():  St9bad_alloc

Program received signal SIGABRT, Aborted.
[Switching to Thread 47026429997440 (LWP 29038)]
0x00002ac5315e66c5 in raise () from /lib/libc.so.6
(gdb) where
#0  0x00002ac5315e66c5 in raise () from /lib/libc.so.6
#1  0x00002ac5315e78ce in abort () from /lib/libc.so.6
#2  0x00002ac5313686c4 in __gnu_cxx::__verbose_terminate_handler () from /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/libstdc++.so.6
#3  0x00002ac531366846 in std::set_unexpected () from /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/libstdc++.so.6
#4  0x00002ac531366873 in std::terminate () from /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/libstdc++.so.6
#5  0x00002ac53136695a in __cxa_throw () from /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/libstdc++.so.6
#6  0x00002ac531366c39 in operator new () from /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/libstdc++.so.6
#7  0x00002ac531366ce9 in operator new[] () from /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/libstdc++.so.6
#8  0x00002aaaace42b2e in celGenericParameterBlock (this=0x1184930, count=2926213956668227591) at stdparams.h:98
#9  0x00002aaaace33ce7 in Precursors::Networking::celClientNetworkLayer::DeserializeParameterBlock (this=0xfac0e0, bs=0x1189bf0, data=@0x7fff7a1f7e80)
    at celClientNetworkLayer.cpp:1120
#10 0x00002aaaace37cc1 in Precursors::Networking::celClientNetworkLayer::Receive (this=0xfac0e0) at celClientNetworkLayer.cpp:578
#11 0x00002aaaace3335e in Precursors::Networking::celClientNetworkLayer::TickEveryFrame (this=0xfac0e0) at celClientNetworkLayer.cpp:1012
#12 0x00002ac5349738f3 in celPlLayer::HandleEvent (this=0x7a8be0, ev=@0x2aaaac106b18) at pl.cpp:122
#13 0x00002ac53498db91 in celPlLayer::EventHandler::HandleEvent (this=0x7a9ed0, ev=@0x2aaaac106b18) at pl.h:261
#14 0x00000000004ca4b9 in csEventTree::Dispatch (this=0x7a6e90, e=@0x2aaaac106b18) at cssubscription.cpp:576
#15 0x00000000004ca574 in csEventTree::Notify (this=0x7a6e90) at cssubscription.cpp:546
#16 0x00000000004b225e in csEventQueue::Notify (this=0x730440, name=@0x72a248) at cseventq.cpp:277
#17 0x00000000004baac9 in csEventQueue::iTypedFrameEventDispatcher::HandleEvent (this=0x72a238) at cseventq.h:262
#18 0x00000000004ca4b9 in csEventTree::Dispatch (this=0x721f60, e=@0x892d98) at cssubscription.cpp:576
#19 0x00000000004ca574 in csEventTree::Notify (this=0x721f60) at cssubscription.cpp:546
#20 0x00000000004b225e in csEventQueue::Notify (this=0x730440, name=@0x7305b8) at cseventq.cpp:277
#21 0x00000000004b231d in csEventQueue::Process (this=0x730440) at cseventq.cpp:293
#22 0x000000000047ebf5 in csDefaultRunLoop (r=0x730238) at runloop.cpp:91
#23 0x000000000045f1b0 in csApplicationFramework::Run () at csapplicationframework.h:330
#24 0x000000000045aa64 in Precursors::preClient::Application (this=0x7fff7a1f9230) at preClient.cpp:558
#25 0x00000000004825b3 in csApplicationFramework::Start () at csapplicationframework.cpp:71
---Type <return> to continue, or q <return> to quit---
#26 0x0000000000482921 in csApplicationFramework::Main (this=0x7fff7a1f9230, argc=1, argv=0x7fff7a1f9498) at csapplicationframework.cpp:131
#27 0x0000000000455eda in csApplicationRunner<Precursors::preClient>::Run (argc=1, argv=0x7fff7a1f9498) at csapplicationframework.h:441
#28 0x0000000000455670 in main (argc=1, argv=0x7fff7a1f9498) at main.cpp:55


[Rosencrantz]

Hmm, interesting it looks like the bitstream borked on the read and set the count to something absurdly huge, and then new barfed. Odd.

[Rosencrantz]

More details.
It looks like the bitstream for the Ares entity is fine, it's just when it moves to dealing with the Archigos entity that it barfs.

What happens for the "Ares" is that it ends up setting the unsigned char version of the count to \005.
With the "Archigos" the first half of the read sets it to \004 and then the second half actually executes and sets it to \a (and then new barfs because that becomes something absurdly huge).

Second half is from
RakNet::BitStream::ReadBits at BitStream.cpp:467
Specifically line 488.