centos6 compilation, running results in the following errors
zqfoffice opened this issue · 17 comments
src/app/srs_app_st.cpp:239: void srs_close_stfd(_st_netfd*&): Assertion `err != -1' failed. Is this a compilation issue or a CentOS version issue? What version did you compile with?
TRANS_BY_GPT3
Please provide the bt (stack information) in the core file. You can search on Baidu how to obtain the bt from a core file.
TRANS_BY_GPT3
Please provide the version number.
TRANS_BY_GPT3
v210 version of the stream pulling may cause memory leaks, with each user garbage possibly causing around 20k memory leaks. It feels like there is a memory leak occurring during the interaction with the client. Can you help me figure out the cause? Thank you!
On 2016-09-28 12:55:01, winlin notifications@github.com wrote:
Please provide the version number.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.
TRANS_BY_GPT3
Information is unclear.
TRANS_BY_GPT3
Hello,
I have set up a three-layer streaming media server using version v215. I am pushing the stream to the edge and pulling it from another edge. After stopping the pulling, a crash of the middle node always occurs after a certain period of time. The gdb output of the specific core file is as follows:
The backtrace of each core file is the same.
Have you encountered this issue on your side?
On 2016-10-24 17:00:59, winlin notifications@github.com wrote:
Information is unclear.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.
TRANS_BY_GPT3
What is the gdb for 'core'? Your information is blank. Please do not paste images, copy the text from gdb-bt and check the stack.
TRANS_BY_GPT3
2.0.220
You update to the latest version first, if there are still core issues, then paste the BT (backtrace) for us to investigate.
TRANS_BY_GPT3
Thank you, version 220 also has errors. Below is the gdb information:
On 2016-11-03 15:09:20, winlin notifications@github.com wrote:
2.0.220
First, update to the latest version. If there is still a core, then paste the bt so we can investigate.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.
TRANS_BY_GPT3
Most of the errors are like this,
On 2016-11-03 15:09:20, winlin notifications@github.com wrote:
Make sure to maintain the markdown structure.
2.0.220
You update to the latest version first, if there is still a core issue, then paste the bt so we can check it.
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.
TRANS_BY_GPT3
The information you provided is all blank. You can open this link and take a look in your browser:
#654 (comment)
Please do not paste images, just paste the text.
TRANS_BY_GPT3
The text is as follows,
#0 0x00007f99612fd509 in main_arena () from /lib64/libc.so.6
#1 0x000000000047ff00 in SrsRtmpConn::process_publish_message (this=0x1fde060, source=0x1fd6840, msg=0x1fdbc40, vhost_is_edge=true) at src/app/srs_app_rtmp_conn.cpp:1231
#2 0x000000000047fe21 in SrsRtmpConn::handle_publish_message (this=0x1fde060, source=0x1fd6840, msg=0x1fdbc40, is_fmle=true, vhost_is_edge=true) at src/app/srs_app_rtmp_conn.cpp:1211
#3 0x0000000000516dc1 in SrsPublishRecvThread::handle (this=0x7f9961dcc890, msg=0x1fdbc40) at src/app/srs_app_recv_thread.cpp:386
#4 0x0000000000515962 in SrsRecvThread::cycle (this=0x7f9961dcc898) at src/app/srs_app_recv_thread.cpp:100
#5 0x00000000004b1c33 in SrsReusableThread2::cycle (this=0x2062410) at src/app/srs_app_thread.cpp:540
#6 0x00000000004b0b69 in internal::SrsThread::thread_cycle (this=0x1fdf170) at src/app/srs_app_thread.cpp:207
#7 0x00000000004b0d7c in internal::SrsThread::thread_fun (arg=0x1fdf170) at src/app/srs_app_thread.cpp:245
#8 0x000000000052b102 in _st_thread_main () at sched.c:327
#9 0x000000000052b89c in st_thread_create (start=0x899ce0 <_srs_stages>, arg=0x2069b6c, joinable=0, stk_size=5105020) at sched.c:591
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
On 2016-11-03 16:21:53, winlin notifications@github.com wrote:
The information you provided is all blank. You can open this link and check it in your browser:
#654 (comment)
Please do not paste images, just paste the text.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.
TRANS_BY_GPT3
Let's take a look.
TRANS_BY_GPT3
Using the latest version 220 of the code for troubleshooting, it was found that the code does not match the code provided in the bt stack.
The code provided in the bt stack at src/app/srs_app_rtmp_conn.cpp:1231 is inside the SrsRtmpConn::process_publish_message function, but in the actual code, that position is inside the SrsRtmpConn::set_sock_options function.
Please upload the binary file and the corresponding core file to the cloud storage for debugging purposes. @zqfoffice
TRANS_BY_GPT3
Sorry, the core information above is for version 215, and below I am posting the core information and core file for version 220:
[root@LOCAL-VM-142 srs_test]# gdb ./objs/srs_220 core.9810
GNU gdb (GDB) Red Hat Enterprise Linux (7.2-83.el6)
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from /root/new_server/srs_test/objs/srs_220...done.
[New Thread 9810]
Missing separate debuginfo for
Try: yum --enablerepo='-debug' install /usr/lib/debug/.build-id/08/e42c6c3d2cd1e5d68a43b717c9eb3d310f2df0
Reading symbols from /lib64/libdl.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib64/libdl.so.2
Reading symbols from /usr/lib64/libstdc++.so.6...(no debugging symbols found)...done.
Loaded symbols for /usr/lib64/libstdc++.so.6
Reading symbols from /lib64/libm.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib64/libm.so.6
Reading symbols from /lib64/libgcc_s.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib64/libgcc_s.so.1
Reading symbols from /lib64/libc.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib64/libc.so.6
Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
Core was generated by `./objs/srs_220 -c ./conf/3100'.
Program terminated with signal 11, Segmentation fault.
#0 0x00007f57d88495cf in main_arena () from /lib64/libc.so.6
Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.192.el6.x86_64 libgcc-4.4.7-16.el6.x86_64 libstdc++-4.4.7-16.el6.x86_64
(gdb) bt
#0 0x00007f57d88495cf in main_arena () from /lib64/libc.so.6
#1 0x0000000000480137 in SrsRtmpConn::process_publish_message (this=0x12d0ba0, source=0x12f81b0, msg=0x13045e0, vhost_is_edge=true) at src/app/srs_app_rtmp_conn.cpp:1029
#2 0x0000000000480069 in SrsRtmpConn::handle_publish_message (this=0x12d0ba0, source=0x12f81b0, msg=0x13045e0, is_fmle=true, vhost_is_edge=true) at src/app/srs_app_rtmp_conn.cpp:1015
#3 0x0000000000517645 in SrsPublishRecvThread::handle (this=0x7f57d93b4890, msg=0x13045e0) at src/app/srs_app_recv_thread.cpp:386
#4 0x00000000005161e6 in SrsRecvThread::cycle (this=0x7f57d93b4898) at src/app/srs_app_recv_thread.cpp:100
#5 0x00000000004b1ff7 in SrsReusableThread2::cycle (this=0x12fbb60) at src/app/srs_app_thread.cpp:540
#6 0x00000000004b0f2d in internal::SrsThread::thread_cycle (this=0x1306c90) at src/app/srs_app_thread.cpp:207
#7 0x00000000004b1140 in internal::SrsThread::thread_fun (arg=0x1306c90) at src/app/srs_app_thread.cpp:245
#8 0x000000000052bada in _st_thread_main () at sched.c:327
#9 0x000000000052c274 in st_thread_create (start=0x89a940 <_srs_stages>, arg=0x12fbf4c, joinable=0, stk_size=5107200) at sched.c:591
#10 0x00007f57d93b4660 in ?? ()
#11 0x000000000000000a in ?? ()
#12 0x00007f57d9318e90 in ?? ()
#13 0x00000004012fbf4c in ?? ()
#14 0x0000000affffffff in ?? ()
#15 0x00000000012ffe40 in ?? ()
#16 0x0000000000000001 in ?? ()
#17 0x00007f57d93b4690 in ?? ()
#18 0x000000000052b457 in _st_vp_schedule () at sched.c:127
#19 0x00000000004b10ee in ?? () at src/app/srs_app_thread.cpp:238
#20 0x00000000012d0c90 in ?? ()
#21 0x0000000000000000 in ?? ()
On 2016-11-03 19:16:59, ME_Kun_Han notifications@github.com wrote:
After using the latest code version 220 for troubleshooting, I found that the code does not match the code provided in the bt stack.
According to the bt stack, the code at src/app/srs_app_rtmp_conn.cpp:1231 should be inside the SrsRtmpConn::process_publish_message function. However, in the actual code, this position is inside the SrsRtmpConn::set_sock_options function.
I hope you can upload the binary file and the corresponding core file to the cloud drive for debugging purposes. @zqfoffice
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
TRANS_BY_GPT3
Fixed in 2.0.221
int SrsEdgeIngester::ingest()
{
int ret = ERROR_SUCCESS;
client->set_recv_timeout(SRS_EDGE_INGESTER_TIMEOUT_US);
SrsPithyPrint* pprint = SrsPithyPrint::create_edge();
SrsAutoFree(SrsPithyPrint, pprint);
while (!pthread->interrupted()) {
pprint->elapse();
// pithy print
if (pprint->can_print()) {
kbps->sample();
srs_trace("<- "SRS_CONSTS_LOG_EDGE_PLAY
" time=%"PRId64", okbps=%d,%d,%d, ikbps=%d,%d,%d",
pprint->age(),
kbps->get_send_kbps(), kbps->get_send_kbps_30s(), kbps->get_send_kbps_5m(),
kbps->get_recv_kbps(), kbps->get_recv_kbps_30s(), kbps->get_recv_kbps_5m());
}
// read from client.
SrsCommonMessage* msg = NULL;
if ((ret = client->recv_message(&msg)) != ERROR_SUCCESS) {
if (!srs_is_client_gracefully_close(ret)) {
srs_error("pull origin server message failed. ret=%d", ret);
}
return ret;
}
srs_verbose("edge loop recv message. ret=%d", ret);
srs_assert(msg);
/////////////////////////////////////////////////////////////////////////////////////////////
// Memory leak
SrsAutoFree(SrsCommonMessage, msg);
if ((ret = process_publish_message(msg)) != ERROR_SUCCESS) {
return ret;
}
////////////////////////////////////////////////////////////////////////////////////////////
}
return ret;
}
Multiple levels of cascading, top-level disconnection, memory leaks occur at the edges, and the point of leakage is in the above function. The leakage is caused by 'msg'.
On 2016-11-05 10:52:21, winlin notifications@github.com wrote:
fixed in 2.0.221
—" is a dash or hyphen in English. It is used to indicate a pause or break in a sentence.
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
TRANS_BY_GPT3
Please provide another issue, one issue solves one problem.
TRANS_BY_GPT3