Can't send() int to the server / Can't receive value from the server

Hi,

MOC is dying at startup (first run) with either Can't send() int to the server or Can't receive value from the server. I saw similar thread earlier in forum, but suggestion given there doesn't help.

moc 2.4.1 Build: Dec 19 2006 23:52:02
Compiled with: OSS DEBUG

configure flags:
--mandir=/usr/local/man --without-jack --without-ffmpeg --without-speex --without-samplerate --without-curl --prefix=/usr/local amd64-portbld-freebsd7.0

CFLAGS=-g -pipe

running on FreeBSD 7.0-CURRENT/amd64

> mocp -D -S -F
Loading plugins from /usr/local/lib/moc/decoder_plugins...
Loading plugin libflac_decoder...
OK
Loading plugin libmp3_decoder...
OK
Loading plugin libmusepack_decoder...
OK
Loading plugin libsndfile_formats_decoder...
OK
Loading plugin libvorbis_decoder...
OK
Trying OSS...
Dec 20 00:26:57.43386: oss.c:58 open_dev(): Audio device opened
Dec 20 00:26:57.50855: oss.c:58 open_dev(): Audio device opened
Dec 20 00:26:57.53056: audio.c:848 print_output_capabilities(): Sound driver capabilities: channels 1 - 2, formats: 8-bit signed, 8-bit unsigned, 16-bit signed little-endian (native)
Dec 20 00:26:57.60395: tags_cache.c:538 tags_cache_load(): Loading tags cache from /home/yuri/.moc/tags_cache...
Dec 20 00:26:57.60577: tags_cache.c:653 tags_cache_load(): Loaded 0 items to the cache
Dec 20 00:26:57.60917: server.c:1215 server_loop(): MOC server started, pid: 91835
Dec 20 00:26:57.61004: out_buf.c:66 read_thread(): entering output buffer thread
Dec 20 00:26:57.61086: tags_cache.c:297 reader_thread(): tags reader thread started
Dec 20 00:26:57.61120: tags_cache.c:319 reader_thread(): all queues empty, waiting
Dec 20 00:27:05.507124: server.c:1241 server_loop(): accept()ing connection...
Dec 20 00:27:05.507218: server.c:1249 server_loop(): Incoming connection
Dec 20 00:27:05.507245: tags_cache.c:453 tags_cache_clear_queue(): Cleared requests queue for client 0
Dec 20 00:27:05.512770: server.c:848 gen_serial(): Generated serial 0 for client with fd 7
Dec 20 00:27:05.563067: server.c:1067 handle_command(): Request for events
Dec 20 00:27:05.564265: server.c:639 get_client_plist(): Client with fd 7 requests the playlist.
Dec 20 00:27:05.564296: server.c:649 get_client_plist(): No clients with the playlist.
Dec 20 00:27:05.588520: server.c:1140 handle_command(): Closing client connection due to error.
Dec 20 00:27:05.588589: tags_cache.c:453 tags_cache_clear_queue(): Cleared requests queue for client 0

from mocp_client_log (mocp -D):
Dec 20 00:27:05.508571: interface.c:1380 init_interface(): Starting MOC interface...
Dec 20 00:27:05.513167: utf8.c:310 utf8_init(): Using UTF8 output
Dec 20 00:27:05.561068: interface.c:439 update_mixer_name(): Mixer name: pcm
Dec 20 00:27:05.563642: interface.c:1256 get_server_playlist(): Getting the playlist...
Dec 20 00:27:05.563745: interface.c:855 recv_server_plist(): Asking server for the playlist from other client.
Dec 20 00:27:05.564390: interface.c:857 recv_server_plist(): Waiting for response
Dec 20 00:27:05.564601: interface.c:861 recv_server_plist(): There is no playlist
Dec 20 00:27:05.595407: protocol.c:103 send_int(): send() failed: Broken pipe
Dec 20 00:27:05.595878: common.c:55 fatal(): FATAL ERROR: Can't send() int to the server.

The server probably did segmentation fault and there should be a core file. Unfortunately I don't have a FreeBSD box to debug that. You can past here a backtrace (as described here: http://moc.daper.net/node/96), but I can't promise any solution.

--
Damian Pietras - MOC developer

Sorry, forgot about it. Actually there's no segfault after those messages. It can be triggered when server is run in foreground pressing ^C.

(gdb) info thr
* 3 LWP 100122 0x0000000800b03abc in kse_thr_interrupt () at kse_thr_interrupt.S:2
2 Thread 0x801250400 (runnable) 0x0000000000000000 in ?? ()
1 Thread 0x801250800 (LWP 100101) 0x0000000800b03a7c in kse_release () at kse_release.S:2
(gdb) thr 1
[Switching to thread 1 (Thread 0x801250800 (LWP 100101))]#0 0x0000000800b03a7c in kse_release () at kse_release.S:2
2 RSYSCALL(kse_release)
(gdb) bt
#0 0x0000000800b03a7c in kse_release () at kse_release.S:2
#1 0x0000000800ae986a in sig_daemon (arg=0x0) at /data/src/lib/libpthread/thread/thr_sig.c:214
#2 0x0000000800af7d1e in kse_sched_single (kmbx=0x801230268) at /data/src/lib/libpthread/thread/thr_kern.c:886
#3 0x0000000000000000 in ?? ()
Cannot access memory at address 0x7fffffbff000
(gdb) thr 2
[Switching to thread 2 (Thread 0x801250400 (runnable))]#0 0x0000000000000000 in ?? ()
(gdb) bt
#0 0x0000000000000000 in ?? ()
#1 0x0000000801f14596 in __do_global_dtors_aux () from /usr/local/lib/libmpcdec.so.4
#2 0x0000000801f20451 in _fini () from /usr/local/lib/libmpcdec.so.4
#3 0x00007fffffffe140 in ?? ()
#4 0x0000000800553776 in objlist_call_fini (list=0x80067c510) at /data/src/libexec/rtld-elf/rtld.c:1381
#5 0x0000000800553fec in dlclose (handle=0x800588000) at /data/src/libexec/rtld-elf/rtld.c:1691
#6 0x000000000042f820 in sys_dl_close (loader_data=0x0, module=0x800588000) at ltdl.c:1124
#7 0x0000000000432d34 in lt_dlclose (handle=0x801290940) at ltdl.c:3808
#8 0x00000000004312a1 in unload_deplibs (handle=0x801290400) at ltdl.c:2979
#9 0x0000000000432d45 in lt_dlclose (handle=0x801290400) at ltdl.c:3809
#10 0x000000000042ffb5 in lt_dlexit () at ltdl.c:2325
#11 0x0000000000414d69 in decoder_cleanup () at decoder.c:230
#12 0x000000000040db82 in start_moc (params=0x7fffffffe320, args=0x7fffffffe798, arg_num=0) at main.c:219
#13 0x000000000040e45b in main (argc=4, argv=0x7fffffffe778) at main.c:548
(gdb) thr 3
[Switching to thread 3 (LWP 100122)]#0 0x0000000800b03a7c in kse_release () at kse_release.S:2
2 RSYSCALL(kse_release)
(gdb) bt
#0 0x0000000800b03a7c in kse_release () at kse_release.S:2
#1 0x0000000800ae986a in sig_daemon (arg=0x0) at /data/src/lib/libpthread/thread/thr_sig.c:214
#2 0x0000000800af7d1e in kse_sched_single (kmbx=0x801230268) at /data/src/lib/libpthread/thread/thr_kern.c:886
#3 0x0000000000000000 in ?? ()
Cannot access memory at address 0x7fffffbff000

Thanks anyway.

This trace looks like a known bug (crash on exit if the musepack plugin is compiled in) and I think it's not related to your crash at startup.

--
Damian Pietras - MOC developer

I can give you ssh access to machine in question, if it can be of any help.