Bug #857

linux/assertion failure CCoTask::getCurrentTask() == this

Added by ratmice about 9 years ago. Updated almost 10 years ago.

Status:Closed Start date:05/08/2010
Priority:Normal Due date:
Assignee:vl % Done:


Category:Client: General
Target version:Version 0.8.0


This is a difficult to figure out problem so i figured i'd better document it,
before someone else spends a bunch of time trying to figure it out...

what appears to be happening when I hit this error is that

we create libxml2 threads to parse stuff, libxml2 calls pthread_key_create
gets a key, libxml2 thread exits, and the key is pthread_key_delete()'d
but libxml2 caches this key in a 'globalkey' variable,

the client then calls pthread_key_create, gets the same key handed out
we startup more libxml2 threads, and those use what is now our key...
they do some stuff, and pthread_key_delete() and our values go poof.

pthread_getspecific then gets called with our key and returns NULL, and we hit this assertion
because NULL != this.

I have hacked the client here in CTDS::CTDS
to check if (_Key == 3) { get a new key; then pthread_key_delete(3); }
with this change I get much further (character creation screen), YMMV and it is a really really horrible workaround.

potential solutions are somehow ensuring that the first libxml2 thread never exists?
or fixing libxml2?

xml.diff (334 Bytes) Magnifier ratmice, 05/10/2010 01:47 am


#1 Updated by ratmice about 9 years ago

Ok, so I looked into this a bit further:
seems that calling xmlCleanupParser in CIXML::release() is the entire problem.

  • xmlCleanupParser: *
  • This function name is somewhat misleading. It does not clean up
  • parser state, it cleans up memory allocated by the library itself.
  • WARNING: if your application is multithreaded or has plugin support
  • calling this may crash the application if another thread or
  • a plugin is still using libxml2. It's sometimes very hard to
  • guess if libxml2 is in use in the application, some libraries
  • or plugins may use it without notice. In case of doubt abstain
  • from calling this function or do it just before calling exit()
  • to avoid leak reports from valgrind !

#2 Updated by vl about 9 years ago

  • Status changed from New to Assigned
  • Assignee set to vl

#3 Updated by vl about 9 years ago

  • Status changed from Assigned to Resolved
  • % Done changed from 0 to 100

Applied in changeset r65.

#4 Updated by vl about 9 years ago

  • Target version set to Version 0.8.0

#5 Updated by vl almost 10 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF