srs encountered a coredump

[juntaoliu]

warning: exec file is newer than core file. [New Thread 49573]

warning: Corrupted shared library list

warning: Corrupted shared library list Core was generated by `./objs/srs -c ./conf/srs.conf'. Program terminated with signal 11, Segmentation fault.

0 0x0000003e5689d258 in ?? ()

(gdb) where

0 0x0000003e5689d258 in ?? ()

1 0x0000000000001388 in ?? ()

2 0x0000000000a75780 in ?? ()

3 0x00000000004e286c in SrsConfig::get_hls_cleanup (this=0xa75798, vhost=Cannot access memory at address 0x0

) at src/app/srs_app_config.cpp:3908

4 0x00000000004a7d11 in SrsHls::dispose (this=Cannot access memory at address 0x4e2844

) at src/app/srs_app_hls.cpp:1166 Backtrace stopped: previous frame inner to this frame (corrupt stack?)

The log has been lost, this is the information from the coredump. The SRS executable file has been recompiled with added logs, so some function entries are not displayed completely.

TRANS_BY_GPT3

[juntaoliu]

Encountered another core, I'll make a note of it here. I'll investigate the cause slowly.

warning: exec file is newer than core file. [New Thread 90307]

warning: Corrupted shared library list

warning: Corrupted shared library list

warning: Corrupted shared library list

warning: Corrupted shared library list Core was generated by `./objs/srs -c ./conf/srs.conf'. Program terminated with signal 11, Segmentation fault.

0 0x0000003e5689d258 in ?? ()

(gdb) where

0 0x0000003e5689d258 in ?? ()

1 0x0000000000001388 in ?? ()

2 0x0000000001425aa0 in ?? ()

3 0x00000000004d5918 in SrsConfig::get_vhost_hls_nb_notify (this=0x1425ab8, vhost=...) at src/app/srs_app_config.cpp:3886

4 0x00000000004880b7 in SrsSource::~SrsSource (this=0x8993a0, __in_chrg=) at src/app/srs_app_source.cpp:1000

5 0x00000000004871c6 in SrsSource::fetch_or_create (r=0x1477920, h=0x7fffa3778740, pps=0x49bdf3) at src/app/srs_app_source.cpp:758

6 0x0000000000473ae2 in SrsServer::dispose (this=0x14011a0) at src/app/srs_app_server.cpp:567

7 0x0000000000475f82 in SrsServer::cycle (this=0x14011a0) at src/app/srs_app_server.cpp:884

8 0x000000000052a936 in run () at src/main/srs_main_server.cpp:359

9 0x000000000052a764 in run () at src/main/srs_main_server.cpp:340

10 0x000000000052a3fa in main (argc=3, argv=0x7fffa3778988) at src/main/srs_main_server.cpp:310

TRANS_BY_GPT3

[juntaoliu]

This problem is probably due to the following reasons: when hls is enabled, _req has been released during disposal, and then an error occurred when requesting _req->vhost. After adding a pointer check here, I no longer encountered a coredump and also saw the logs indicating that it executed to this point.

However, it is unclear why _req is being released. Looking at the code logic, it seems that the release of this _req is correct.

void SrsHls::dispose() { if (hls_enabled) { on_unpublish(); }

if (!_req) {
    srs_warn("hls dispose failed,  _req may be free...");
    return;
}

// Ignore when hls_dispose disabled.
// @see https://github.com/ossrs/srs/issues/865
int hls_dispose = _srs_config->get_hls_dispose(_req->vhost);
if (hls_dispose == 0)  {
    return;
}

muxer->dispose();

}

TRANS_BY_GPT3

[winlinvip]

Fixed.