[go: up one dir, main page]
Menu ▾ ▴

#333 inconsistent core dump of v1.3.0 on OmniOS

v1.0 (example)
open
nobody
None
5
2024-09-15
2020-12-06
Bryan Stenson
No

I've had a very inconsistent crash on OmniOS (omnios-r151036-4a32ffb911) of minidlna v1.3.0.

The inconsistency makes it difficult to diagnose, although the two crashes I have seen happen at the same location of a specific media (with about 8 minutes left). Subsequent attempts to crash have been inconsistent. When minidlna does core dump, the OS restarts the process, and I'm able to replay the media through the previously troubled spot. This is a strange one.

I did manage to get a core dump file, and pstack core show this:

root@minidlna:/var/cores# pstack core.minidlnad.10624.interview.8minsleft 
core 'core.minidlnad.10624.interview.8minsleft' of 10624:   /opt/ooce/minidlna/sbin/minidlnad -R -f /etc/opt/ooce/minidlna/minidln
 0000000000434a84 select_del () + 74
 0000000000411ce7 CloseSocket_upnphttp () + 17
 0000000000413d63 ProcessHttpQuery_upnphttp () + d73
 00000000004155d2 Process_upnphttp () + 2c2
 00000000004348fb select_process () + cb
 0000000000410640 main () + 3e0
 000000000040e163 _start_crt () + 83
 000000000040e0c8 _start () + 18

From what I can tell, the problem happens from here: https://sourceforge.net/p/minidlna/git/ci/v1_3_0/tree/select.c#l115.

But, I'm not familiar with the codebase to understand how this could happen.

I'm documenting this here in hopes someone can offer pointers on how to nail this down.

Discussion

  • Bryan Stenson

    Bryan Stenson - 2020-12-13

    I've managed to crash minidlna again, using different media. The resulting pstack core is identical to the original post.

    After the OS restarts minidlna, I'm able to resume playback at through the trouble spot without issue.

    Here are the facts I've observed to be true:
    1. Not related to one specific media (seen on multiple media)
    2. Crashes happen at the same location in the code (identical pstack)
    3. Intermittent/rare (same time in media does not always crash...repeated attempts to crash at a spot rarely result in a crash)

     

  • Nite Life

    Nite Life - 2021-02-18

    Same on Fedora 32 with minidlna 1.3.0:

       Stack trace of thread 235181:
                #0  0x000055573cc1e63b select_del (minidlnad + 0x3863b)
                #1  0x000055573cbf5603 CloseSocket_upnphttp (minidlnad + 0xf603)
                #2  0x000055573cbf7911 ProcessHttpQuery_upnphttp (minidlnad + 0x11911)
                #3  0x000055573cbf929d Process_upnphttp (minidlnad + 0x1329d)
                #4  0x000055573cc1e4ae select_process (minidlnad + 0x384ae)
                #5  0x000055573cbf1865 main (minidlnad + 0xb865)
                #6  0x00007f12cc365082 __libc_start_main (libc.so.6 + 0x27082)
                #7  0x000055573cbf209e _start (minidlnad + 0xc09e)

    Client is a LG OLED Smart TV if that helps.

     

  • Nite Life

    Nite Life - 2021-02-23

    I just rebuilt minidlna and will check if the patch fixes the problem.

     

  • Dominik Mierzejewski

    Dominik Mierzejewski - 2021-03-02

    I've just noticed I'm getting the same crash on my home server running F33. Reported to RPM Fusion bugzilla and linked this ticket.

    Backtrace is similar:

    #0  0x000056529a9f3a9b in select_del (ev=0x56529c8ce210, flags=<optimized out>) at select.c:135
#1  0x000056529a9dd8e2 in CloseSocket_upnphttp (h=0x56529c8ce210) at upnphttp.c:126
#2  0x000056529a9e18ce in SendResp_dlnafile (object=0x7ffc82a7c30c "10573.mkv", h=0x56529c8ce210) at upnphttp.c:2082
#3  ProcessHttpQuery_upnphttp (h=0x56529c8ce210) at upnphttp.c:984
#4  0x000056529a9e3ced in Process_upnphttp (ev=<optimized out>) at upnphttp.c:1114
#5  0x000056529a9fe52e in select_process (msec=<optimized out>) at select.c:186
#6  0x000056529a9d694e in main (argc=<optimized out>, argv=<optimized out>) at minidlna.c:1285
     

  • Nite Life

    Nite Life - 2021-03-02

    The patch linked by Andy helped to fix the the problem.

     

Log in to post a comment.