** Changed in: sun-java6 (Ubuntu Hardy)
Status: In Progress => Won't Fix
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/87947
Title:
xcb_xlib.c:50: xcb_xlib_unlock: Assertion `c->xlib.lock' fa
Sorry, I had meant to post the above on the end of #185311.
--
xcb_xlib.c:50: xcb_xlib_unlock: Assertion `c->xlib.lock' failed.
https://bugs.launchpad.net/bugs/87947
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing
Hiya -
Just to confirm, the noxcb deb files above allowed python-pyxine to work
properly on hardy, where previously it had suffered a hard lockup just
after creating the display visual object and spawning the X event
thread.
I would certainly like to have this module working on a long-term
supp
charly4711: We can't provide both versions of libX11 because it would
almost certainly result in two copies of libX11 (one with XCB and one
without) sometimes being loaded into the one process depending on the
exact transitive library linkage involved, which would cause chaos and
crashes. We can't
fixed in 6-07 in intrepid
** Changed in: sun-java6 (Ubuntu)
Status: Won't Fix => Fix Released
** Changed in: libx11 (Ubuntu Hardy)
Status: New => Invalid
** Changed in: libxcb (Ubuntu Hardy)
Status: New => Invalid
** Changed in: sun-java6 (Ubuntu Hardy)
Status: New =
"Why can't we just remove the XCB infection/bridge layer from libX11 and
revert it to the stock libX11 module? Let old libX11 programs use that,
and new ones use XCB."
Far as I understand the issue, it is because some apps (e. g. compiz) don't
work without.
I think the ideal short term solution f
I neither understand why this bug is declined for the Long Term Support
"hardy" release
Does that mean I have to update to an "intermediate" yet unreleased version ?
Thanks
Chris
--
xcb_xlib.c:50: xcb_xlib_unlock: Assertion `c->xlib.lock' failed.
https://bugs.launchpad.net/bugs/87947
You
Sorry, I meant to say "unusably slow". TCP/X11 transport of Matlab and
other Java applications are unusably slow even with all the hacks and
updates applied.
--
xcb_xlib.c:50: xcb_xlib_unlock: Assertion `c->xlib.lock' failed.
https://bugs.launchpad.net/bugs/87947
You received this bug notificatio
I still get issues when running MATLAB r2008 under Hard (32-bit and 64-bit).
I've tried the sed thing, the SLOPPY_LOCK export and have all the updates
installed as of today.
Basically, matlab over UNIX sockets (the default, DISPLAY=:0.0) seems
fine, but over TCP sockets (DISPLAY=localhost:0) is
Why was this declined for hardy between it and bug 185311 it is
apparently causing lots of crashes on OpenOffice.org.
Thanks,
Chris Cheney
--
xcb_xlib.c:50: xcb_xlib_unlock: Assertion `c->xlib.lock' failed.
https://bugs.launchpad.net/bugs/87947
You received this bug notification because you are
Thanks for testing! The handoff patches are based on libxcb git commit
7a74ba3d0212f9bfe021d6da9070f71cbc53f85b and libX11 git commit
64325f38bab082a8e0e9ce779a8e582de5c8588e. It'll probably apply against
newer versions of libX11, but there's been a lot of work in libxcb since
we started trying to
Jamey, I would be more than willing to test the socket handoff patches,
but I cannot get the patches to apply well. If I checkout current git
and do git-apply --check --summary, only the first patch does not yield
any problems. I suppose I need to check out a specific revision of
libxcb? If you cou
The (first) error message is expected when LIBXCB_ALLOW_SLOPPY_LOCK=1 is
enabled.
As long as your app isn't crashing, you can safely ignore the error,
since your app doesn't mix xlib and xcb.
The long term solution should be "socket handoff," but I don't think
that will hit hardy:
http://lists.fr
I can confirm that, running matlab on current Hardy, with libxcb1
(1.1-1ubuntu1) gives the following :
[EMAIL PROTECTED]:~$ /opt/matlab/bin/matlab
Locking assertion failure. Backtrace:
#0 /usr/lib/libxcb-xlib.so.0 [0xb5aee767]
#1 /usr/lib/libxcb-xlib.so.0(xcb_xlib_unlock+0x31) [0xb5aee8b1]
#2 /us
here on latest hardy x86_64 with installed libxcb1 (1.1-1ubuntu1)
installed. i still get the following error when starting tomcat from
within eclipse:
Locking assertion failure. Backtrace:
#0 /usr/lib/libxcb-xlib.so.0 [0x7f8d779f497c]
#1 /usr/lib/libxcb-xlib.so.0(xcb_xlib_unlock+0x24) [0x7f8d779f
I am trying to install VP-UML for eclipse. I tried all proposed workarounds and
none worked. tried the
export LIBXCB_ALLOW_SLOPPY_LOCK=1
same result.
tried sed command, but apparently the installer packs its own version of
libmawt.so
Locking assertion failure. Backtrace:
#0 /usr/lib/libxcb-xli
Josh and I just proposed a set of changes to XCB and Xlib/XCB which,
among other things, should address all the outstanding assertion
failures and synchronization problems that we know of. Could anyone
experiencing this bug please build XCB and Xlib with the patches found
at http://lists.freedeskt
This bug was fixed in the package libxcb - 1.1-1ubuntu1
---
libxcb (1.1-1ubuntu1) hardy; urgency=low
* Add 100_sloppy_lock.diff, which reverses the locking logic, ie. sloppy
locking is the default. To disable that, set the environment variable
LIBXCB_DISABLE_SLOPPY_LOCK to a
@drdabbles: It is sounds easier for me to use export instead of replacing a
string in a binary file. You don't have to use export from the CLI every time.
Just put it into your .bashrc or add the variable to /etc/environment.
I guess sloppy locking refers to some locking method, and not to sloppy
drbabbles,
A better workaround is to add a line "LIBXCB_ALLOW_SLOPPY_LOCK=1" to
/etc/environment.
Regarding, your first comment, we can have our cake and eat it too.
Just because we don't gratuitously crash applications doesn't mean we
can't fix the underlying problems. A lot of extensions were
If I understand the original Debian thread correctly, this arises when
someone writes sloppy code, no? Sloppy code should be fixed, instead of
allowing broken behavior in the libraries...IMHO. Still, the closed-
source java annoys me in that only Sun can fix the problem.
Is a fix forthcoming in li
Found a workaround on the Gentoo forums and adapted it to Ubuntu's
locations.
NOTE: Newcomers...do NOT run this command. If you don't understand
exactly what is going on, NEVER run a command you find online.
locate libmawt.so | grep "/usr/lib/jvm/java-6.*/lib/i386/.*libmawt.so" |
xargs sudo sed -
The patch was in fact needed for libxcb.
** Changed in: libxcb (Ubuntu)
Importance: Undecided => High
Status: Invalid => Fix Committed
** Changed in: libx11 (Ubuntu)
Status: Triaged => Fix Released
--
xcb_xlib.c:50: xcb_xlib_unlock: Assertion `c->xlib.lock' failed.
https://bugs
I agree with Tom Jaegar.
Currently common Java GUI applications simply crash on Hardy.
For a newcomer this is equivalent to "Java does not work on Ubuntu", that
sounds especially bad for an LTS distro.
--
xcb_xlib.c:50: xcb_xlib_unlock: Assertion `c->xlib.lock' failed.
https://bugs.launchpad.ne
Timo, please revert to sloppy locking and let that be the end of it.
The current situation makes no sense at all: Having applications crash
because of a _recoverable_ error is just stupid. It seems like an
extremely dickish move by the xcb developers (or whoever is responsible
for this insanity)
Hello,
Many people here in Norway (who run Hardy Alpha6) cannot login to their
internet bank or do any other internet transactions because the
Firefox's Java-plugin does not work. The security and login system is
called BankID applet and it requires Sun's Java5/6 (or possibly later)
plugin and Ja
We are experiencing the same issue as we prepare for our migration to
Hardy. Java 5/6 is a requirement for us so I'm anxious to see a
resolution to this.
Are you saying that the same work-around used in Gutsy for Java 5/6 will
be available in Hardy? Or are you saying if someone makes the fixes t
I tried to link to the upstream report:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6532373c bug
launchpad doesn't know about sun's bug database (yet).
--
xcb_xlib.c:50: xcb_xlib_unlock: Assertion `c->xlib.lock' failed.
https://bugs.launchpad.net/bugs/87947
You received this bug notificati
Sun will not fix java5/6, but it has already been fixed in icedtea and
the upcoming java7. AFAIK there would be no issues if libx11 defaults to
sloppy locks, so it should be doable.
** Changed in: sun-java6 (Ubuntu)
Status: Triaged => Won't Fix
** Changed in: libx11 (Ubuntu)
Importance:
Please change default to sloppy locks. There are a lot of binary java
apps, that need older versions of java (1.3.1 or 1.4.2) and most users
will encounter this problem. I know it's not the prefered solution, but
it's easy enough to satisfy a lot of people.
--
xcb_xlib.c:50: xcb_xlib_unlock: Asse
No need to confirm, it's well known. We can't fix old java's though, so
either the locking behaviour needs to be changed so that it allows
sloppy locks by default.
** Changed in: sun-java6 (Ubuntu)
Status: New => Triaged
--
xcb_xlib.c:50: xcb_xlib_unlock: Assertion `c->xlib.lock' failed.
I can confirm this bug for hardy alpha 5
~~~
$ java -jar GoogleVideoUploader.jar
Locking assertion failure. Backtrace:
#0 /usr/lib/libxcb-xlib.so.0 [0x7f9c5192c97c]
#1 /usr/lib/libxcb-xlib.so.0(xcb_xlib_unlock+0x24) [0x7f9c5192ca84]
#2 /usr/lib/libX11.so.6(_XReply+0x10f) [0x7f9c5218b14f]
#3 /us
This is a regression in hardy. Nearly all graphical java programs will
fail due to this. Early releases of gutsy had this problem but it was
fixed before the release such that a default installation of gutsy did
not experience the problem for java programs. Yes, technically it's a
bug in Java, but
Hi,
this problem is also affecting other programs in Hardy.
For example the Citrix ICA Client needs the same work around
export LIBXCB_ALLOW_SLOPPY_LOCK=1
--
xcb_xlib.c:50: xcb_xlib_unlock: Assertion `c->xlib.lock' failed.
https://bugs.launchpad.net/bugs/87947
You received this bug notification b
For sun-java5-bin:
sed -i 's/XINERAMA/FAKEEXTN/g'
/opt/sun-jdk-1.5.0.12/jre/lib/i386/xawt/libmawt.so
For sun-java6-bin:
sed -i 's/XINERAMA/FAKEEXTN/g'
/opt/sun-jdk-1.6.0.02/jre/lib/i386/xawt/libmawt.so
The same fix (applied to the appropriate file) might work for other
proprietary JDKs.
On Ja
hasan: it's a bug in java, so you need to use
'LIBXCB_ALLOW_SLOPPY_LOCK=1 $prog'. To "fix" java on your system, look
at /usr/share/doc/libx11-6/NEWS.Debian.gz. Due to licensing issues that
change cannot be done on the java packages.
--
xcb_xlib.c:50: xcb_xlib_unlock: Assertion `c->xlib.lock' fail
I do not think this bug has been satisfactorily fixed. Whenever I try to
run Matlab or other java dependent applications such as jconsole I get
the following error message:
xcb_xlib.c:82: xcb_xlib_unlock: Assertion `c->xlib.lock' failed.
Steps to reproduce bug:
Install sun-java6-jdk
Run
$ jcons
Hardy now has 1.1.3, marking as fixed.
** Changed in: libxcb (Ubuntu)
Assignee: Daniel T Chen (crimsun) => (unassigned)
** Changed in: libx11 (Ubuntu)
Status: Confirmed => Fix Released
--
xcb_xlib.c:50: xcb_xlib_unlock: Assertion `c->xlib.lock' failed.
https://bugs.launchpad.net/bug
Currently the plan is to enable xcb for Hardy Heron. Sun has
acknowledged the problem in their java, and it's hopefully fixed soon.
** Changed in: libx11 (Ubuntu)
Importance: Undecided => Medium
--
xcb_xlib.c:50: xcb_xlib_unlock: Assertion `c->xlib.lock' failed.
https://bugs.launchpad.net/bug
** Changed in: libx11 (Debian)
Status: Confirmed => Fix Released
--
xcb_xlib.c:50: xcb_xlib_unlock: Assertion `c->xlib.lock' failed.
https://bugs.launchpad.net/bugs/87947
You received this bug notification because you are a member of Ubuntu
Bugs, which is the bug contact for Ubuntu.
--
u
** Changed in: libx11 (Debian)
Status: Unknown => Confirmed
--
xcb_xlib.c:50: xcb_xlib_unlock: Assertion `c->xlib.lock' failed.
https://bugs.launchpad.net/bugs/87947
You received this bug notification because you are a member of Ubuntu
Bugs, which is the bug contact for Ubuntu.
--
ubuntu
I believe this bug is now fixed in upstream libX11 git.
http://gitweb.freedesktop.org/?p=xorg/lib/libX11.git;a=commitdiff;h=c2f88cdf5cd9c94b77e5bfdac572b5ac06ab4aa8
** Changed in: libx11 (Debian)
Sourcepackagename: libxcb => libx11
Bugwatch: Debian Bug tracker #401571 => Debian Bug tracker #4
Per the debian-devel-announce message, please make sure your X libraries
are up to date. If you can still reproduce the problem, can you supply a
backtrace?
--
xcb_xlib.c:50: xcb_xlib_unlock: Assertion `c->xlib.lock' failed.
https://bugs.launchpad.net/bugs/87947
You received this bug notification
See bug 87390; a workaround is in place in Feisty's current package,
allowing apps to work. Said workaround will be dropped when Feisty+1
opens.
** Changed in: libxcb (Ubuntu)
Assignee: (unassigned) => Daniel T Chen
Status: Unconfirmed => Rejected
--
xcb_xlib.c:50: xcb_xlib_unlock: A
** Changed in: libxcb (Debian)
Status: Unknown => Unconfirmed
--
xcb_xlib.c:50: xcb_xlib_unlock: Assertion `c->xlib.lock' failed.
https://launchpad.net/bugs/87947
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
more information on
http://lists.debian.org/debian-devel-announce/2006/11/msg00010.html
fcitx's version:
ii fcitx 3.4-1 Free Chinese Input Toy
for X (XIM)
--
xcb_xlib.c:50: xcb_xlib_unlock: Assertion `c->xlib.lock' failed.
https://launchpad.net/bugs/8794
46 matches
Mail list logo
