** Changed in: xvidcap (Ubuntu)
Status: New => Fix Released
--
get libpthread assertion on multicore CPU
https://bugs.launchpad.net/bugs/60708
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bug
Since this is no longer a glibc task, the whole purpose of this bug has
gone. After finding the exact conditions in glib to cause this, xvidcap
has avoided the problem for ages and not displayed this anymore. Should
be safe to close.
--
get libpthread assertion on multicore CPU
https://bugs.launc
** Bug watch added: SourceForge.net Tracker #1551015
http://sourceforge.net/support/tracker.php?aid=1551015
** Also affects: xvidcap via
http://sourceforge.net/support/tracker.php?aid=1551015
Importance: Unknown
Status: Unknown
--
get libpthread assertion on multicore CPU
https:/
closing the glibc task, opening a xvidcap task; please could you check
for the fix in the current development version (feisty)?
** Changed in: glibc (Ubuntu)
Status: Unconfirmed => Rejected
--
get libpthread assertion on multicore CPU
https://launchpad.net/bugs/60708
--
ubuntu-bugs mai
before taking this to the gnome folks I was trying rule out a connection
between glibc and the above mentioned gcc bug by recompiling glibc with gcc 3.4
(because __generic_mutex_lock DOES use some inline asm code and could match the
gcc bug).
However, that seems to be beyond my current skills. A
recompiling libglib2.0-0 with gcc 3.4 does not solve the issue and the crashes
keep coming up in g_idle_add().
Dunno if http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29415 means that this is a
question of what compiler glibc was compiled with?
Maybe it is a libglib thing?
--
get libpthread assert
get the same error on edgy and here it's more dramatic because LinuxThreads
support appears to be gone.
Some more research brings up glibc bug # 3328
http://sources.redhat.com/bugzilla/show_bug.cgi?id=3328
that one was rejected and points to gcc bug # 29415
http://gcc.gnu.org/bugzilla/show_bug.cg
since you were saying in bug # 60711:
"where they're assuming some behaviour of LinuxThreads rather than relying on
POSIX semantics. The design of NPTL is radically different: All the internal
opaque structures are different, it uses Thread Local Storage, etc. The only
guarantees for compatabili
Hello Jeff,
you don't need any special equipment for xvidcap. You might want to try current
svn trunk, though, and do the usual "./autogen.sh && debian/rules binary"
As for the platforms I've been talking about: Well, since the effect seemed
different on various platforms we've tested some:
AMD3
It seems like you've tripped across a bug in NPTL. From the other bug
you filed, though, I'm confused about which architecture you're doing
this on. Is it i386 or amd64?
Do I need special equipment to work with xvidcap? It would be useful if
I could run this locally to see the bug, but I don't
ref.
http://sourceforge.net/tracker/index.php?func=detail&aid=1551015&group_id=81535&atid=563254
--
get libpthread assertion on multicore CPU
https://launchpad.net/bugs/60708
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
oh and I forgot to mention that this is on dapper
--
get libpthread assertion on multicore CPU
https://launchpad.net/bugs/60708
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
issue # 60711 prevents the use of LD_ASSUME_KERNEL in a 64 bit
environment on AMD64
--
get libpthread assertion on multicore CPU
https://launchpad.net/bugs/60708
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
13 matches
Mail list logo
