[opensource-dev] Viewer Azumarill (coroutines) issue

Henri Beauchamp sldev at free.fr
Tue Dec 1 05:17:31 PST 2015


Greetings,

Last week, I started backporting viewer-azumarill's coroutine code to
the future experimental branch (v1.26.17) of the Cool VL Viewer. I
first concentrated on backporting only the llcorehttp "coroutined"
code and the related services (i.e. texture fetchs, mesh repository,
AIS and HTTP inventory fetches).

Alas, the resulting viewer kept crashing after each AIS request was
being cleaned-up. I lost a lot of time incriminating my own backport
and searching for something I would have missed in Azumarill's diff,
but in the end, I had to conclude that the problem was with the
llcorehttp coroutine implementation itself.

Today, I worked again on that issue and narrowed down the problem to
a bogus call to a destroyed HttpRequestPumper.

It looks like the LLTempBoundListener associated with an
HttpRequestPumper destroys the latter just before the call to
"mainloop.post(new_frame);" per-frame pumping (in llappviewer.cpp)
and that the event pump didn't yet register the destruction of the
said HttpRequestPumper, thus wrongly calling its pollRequest()
callback (causing a segfault in the latter).

Not having signed a CA, I won't post here the code I used to work
around that problem (in llcorehttputil.cpp), but here is the comment
I wrote for it, which explains it all and could be used with benefit
by LL:

///////////////////////////////////////////////////////////////////////////////
// HttpRequestPumper class
///////////////////////////////////////////////////////////////////////////////

// The HttpRequestPumper is a utility class. When constructed it will poll the
// supplied HttpRequest once per frame until it is destroyed.
// NOTE: I had to change the pollRequest() method for a static one and keep
// track of the existing HttpRequestPumper instances in a list so that, when
// called, pollRequest() checks that the corresponding HttpRequestPumper
// instance does still actually exist. This is because there is a fatal issue
// with so many boost "smart" pointers that get deleted in an order that we do
// not control, the result being in a poll request sometimes happening (always
// under Linux, at the completion and dequeuing of AIS requests) while the
// corresponding HttpRequestPumper just got deleted (probably via the
// LLTempBoundListener boost::signals2::scoped_connection), causing a segfault.
// LL should really stop using boost stuff so much... It's becoming insane:
// obfuscating code complexity behind a gazillion of templates does not make
// the code cleaner (and certainly not faster), much to the contrary !  HB

Note that depending on the plateform/OS (or even compiler version and
optimisations) you compiled viewer-azumarill on, you might not encounter the
issue I hit, but there is an issue with the reliability of the whole code,
because of the uncontrolled and pretty much random sequence of templatized
structures destructions. I think more thinking is necessary, before calling
the current coroutine-based code acceptable.

Regards,

Henri.


More information about the opensource-dev mailing list