Assertion failed: (false), function pluginThreadEntry #18

Closed
yermulnik opened this Issue Dec 20, 2011 · 3 comments

Comments

Projects
None yet
3 participants
@yermulnik

Yesterday I rebuilt my Licq 1.5.1 and it cannot start now:
Assertion failed: (false), function pluginThreadEntry, file /usr/ports/WORK/usr/ports/n
et-im/licq/work/licq-1.5.1/src/plugins/pluginthread.cpp, line 84.

Unfortunately, there's now gdb output:
Using gdb to save backtrace to /home/yz/.licq/licq.backtrace.gdb
Assertion failed: (false), function pluginThreadEntry, file /usr/ports/WORK/usr/ports/n
et-im/licq/work/licq-1.5.1/src/plugins/pluginthread.cpp, line 84.
/usr/src/gnu/usr.bin/gdb/libgdb/../../../../contrib/gdb/gdb/solib-svr4.c:1443: internal
-error: legacy_fetch_link_map_offsets called without legacy link_map support enabled.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) n

Tracing with gdb (gdb /usr/local/bin/licq) shows:
(gdb) run
Starting program: /usr/local/bin/licq
<skipped "(no debugging symbols found)..." lines>
[New Thread 28801140 (LWP 100234/initial thread)]
[New Thread 28850140 (LWP 100293/licq)]
[New Thread 2884fec0 (LWP 100294/licq)]
<skipped "(no debugging symbols found)..." lines>
[New Thread 2884fd80 (LWP 100295/licq)]
Assertion failed: (false), function pluginThreadEntry, file /usr/ports/WORK/usr/ports/net-im/licq/work/licq-1.5.1/src/plugins/pluginthread.cpp, line 84.

Program received signal SIGABRT, Aborted.
[Switching to Thread 2884fd80 (LWP 100295/licq)]
0x286e64ab in thr_kill () from /lib/libc.so.7
(gdb) The program is running. Exit anyway? (y or n) y

11:24:37 [yz@yz][~]> uname -srm
FreeBSD 8.2-STABLE i386

What could cause this error and what can I do to make Licq work?

Thanx in advance for help.

@erijo

This comment has been minimized.

Show comment
Hide comment
@erijo

erijo Dec 20, 2011

Member

A very strange problem. Is it possible for you to test version 1.6.0?

Member

erijo commented Dec 20, 2011

A very strange problem. Is it possible for you to test version 1.6.0?

@yermulnik

This comment has been minimized.

Show comment
Hide comment
@yermulnik

yermulnik Dec 20, 2011

Unfortunately, there's no version 1.6.0 in FreeBSD's ports tree =( And, probably, I won't be able to build without FreeBSD specific patches.
I've found the same problem you had participated a year ago, but there where no thread continuation:
http://www.mail-archive.com/licq-dev@googlegroups.com/msg00970.html

I suspect that the problem could be caused by some library or dependency update made recently on my sendbox. But I can't imagine which of them exactly it is.

Unfortunately, there's no version 1.6.0 in FreeBSD's ports tree =( And, probably, I won't be able to build without FreeBSD specific patches.
I've found the same problem you had participated a year ago, but there where no thread continuation:
http://www.mail-archive.com/licq-dev@googlegroups.com/msg00970.html

I suspect that the problem could be caused by some library or dependency update made recently on my sendbox. But I can't imagine which of them exactly it is.

erijo added a commit that referenced this issue Dec 20, 2011

Re-evaluate predicate after returning from condition wait
This is needed because pthread_cond_wait() can wake up for no apparent reason
(i.e. not due to a call to pthread_cond_signal() or
pthread_cond_broadcast()). See [1]. Should hopefully solve #18.

[1] - http://lists.freebsd.org/pipermail/freebsd-hackers/2011-February/034573.html
@flynd

This comment has been minimized.

Show comment
Hide comment
@flynd

flynd Dec 21, 2011

Member

Confirmed via mail that 2f25b63 solves it.

Member

flynd commented Dec 21, 2011

Confirmed via mail that 2f25b63 solves it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment