MOC 2.4.0 crashes on FreeBSD 5.5

Submitted by jdevelop on Fri, 2006-05-12 13:28

Forums:

0x283b2373 in pthread_testcancel () from /usr/lib/libpthread.so.1
(gdb) bt
#0 0x283b2373 in pthread_testcancel () from /usr/lib/libpthread.so.1
#1 0x283a3171 in sigaction () from /usr/lib/libpthread.so.1
#2 0x2839d1f5 in pthread_kill () from /usr/lib/libpthread.so.1
#3 0x2839cbc4 in raise () from /usr/lib/libpthread.so.1
#4 0x2846fcef in abort () from /lib/libc.so.5
#5 0x28449c4f in __assert () from /lib/libc.so.5
#6 0x08056675 in out_buf_time_get ()
#7 0x08057d71 in audio_get_time ()
#8 0x0806aa6b in options_get_str ()
#9 0x0806b1c5 in player_init ()
#10 0x08055d9a in fifo_buf_clear ()
#11 0x2839eb09 in pthread_create () from /usr/lib/libpthread.so.1
#12 0x2845b327 in _ctx_start () from /lib/libc.so.5

daper

Sat, 2006-05-13 07:38

Thanks, I don't have a solution now.

--
Damian Pietras - MOC developer

jdevelop

Wed, 2006-05-17 15:46

Okay, on most songs MOC works fine, but on some it doesn't
I can live with this for sure, just it would be nice if this weird issue will be fixed somewhen ;)

Thanks!

jcf

Wed, 2014-08-13 01:52

I have today committed to SVN r2656 which fixes this bug.

It turns out the assertion being triggered is not valid as a negative time value may arise legitimately if the hardware buffer still contains more samples from the previous file than have been decoded from the next file. This situation is now handled appropriately.