Apologies, my mistake. I was running the new executable locally but it was still pulling the old libfluidsynth. The problem is indeed fixed with the new version.
Many thanks for your help! Regards, Mark At 12:39 on 19 Jan 2015, Element Green wrote: >Are you sure you don't still have another libfluidsynth hanging around >on your system? That was the problem I had at first when testing this >change. So do a 'which fluidsynth' to find out where the executable >is and then do ldd `which fluidsynth` to see which libfluidsynth it is >pulling in and that it is indeed what you just built from git. > >The original reported issue was also affecting my Ubuntu 14.10 64 bit >system, but this fixed it for me. > >Best regards, > >Element Green > >On Mon, Jan 19, 2015 at 11:44 AM, Mark Knoop <m...@opus11.net> wrote: > >> Thanks for your help. I've pulled this from git and built, however I >> still see the same behaviour. Attempting to debug it now, I see lots >> of logging references in the code such as >> >> FLUID_LOG (FLUID_DBG, "New client connection"); >> >> but it's not immediately apparent where these logging messages go, or >> how to turn logging on. Is there a make or cmake variable that >> triggers this? >> >> At 10:17 on 19 Jan 2015, Element Green wrote: >> >Hello Mark, >> > >> >Thank you for reporting this. Looks like it was an issue >> >with fluid_server_handle_connection() not having a return value, >> >which meant undefined behavior, since the return value was getting >> >checked for a success value in fluid_server_socket_run(), but the >> >return value was not getting properly assigned. So this probably >> >worked on some systems and not others. >> > >> >I checked in a fix for this into the git repository. >> > >> >Best regards, >> > >> >Element Green >> > >> >On Mon, Jan 19, 2015 at 9:35 AM, Mark Knoop <m...@opus11.net> wrote: >> > >> >> Hi Element, >> >> >> >> Thanks for your reply. >> >> >> >> >When I encounter network related issues like that, it can >> >> >sometimes be helpful to get a network traffic capture with an >> >> >application like Wireshark. When testing connections to >> >> >FluidSynth you'd want to capture on the lo loop back interface. >> >> >> >> Wireshark shows the TCP handshake establishing the connection, >> >> then fluidsynth immediately sends FIN-ACK. See attached capture >> >> file. >> >> >> >> >I'd also check to make sure >> >> >you don't have any firewall rules enabled which would be causing >> >> >this. It might be worth doing a quick test using netcat to >> >> >create a TCP/IP server on the same port 9800 and see if it >> >> >works, to rule out any system related causes of port 9800 being >> >> >blocked. >> >> >> >> Netcat server on 9800 works with no problem. >> >> >> >> >Also, are you using the default Fedora package for FluidSynth or >> >> >are you building from source? If you try building from source, >> >> >does the issue also occur. >> >> >> >> Have tried both with the same results. >> >> >> >> >If I was still having issues, I'd start delving into debugging >> >> >FluidSynth. For example, setting a breakpoint on >> >> >fluid_server_handle_connection() to see if that callback is >> >> >getting called when an incoming connection occurs. Or checking >> >> >to see if fluid_istream_readline() gets called, which handles >> >> >shell input and see if it is returning any values which would >> >> >cause a disconnect. >> >> >> >> I'll try these suggestions when I have a chance, thanks. >> >> >> >> Regards, >> >> >> >> Mark >> >> >> >> >Hopefully that is helpful in figuring out what is going on. >> >> > >> >> >Best regards, >> >> > >> >> >Element Green >> >> > >> >> > >> >> >On Mon, Jan 19, 2015 at 2:59 AM, Mark Knoop <m...@opus11.net> >> >> >wrote: >> >> > >> >> >> Hi list, >> >> >> >> >> >> I'm having a problem on Fedora 21 where fluidsynth rejects any >> >> >> server connection. This always worked without problems on >> >> >> Fedora 20 and earlier which leads me to suspect that it might >> >> >> be related to some distro change or update (e.g. compiler >> >> >> version). >> >> >> >> >> >> Has anyone experienced anything similar? I could use some >> >> >> suggestions as to how to debug this. I have tried building from >> >> >> git source (master) and get the same result. >> >> >> >> >> >> Thanks for any help. >> >> >> >> >> >> $ fluidsynth -lsi -apulseaudio & >> >> >> [1] 18386 >> >> >> FluidSynth version 1.1.6 >> >> >> Copyright (C) 2000-2012 Peter Hanappe and others. >> >> >> Distributed under the LGPL license. >> >> >> SoundFont(R) is a registered trademark of E-mu Systems, Inc. >> >> >> >> >> >> fluidsynth: Using PulseAudio driver >> >> >> >> >> >> $ telnet 127.0.0.1 9800 >> >> >> Trying 127.0.0.1... >> >> >> Connected to localhost. >> >> >> Escape character is '^]'. >> >> >> Connection closed by foreign host. >> >> >> >> >> >> $ echo fonts | nc 127.0.0.1 9800 >> >> >> Ncat: Connection reset by peer. >> >> >> >> >> >> https://bugzilla.redhat.com/show_bug.cgi?id=1183328 >> >> >> >> >> >> -- >> >> >> Mark Knoop >> >> >> >> >> >> _______________________________________________ >> >> >> fluid-dev mailing list >> >> >> fluid-dev@nongnu.org >> >> >> https://lists.nongnu.org/mailman/listinfo/fluid-dev >> >> >> >> >> >> >> >> >> -- >> >> Mark Knoop >> >> >> >> _______________________________________________ >> >> fluid-dev mailing list >> >> fluid-dev@nongnu.org >> >> https://lists.nongnu.org/mailman/listinfo/fluid-dev >> >> >> >> >> >> >> -- >> Mark Knoop >> >> _______________________________________________ >> fluid-dev mailing list >> fluid-dev@nongnu.org >> https://lists.nongnu.org/mailman/listinfo/fluid-dev >> -- Mark Knoop _______________________________________________ fluid-dev mailing list fluid-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/fluid-dev