XMLRPCResponder constructor was missing.
This fixes the following crash signature:
VIEWER : 2012-12-12T14:25:13Z INFO("AppInit"): setStartupState: Startup state changing from STATE_LOGIN_NO_DATA_YET to STATE_LOGIN_DOWNLOADING
VIEWER : 2012-12-12T14:25:14Z INFO("AppInit"): transferRate: Buffer size: 1308 B
VIEWER : 2012-12-12T14:25:14Z INFO("AppInit"): transferRate: Transfer rate: 11 kb/s
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff33df7f5 in XMLRPC_RequestGetData () from /usr/lib/x86_64-linux-gnu/libxmlrpc-epi.so.0
(gdb) bt
Reason was that if the server replied with some error code then
mResponse was undefined.
I also added code to retry three times in that case;
the http status code that I get was 503, which really
mean "Service *temporarily* unavailable", so a retry
is in order.
XMLRPCResponder constructor was missing.
This fixes the following crash signature:
VIEWER : 2012-12-12T14:25:13Z INFO("AppInit"): setStartupState: Startup state changing from STATE_LOGIN_NO_DATA_YET to STATE_LOGIN_DOWNLOADING
VIEWER : 2012-12-12T14:25:14Z INFO("AppInit"): transferRate: Buffer size: 1308 B
VIEWER : 2012-12-12T14:25:14Z INFO("AppInit"): transferRate: Transfer rate: 11 kb/s
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff33df7f5 in XMLRPC_RequestGetData () from /usr/lib/x86_64-linux-gnu/libxmlrpc-epi.so.0
(gdb) bt
Reason was that if the server replied with some error code then
mResponse was undefined.
I also added code to retry three times in that case;
the http status code that I get was 503, which really
mean "Service *temporarily* unavailable", so a retry
is in order.
Conflicts:
indra/llcommon/CMakeLists.txt
indra/llmessage/llcurl.cpp
indra/llmessage/llcurl.h
indra/llmessage/llhttpclient.cpp
indra/llmessage/llhttpclient.h
indra/llmessage/llpumpio.cpp
indra/llmessage/llpumpio.h
indra/llmessage/llurlrequest.cpp
indra/llmessage/llurlrequest.h
indra/newview/hipporestrequest.cpp
indra/newview/llappviewer.cpp
indra/newview/llspatialpartition.cpp
indra/newview/llviewermedia.cpp
indra/newview/llxmlrpctransaction.cpp
Conflicts resolved by choosing curlthreading2
for any llmessage file regardless (which looks
correct upon investigation); the rest also
turned out to need to use curlthreading2, except
in one line where I added a semi-colon after
an assert(), and the assert was changed in
singu/master.
Tweaked LLRenderTarget to support depth textures if FBO support is lacking.
Prefer LLRenderTarget::getFBO() over LLRenderTarget::sUseFBO when determining how to handle a specific LLRenderTarget object. (Decoupling to simplify logic without having to track a global)
Conflicts:
indra/llcommon/llstring.cpp
indra/llmessage/llcurl.cpp
indra/newview/llviewertexturelist.cpp
indra/newview/viewer_manifest.py
install.xml
Resolved:
indra/llcommon/llstring.cpp :
two different ways to work around compile error.
indra/llmessage/llcurl.cpp :
this file is no longer used.. I deleted huge
parts to mark that I implemented that. Siana
apparently made a few changes in those parts.
indra/newview/llviewertexturelist.cpp :
manually copied patch. Mine also removed trailing
spaces, keeping that.
indra/newview/viewer_manifest.py:
Collision with changes from Liru, which have been
ignored (kept siana/master).
install.xml:
Collision with an earlier screw up. I kept the
fix from siana/master.
Conflicts:
indra/llmessage/llcurl.cpp
indra/llmessage/llcurl.h
indra/newview/app_settings/settings.xml
indra/newview/llappviewer.cpp
indra/newview/llmeshrepository.cpp
Resolved:
indra/llmessage/llcurl.cpp:
Basically removed (not used anyway)
indra/llmessage/llcurl.h:
Basically removed (just includes aiculr.h now)
indra/newview/app_settings/settings.xml:
CurlUseMultipleThreads was remvoved.
CurlMaximumNumberOfHandles and CurlRequestTimeOut
are still in there, but unused at the moment.
indra/newview/llappviewer.cpp:
CurlMaximumNumberOfHandles and CurlRequestTimeOut
are unused at the moment.
indra/newview/llmeshrepository.cpp:
Lock mSignal always (is unlocked inside wait()).
Use mSignal lock to see if we are waiting; remove mWaiting.
Return false from the MeshFetch functions iff we have to retry
a HTTP fetch. Catch the error exception thrown by getByteRange
instead of using it's return value (always returns true
anyway).
