murmur-1.2.2_2 - Segmentation fault

[plankt]

Server version: 1.2.2_2
Client version: 1.2.2

First I did:

portsnap fetch update

I have installed the port:
audio/murmur


When I run it with:
[cmd=]/usr/local/etc/rc.d/murmur start[/Cmd]
It appears on both "top" and "sockstat". My mumble client can detect the servers ping. When I join it I get these messages:

[21:35:50] Connecting to server <Client Lan IP>.
[21:35:50] Server connection failed: The remote host closed the connection.
[21:35:56] Connecting to server <Client Lan IP>.
[21:35:58] Server connection failed: Connection refused.

On server this displays (red is command I entered, green is info):

[color="Red"]./murmurd -ini /usr/local/etc/murmur.ini -v -fg[/color]
Initializing settings from /usr/local/etc/murmur.ini (basepath /usr/local/etc)
Successfully switched to uid 1004
ServerDB: Openend SQLite database /var/db/murmur/murmur.sqlite
Murmur 1.2.2 (1.2.2) running on X11: FreeBSD 8.1-RELEASE: Booting servers
1 => Server listening on 0.0.0.0:64738
[color="Green"](rest comes when I try to connect to it)[/color]
1 => <1:(-1)> New connection: <Client Lan IP>:55075
Segmentation fault

[color="Red"]tail /var/log/messages[/color]
Server kernel: pid 1524 (murmurd), uid 1004: exited on signal 11

UID 1004 is the murmur user.

[color="Red"]tail /var/log/murmur/murmur.log[/color]
Initializing settings from /usr/local/etc/murmur.ini (basepath /usr/local/etc)
ServerDB: Openend SQLite database /var/db/murmur/murmur.sqlite
Murmur 1.2.2 (1.2.2) running on X11: FreeBSD 8.1-RELEASE: Booting servers
1 => Server listening on 0.0.0.0:64738
1 => <1:(-1)> New connection: <Client Lan IP>:55207

My murmur.ini

database=/var/db/murmur/murmur.sqlite
logfile=/var/log/murmur/murmur.log
pidfile=/var/run/murmur/murmur.pid
welcometext="Welcome"
port=64738
uname=murmur
Ice.Warn.UnknownProperties=1
Ice.MessageSizeMax=65536

 

[fwaggle]

Grave-digging here, but 1.2.3 will still do this so I figured I would post here for posterity's sake (in case someone is Googling for the same problem):

Do you have security/openssl installed? If so, that's likely the culprit. QT's QSslSocket stuff is apparently broken on FreeBSD when you have both ports and base version installed - I tried to report the bug to the mailing list, but wasn't subscribed and missed the follow up.

If you have security/openssl installed, and build audio/murmur it will build from the ports version just fine. However when it goes to run, I gather that ld dynamically loads stuff from ports first, but when QT itself goes to load the ssl bits for QSslSocket, for some reason it grabbed /usr/lib/libssl.so instead (checked via ktrace).

Uninstalling the OpenSSL port isn't an option at the moment, because QSslSocket has a nasty DoS in it that's only mitigated by OpenSSL 0.9.8o+, and IIRC every current version of FreeBSD has revision n in base, and 1.0.0-something in ports.

The solution IIRC (I'm going through it right now so I will update if I'm wrong) is to rename /usr/lib/libssl.so so it's not found, and then rebuild net/qt4-network (probably require rebuilding all of QT, because packages for 8.2-R at least are all 4.6.3 and ports is 4.7.2), then rebuild audio/murmur.

 

[mamalos]

fwaggle,

I would be careful when renaming libssl from base system. Many programs are built with its support. Nevertheless, I don't think you need to rebuild your system in order to call the /usr/local/lib version of this library. If you rename it and run ldconfig to update its cache, I think you'll do the trick.

 

[fwaggle]

fwaggle,

I would be careful when renaming libssl from base system. Many programs are build with its support.

Everything else seems to function fine with just the .so file renamed (I think most everything else willy happily pick up the ports version). I leave .a and the specific versions (if they're there), and I was originally worried when I tried it on a virtual machine, but nothing appears to break.

It seems to be just QT that barfs on it, I have no idea why QT's own runtime loader doesn't appear to have a sane search path order.

Nevertheless, I don't think you need to rebuild your system in order to call the /usr/local/lib version of this library. If you rename it and run ldconfig to update its cache, I think you'll do the trick.

I'll give it another shot, but I'm pretty sure unless I rebuilt net/qt4-network I got "no usable ciphers"... I chalked it up to the ABI for ciphers changing from 0.9.8 to 1.0.0, but of course I have no evidence of this (and come to think of it, it really doesn't make much sense now).