python: pthread_mutex_lock.c:62: __pthread_mutex_lock: Assertion `mutex->__data.__owner == 0' failed.

[Paul Kraus]

My turbogears 2.1.1 app keeps dieing with ...

python: pthread_mutex_lock.c:62: __pthread_mutex_lock: Assertion `mutex->__data.__owner == 0' failed.

Any idea what might be causing this?

[Michael Pedersen]

Unfortunately, not really.

What I am seeing indicates some sort of problem with threading, though, and that's an OS level item. To try to troubleshoot, we need to know exactly which operating system and revision you are using. In addition, we need to know exactly which version of Python. You can obtain that with "Python -V". As to the OS version, that's obtainable in too many different (and incompatible) ways. You'll have to know that part.

--
You received this message because you are subscribed to the Google Groups "TurboGears" group.
To view this discussion on the web visit https://groups.google.com/d/msg/turbogears/-/xIc4cjSr8lgJ.
To post to this group, send email to turbo...@googlegroups.com.
To unsubscribe from this group, send email to turbogears+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/turbogears?hl=en.

--
Michael J. Pedersen
My IM IDs: Jabber/pede...@icelus.tzo.com, AIM/pedermj022171
          Yahoo/pedermj2002, MSN/pederm...@hotmail.com
My LinkedIn Profile: http://www.linkedin.com/in/michaeljpedersen
Twitter: pedersentg

[Paul Kraus]

Ubuntu 32bit 10.04 TLS
Python 2.6.5

uname -a
Linux teletraan1 2.6.32-32-generic-pae #62-Ubuntu SMP Wed Apr 20 22:10:33 UTC 2011 i686 GNU/Linux

I am not even sure how to go about tracking this down. I think this has something to do with mxodbc but like I said I am not even sure where to start with this.

Here is what have done so far. It seems to happen when there are a lot of queries being processed by mxODBC so yesterday I rewrote some code and moved things around and the problem seemed to go away no issue all day until the end of the day where it crashed 3 times with in 30 minutes (high activity part of day).

Prior to all of this I was having random issues with mxODBC segfaulting and as part of that hunt I eventually moved to the 32bit version of ubuntu(suggested by egenix), problem persisted so I for kicks moved the DB connection into the same function with the query so for each query it connects, runs query, and then destroys itself. With this change the segfaults stopped but these pthread_mutex_lock errors replaced them at the exact time of the change. Prior to this change only segfaults, after this change no segfaults but these mutex issues.

Then I thought maybe it had something to do with scheduler. I had scheduler running some order imports into the app over  couple of minutes and the pthread issues where happening like crazy. Set scheduler to make sure it ran sequentially and this had no effect. Moved it to a cron script that checks to see if its already running and I was off to testing today. As I said earlier no issues all day long until the last half hour of the day (major improvement) but obviously not a fix but I am more confident that this has something to do with mxODBC.

I can not reproduce this error on my own it only seems to appear when the system is under heavy load (not if i would call it heavy but 8 users each running a query every couple of seconds).

PK

[Michael Pedersen]

Okay, I'll admit that I've got no reason for this, though I do have questions:

1. Is mxODBC being accessed directly, or it being accessed via SQLAlchemy?
2. If it *is* via SQLAlchemy, can you switch to pyODBC instead, and see if that will work properly for you?
3. If it is *not* via SQLAlchemy, can you try pyODBC anyway?

If the problem is with mxODBC, and you can't get that to work reliably, I'd look elsewhere. pyODBC seems like a viable candidate.

--
You received this message because you are subscribed to the Google Groups "TurboGears" group.

To view this discussion on the web visit https://groups.google.com/d/msg/turbogears/-/2oMhTdRRXIcJ.

To post to this group, send email to turbo...@googlegroups.com.
To unsubscribe from this group, send email to turbogears+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/turbogears?hl=en.