Sourcery - Attempt to unlock mutex that was not locked

[Ali82]

I did a fresh install of Salix 14.1, followed by a package upgrade. Now when I run sourcery i get the following error:

Code: Select all

sourcery
Attempt to unlock mutex that was not locked
Aborted

[gapan]

I can tell you that this error does not originate from Sourcery. What exactly did you upgrade? Did you add any custom repos?

[Ali82]

The problem is caused by glib-2.46, which I was experimenting. Changing my LD path, pygtk was loading that version. Anyway, this is a problem to consider, since It reflects a problem in using threading https://lists.debian.org/debian-python/ ... 00004.html.

I didn't have time to lock at the code of sourcery, but I'll do as soon as I can.

[mimosa]

If you mess with C libraries, trouble of that kind is only to be expected. Probably a lot of other things would be broken, too.

[gapan]

The problem is most likely not glib-2.46 alone, but that you'd have to rebuilt almost everything that depends on it, in this case probably pygtk and gtk+2. Sourcery does make use of threading through pygtk, but that shouldn't be a problem when we move to glib-2.46 that is now in slackware-current for the next release.

[Ali82]

The problem is most likely not glib-2.46 alone, but that you'd have to rebuilt almost everything that depends on it

Oh, I did not expect such statement. What is the idea behind dynamic linking then?

Glib2 does not break ABI, so you don't have to rebuild anything when you upgrade it (unless of course the code of your app uses GLIB_CHECK_VERSION() for version dependent codes). If you don't believe that, have fun rebuilding your glib dependent applications (can you imagine archlinux rebuilding all their glib dependent application when they push a new version...)

The mutex code of glib > 2.41 got rewritten, they seem to do checks if mutex were already locked or not. I have checked sourcery's code and I think the problem is at pygtk level, as a simple call to

Code: Select all

gtk.gdk.threads_init()

Causes a glib assertion failure.

[mimosa]

But the point is, Sourcery works with the version of glib in the 14.1 repos (I just tested it on my system which is fully up to date). Salix is not a rolling release distro. I am sure this won't turn out to be the only thing that is broken by the change. Keeping basic system components the same throughout a release cycle has the advantage of promoting stability.

[Ali82]

Keeping basic system components the same throughout a release cycle has the advantage of promoting stability.

There is absolutely no doubt on this point, this is why I'm moving to Salix.

I'm building local versions keeping the system versions intact (LD_LIBRARY_PATH ?). I came across this problem because my locally compiled version of glib 2.42 got loaded with sourcery instead of the system one. I'm just reporting it here, as a form of problem/bug anticipation. But when I see statements like "a new version of glib2 causes a complete rebuild of everything that depends on it", I just feel that I should reconsider using a distro whose main devs do not really understand what they are talking about...

[mimosa]

whose main devs do not really understand what they are talking about...

I wouldn't be quite so quick to assume that. On the other hand, if that is your eventual conclusion, you could always just use Slackware. It does sound as though you have the necessary skills.

[gapan]

The mutex code of glib > 2.41 got rewritten, they seem to do checks if mutex were already locked or not. I have checked sourcery's code and I think the problem is at pygtk level, as a simple call to

Code: Select all

gtk.gdk.threads_init()

Causes a glib assertion failure.

No, that is not the problem. That is a perfectly valid call. If it doesn't work, your system is broken.

I'm building local versions keeping the system versions intact (LD_LIBRARY_PATH ?).

To me, that reads like "I have no idea what I'm doing and I'm playing around to see what will break".

I came across this problem because my locally compiled version of glib 2.42 got loaded with sourcery instead of the system one. I'm just reporting it here, as a form of problem/bug anticipation.

Again, this is not a problem in sourcery or a problem with glib 2.42 itself. Sourcery works just fine without any changes under slackware-current, which uses glib 2.42. So this is certainly not a problem and will not be a problem for the next release. It might be a problem for people that are trying to break their systems in unpredictable ways that they only pretend to understand.

But when I see statements like "a new version of glib2 causes a complete rebuild of everything that depends on it", I just feel that I should reconsider using a distro whose main devs do not really understand what they are talking about...

Feel free to do anything you like. Statements like yours make me feel that I should reconsider responding to any future issues you might have. After all I don't really understand anything and you know better.