svn-1659 crashes when SB tries to access

[RobotChicken]

Crash reason (?):
http://mt-daapd.svn.sourceforge.net/viewvc/mt-daapd/trunk/src/util.c?r1=1633&r2=1634&view=diff&diff_format=l

(1) In OpenBSD (what I am using) there is va_copy() but the it does not get picked up by util.c (no HAVE_*VA_COPY macros?)
(2) I think

VA_COPY(a,b) memcpy((a),(b),sizeof(b))

should be

VA_COPY(a,b) memcpy((&a),(&b),sizeof(b))

[rpedde]

@RobotChicken wrote:

Crash reason (?):
http://mt-daapd.svn.sourceforge.net/viewvc/mt-daapd/trunk/src/util.c?r1=1633&r2=1634&view=diff&diff_format=l

(1) In OpenBSD (what I am using) there is va_copy() but the it does not get picked up by util.c (no HAVE_*VA_COPY macros?)
(2) I think

VA_COPY(a,b) memcpy((a),(b),sizeof(b))

should be

VA_COPY(a,b) memcpy((&a),(&b),sizeof(b))

Oh, duh. No wonder I couldn’t find it in any of the arches I have — it’s not arch dependent, it’s arch and os dependent.

Have you verified that the patch works?

Also, can you research to see where va_copy is defined, and what the define is that’s making it not detect?

Or failing that, can you find the header that defines va_copy and email it to me?

([email protected])

thanks.

— Ron

[RobotChicken]

After my va_copy() patch things are somewhat better, but unfortunately I still get crashes on my setup (although not as immediate as before which resulted in any sort of connection crashing the server). I can start streaming a song, but as soon as I switch to an other one the server dies (on both sqlite and sqlite3):

Loading new config file.

Firefly Version svn-1671: Starting with debuglevel 5

Loaded plugin /usr/local/lib/mt-daapd/plugins/out-daap.so (daap/svn-1671)

Loaded plugin /usr/local/lib/mt-daapd/plugins/rsp.so (rsp/svn-1671)

Loaded plugin /usr/local/lib/mt-daapd/plugins/ssc-script.so (ssc-script/svn-1671)

Plugin loaded: ssc-script/svn-1671

Plugin loaded: rsp/svn-1671

Plugin loaded: daap/svn-1671

Starting rendezvous daemon

Starting signal handler

Initializing database

Starting web server from /usr/local/share/mt-daapd/admin-root on port 3689

Listening on port 3689

Starting server thread

Registering rendezvous names

Serving 2 songs.  Startup complete in 0 seconds

Session 0: Streaming file 'Song1.mp3' to 10.0.0.10 (offset 0)

Session 0: Streaming file '02 - Song.wma' to 10.0.0.10 (offset 0)

Broken pipe

Rendezvous socket closed (daap server crashed?)  Aborting.

Aborting

Here is the last part with a higher debug setting (-d10):

...

writing to socket 13

entering io_read

Read 512 bytes

writing to socket 13

Received a message from daap server

Broken pipe

Rendezvous socket closed (daap server crashed?)  Aborting.

Aborting

Note that there were a number of other issues while compiling on OpenBSD v4.1 (or more like pre-v4.1, as I grabbed the distro before the official version was released):
(1) Zeroconf/Bonjour daemons:
Bulit-in mDNS does not work. I am using howl instead (as noted in an other thread on this forum). Note: It seems like this is an issue with the Apple Bonjour code that does not seem to have been tested on openBSD (for one it does not compile due to an issue in the code the compilation of which is only attempted apparently on openBSD. But even once that code is fixed, I get “mDNSResponder: mDNSPlatformSendUDP got error 64 (Host is down) sending packet to 224.0.0.251 on interface 10.0.0.2/vr0/2” error messages. Also
apparently avahi does not work on openBSD either (could not even compile it).

(2) There are lots of warnings during the compilation (some because of apparently no headers included with function prototypes but mostly because of openBSD’s security conscious approach – e.g. using strlcpy() instead of strcpy()). There are also a few errors, like strcasestr() not being found during running the pre-compilation configuration script thus having a conflicting version trying to be compiled (in compat.[c|h]). I also had to adjust the include path to find howl.h (i.e. add -I/usr/local/include/howl to the right places in src/Makefile which still causes some PACKAGE/VERSION redefined warnings, but at least it proceeds).

(3) as far as the va_copy() – I have no idea what macro should be looked at to see whether a platform has it or not. In my case I just hardcoded a “#define HAVE_VA_COPY 1” macro so that the va_copy() from openBSD’s header files are used (which by looks to be defined as “#define va_copy(dest, src) ((dest) = (src)) on i386 platforms). However my original patch also seems to have worked.

[RobotChicken]

I addressed my “broken pipe” issue by copying the u_ignore_sigpipe() function from the (old) OpenBSD ports version of the mt-daap sources (uici.c) into the io.c of the nightly build – and call it from io_listen_open().
While I’m sure this is a pretty big hack – it does seem to work…

[rpedde]

@RobotChicken wrote:

(1) Zeroconf/Bonjour daemons:
Bulit-in mDNS does not work. I am using howl instead (as noted in an other thread on this forum). Note: It seems like this is an issue with the Apple Bonjour code that does not seem to have been tested on openBSD (for one it does not compile due to an issue in the code the compilation of which is only attempted apparently on openBSD. But even once that code is fixed, I get “mDNSResponder: mDNSPlatformSendUDP got error 64 (Host is down) sending packet to 224.0.0.251 on interface 10.0.0.2/vr0/2” error messages. Also
apparently avahi does not work on openBSD either (could not even compile it).

Yeah, I’ve seen that too. Seems like at one point it did compile, but it hasn’t been maintained with the rest of the code… all the ifdefs for openbsd are there but references struct members that have had name changes, etc.

Seems pretty deprecated.

(3) as far as the va_copy() – I have no idea what macro should be looked at to see whether a platform has it or not. In my case I just hardcoded a “#define HAVE_VA_COPY 1” macro so that the va_copy() from openBSD’s header files are used (which by looks to be defined as “#define va_copy(dest, src) ((dest) = (src)) on i386 platforms). However my original patch also seems to have worked.

I think on most (all?) va_list is a void*, so it should probably work on most (all?) systems. Just that it doesn’t *have* to be, and could well break on some systems.

I thought I had run into the sigpipe issue before and fixed it. :/

Guess not.

I appreciate the pointers. I have an openbsd box I just put up, I’m going to try and work these all into the source.

Thanks.

– Ron

[thorstenhirsch]

I can confirm that my initial problem (crash when SB tries to connect) is solved in svn-1673. Thank you very much, rpedde!

It even works with sqlite3. And I also can’t reproduce the crash in the web server. Seems to be a pretty stable version for me.

[rpedde]

@thorstenhirsch wrote:

I can confirm that my initial problem (crash when SB tries to connect) is solved in svn-1673. Thank you very much, rpedde!

It even works with sqlite3. And I also can’t reproduce the crash in the web server. Seems to be a pretty stable version for me.

Don’t *say* that!

— Ron

[Author]

Posts