Bug #857
linux/assertion failure CCoTask::getCurrentTask() == this
Status: | Closed | Start date: | 05/08/2010 | |
---|---|---|---|---|
Priority: | Normal | Due date: | ||
Assignee: | vl | % Done: | 100% |
|
Category: | Client: General | |||
Target version: | Version 0.8.0 |
Description
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?
History
#1 Updated by ratmice over 8 years ago
- File xml.diff added
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 over 8 years ago
- Status changed from New to Assigned
- Assignee set to vl
#3 Updated by vl over 8 years ago
- Status changed from Assigned to Resolved
- % Done changed from 0 to 100
Applied in changeset r65.
#4 Updated by vl over 8 years ago
- Target version set to Version 0.8.0
#5 Updated by vl about 8 years ago
- Status changed from Resolved to Closed