svn-1659 crashes when SB tries to access

Viewing 12 posts - 16 through 27 (of 27 total)
  • Author
    Posts
  • #12548
    rpedde
    Participant

    @raveman wrote:

    got same problem with previous and 1668 nightly build. my system is RHEL4 server

    What’s your plugin_dir path? Is it $prefix/lib/mt-daapd, or $prefix/share/mt-daapd/plugins?

    Should be $prefix/lib/mt-daapd.

    — Ron

    #12549
    thorstenhirsch
    Participant

    I corrected the plugin_dir path, but the server keeps crashing the same way as before.

    edit: nightly svn-1671 crashes also.

    #12550
    rpedde
    Participant

    @thorstenhirsch wrote:

    I corrected the plugin_dir path, but the server keeps crashing the same way as before.

    edit: nightly svn-1671 crashes also.

    Are you using sqlite3 or sqlite?

    #12551
    thorstenhirsch
    Participant

    Still sqlite3 so far.

    edit: maybe an strace output can help you…

    Process 4504 attached - interrupt to quit
    _newselect(8, [5 6 7], NULL, NULL, {4, 200000}) = 0 (Timeout)
    gettimeofday({1191104269, 962564}, NULL) = 0
    gettimeofday({1191104269, 965270}, NULL) = 0
    _newselect(8, [5 6 7], NULL, NULL, {2, 884765}) = 0 (Timeout)
    gettimeofday({1191104272, 852530}, NULL) = 0
    sendto(7, "204164TUXI5local12001"..., 838, 0, {sa_family=AF_INET, sin_port=htons(5353), sin_addr=inet_addr("224.0.0.251")}, 16) = 838
    gettimeofday({1191104272, 859943}, NULL) = 0
    _newselect(8, [5 6 7], NULL, NULL, {0, 92773}) = 1 (in [7], left {0, 100000})
    recvmsg(7, {msg_name(16)={sa_family=AF_INET, sin_port=htons(5353), sin_addr=inet_addr("192.168.0.7")}, msg_iov(1)=[{"204164TUXI5local12001"..., 8952}], msg_controllen=40, {cmsg_len=24, cmsg_level=SOL_IP, cmsg_type=, ...}, msg_flags=0}, 0) = 838
    gettimeofday({1191104272, 870938}, NULL) = 0
    gettimeofday({1191104272, 874055}, NULL) = 0
    gettimeofday({1191104272, 876861}, NULL) = 0
    _newselect(8, [5 6 7], NULL, NULL, {0, 76171}) = 0 (Timeout)
    gettimeofday({1191104272, 952525}, NULL) = 0
    gettimeofday({1191104272, 955222}, NULL) = 0
    _newselect(8, [5 6 7], NULL, NULL, {4, 997070}) = 1 (in [5], left {4, 440000})
    read(5, "3"..., 684) = 684
    write(8, "1", 4) = 4
    gettimeofday({1191104273, 520601}, NULL) = 0
    gettimeofday({1191104273, 523297}, NULL) = 0
    _newselect(8, [5 6 7], NULL, NULL, {4, 998046}) = 1 (in [5], left {1, 410000})
    read(5, "3"..., 684) = 684
    write(8, "1", 4) = 4
    gettimeofday({1191104277, 124515}, NULL) = 0
    gettimeofday({1191104277, 127040}, NULL) = 0
    _newselect(8, [5 6 7], NULL, NULL, {4, 997070}) = 1 (in [5], left {2, 880000})
    read(5, "", 684) = 0
    time([1191104279]) = 1191104279
    stat64(0x2b0b3cdc, 0x7fff63f0) = 0
    stat64(0x2b0b3cdc, 0x7fff6358) = 0
    stat64(0x2b0b3cdc, 0x7fff6358) = 0
    getpid() = 4504
    send(3, "Sep 29 17:17:59 mt-daapd[450"..., 94, MSG_NOSIGNAL) = 94
    time(NULL) = 1191104279
    write(4, "2007-09-29 17:17:59 (00004000): "..., 90) = 90
    write(4, "2007-09-29 17:17:59: Abortingn", 30) = 30
    write(2, "Rendezvous socket closed (daap s"..., 58) = 58
    write(2, "Abortingn", 9) = 9
    exit_group(1) = ?
    Process 4504 detached

    Another info: the webserver process always crashs after I visited the playlists. All other pages work w/o problems and even the playlist page is displayed correctly. But no matter which page I click next, the webserver is always down after the playlist page.

    #12552
    rpedde
    Participant

    @thorstenhirsch wrote:

    Still sqlite3 so far.

    edit: maybe an strace output can help you…

    Process 4504 attached - interrupt to quit
    _newselect(8, [5 6 7], NULL, NULL, {4, 200000}) = 0 (Timeout)
    gettimeofday({1191104269, 962564}, NULL) = 0
    gettimeofday({1191104269, 965270}, NULL) = 0
    _newselect(8, [5 6 7], NULL, NULL, {2, 884765}) = 0 (Timeout)
    gettimeofday({1191104272, 852530}, NULL) = 0
    sendto(7, "204164TUXI5local12001"..., 838, 0, {sa_family=AF_INET, sin_port=htons(5353), sin_addr=inet_addr("224.0.0.251")}, 16) = 838
    gettimeofday({1191104272, 859943}, NULL) = 0
    _newselect(8, [5 6 7], NULL, NULL, {0, 92773}) = 1 (in [7], left {0, 100000})
    recvmsg(7, {msg_name(16)={sa_family=AF_INET, sin_port=htons(5353), sin_addr=inet_addr("192.168.0.7")}, msg_iov(1)=[{"204164TUXI5local12001"..., 8952}], msg_controllen=40, {cmsg_len=24, cmsg_level=SOL_IP, cmsg_type=, ...}, msg_flags=0}, 0) = 838
    gettimeofday({1191104272, 870938}, NULL) = 0
    gettimeofday({1191104272, 874055}, NULL) = 0
    gettimeofday({1191104272, 876861}, NULL) = 0
    _newselect(8, [5 6 7], NULL, NULL, {0, 76171}) = 0 (Timeout)
    gettimeofday({1191104272, 952525}, NULL) = 0
    gettimeofday({1191104272, 955222}, NULL) = 0
    _newselect(8, [5 6 7], NULL, NULL, {4, 997070}) = 1 (in [5], left {4, 440000})
    read(5, "3"..., 684) = 684
    write(8, "1", 4) = 4
    gettimeofday({1191104273, 520601}, NULL) = 0
    gettimeofday({1191104273, 523297}, NULL) = 0
    _newselect(8, [5 6 7], NULL, NULL, {4, 998046}) = 1 (in [5], left {1, 410000})
    read(5, "3"..., 684) = 684
    write(8, "1", 4) = 4
    gettimeofday({1191104277, 124515}, NULL) = 0
    gettimeofday({1191104277, 127040}, NULL) = 0
    _newselect(8, [5 6 7], NULL, NULL, {4, 997070}) = 1 (in [5], left {2, 880000})
    read(5, "", 684) = 0
    time([1191104279]) = 1191104279
    stat64(0x2b0b3cdc, 0x7fff63f0) = 0
    stat64(0x2b0b3cdc, 0x7fff6358) = 0
    stat64(0x2b0b3cdc, 0x7fff6358) = 0
    getpid() = 4504
    send(3, "Sep 29 17:17:59 mt-daapd[450"..., 94, MSG_NOSIGNAL) = 94
    time(NULL) = 1191104279
    write(4, "2007-09-29 17:17:59 (00004000): "..., 90) = 90
    write(4, "2007-09-29 17:17:59: Abortingn", 30) = 30
    write(2, "Rendezvous socket closed (daap s"..., 58) = 58
    write(2, "Abortingn", 9) = 9
    exit_group(1) = ?
    Process 4504 detached

    Another info: the webserver process always crashs after I visited the playlists. All other pages work w/o problems and even the playlist page is displayed correctly. But no matter which page I click next, the webserver is always down after the playlist page.

    Try sqlite 2. I think I’ve got a threading problem in sqlite3. Might be they changed the threading model yet again.

    #12553
    RobotChicken
    Participant

    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))
    #12554
    rpedde
    Participant

    @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

    #12555
    RobotChicken
    Participant

    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.

    #12556
    RobotChicken
    Participant

    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…

    #12557
    rpedde
    Participant

    @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

    #12558
    thorstenhirsch
    Participant

    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.

    #12559
    rpedde
    Participant

    @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

Viewing 12 posts - 16 through 27 (of 27 total)
  • The forum ‘Nightlies Feedback’ is closed to new topics and replies.