ossrs
Heap-buffer-overflow error in SRS version 6.x logged on February 14, 2025
!!! Before submitting a new bug report, please ensure you have searched for any existing bugs. Duplicate issues or questions that are overly simple or already addressed in the documentation will be removed without any response.
Describe the bug
[2025-02-14 02:10:57.075][ERROR][80557][i8224766][0] =================================================================
[2025-02-14 02:10:57.075][ERROR][80557][i8224766][0] ==80557==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x604000007910 at pc 0x55bf19bddcab bp 0x7f6225e5de30 sp 0x7f6225e5de20
[2025-02-14 02:10:57.075][ERROR][80557][i8224766][0] READ of size 8 at 0x604000007910 thread T1
[2025-02-14 02:10:57.075][ERROR][80557][i8224766][0] #0 0x55bf19bddcaa in impl_SrsAutoFree<SrsLiveStream>::~impl_SrsAutoFree() src/core/srs_core_autofree.hpp:79, r0=1093
[2025-02-14 02:10:57.075][ERROR][80557][i8224766][0] #1 0x55bf19bd8877 in SrsHttpStreamServer::http_unmount(SrsRequest*) src/app/srs_app_http_stream.cpp:1094, r0=1093
[2025-02-14 02:10:57.075][ERROR][80557][i8224766][0] #2 0x55bf19d25e6c in SrsHttpServer::http_unmount(SrsRequest*) src/app/srs_app_http_conn.cpp:557, r0=1093
[2025-02-14 02:10:57.075][ERROR][80557][i8224766][0] #3 0x55bf19b31d88 in SrsServer::on_unpublish(SrsRequest*) src/app/srs_app_server.cpp:1334, r0=1093
[2025-02-14 02:10:57.075][ERROR][80557][i8224766][0] #4 0x55bf19b90650 in SrsLiveSource::on_unpublish() src/app/srs_app_source.cpp:2649, r0=1093
[2025-02-14 02:10:57.075][ERROR][80557][i8224766][0] #5 0x55bf19b65960 in SrsRtmpConn::release_publish(SrsSharedPtr<SrsLiveSource>) src/app/srs_app_rtmp_conn.cpp:1151, r0=1093
[2025-02-14 02:10:57.075][ERROR][80557][i8224766][0] #6 0x55bf19b6206a in SrsRtmpConn::publishing(SrsSharedPtr<SrsLiveSource>) src/app/srs_app_rtmp_conn.cpp:964, r0=1093
[2025-02-14 02:10:57.075][ERROR][80557][i8224766][0] #7 0x55bf19b5b3a4 in SrsRtmpConn::stream_service_cycle() src/app/srs_app_rtmp_conn.cpp:658, r0=1093
[2025-02-14 02:10:57.075][ERROR][80557][i8224766][0] #8 0x55bf19b57f56 in SrsRtmpConn::service_cycle() src/app/srs_app_rtmp_conn.cpp:446, r0=1093
[2025-02-14 02:10:57.075][ERROR][80557][i8224766][0] #9 0x55bf19b55095 in SrsRtmpConn::do_cycle() src/app/srs_app_rtmp_conn.cpp:262, r0=1093
[2025-02-14 02:10:57.075][ERROR][80557][i8224766][0] #10 0x55bf19b6ba3f in SrsRtmpConn::cycle() src/app/srs_app_rtmp_conn.cpp:1609, r0=1093
[2025-02-14 02:10:57.075][ERROR][80557][i8224766][0] #11 0x55bf19be4244 in SrsFastCoroutine::cycle() src/app/srs_app_st.cpp:309, r0=1093
[2025-02-14 02:10:57.075][ERROR][80557][i8224766][0] #12 0x55bf19be4399 in SrsFastCoroutine::pfn(void*) src/app/srs_app_st.cpp:324, r0=1093
[2025-02-14 02:10:57.075][ERROR][80557][i8224766][0] #13 0x55bf19fb4b56 in _st_thread_main /home/ecs-user/srs-project/srs-service/srs/trunk/objs/Platform-SRS6-Linux-5.15.0-GCC11.4.0-x86_64/st-srs/sched.c:380, r0=1093
[2025-02-14 02:10:57.075][ERROR][80557][i8224766][0] #14 0x55bf19fb548b in st_thread_create /home/ecs-user/srs-project/srs-service/srs/trunk/objs/Platform-SRS6-Linux-5.15.0-GCC11.4.0-x86_64/st-srs/sched.c:666, r0=1093
[2025-02-14 02:10:57.075][ERROR][80557][i8224766][0] #15 0x55bf19ae0511 in srs_context_set_cid_of(void*, _SrsContextId const&) src/protocol/srs_protocol_log.cpp:91, r0=1093
[2025-02-14 02:10:57.075][ERROR][80557][i8224766][0] #16 0x55bf198d62b0 in _SrsContextId::~_SrsContextId() src/core/srs_core.cpp:26, r0=1093
[2025-02-14 02:10:57.075][ERROR][80557][i8224766][0] #17 0x55bf19ae06b4 in impl_SrsContextRestore::~impl_SrsContextRestore() src/protocol/srs_protocol_log.cpp:104, r0=1093
[2025-02-14 02:10:57.075][ERROR][80557][i8224766][0] #18 0x55bf19b312b5 in SrsServer::do_on_tcp_client(ISrsListener*, void*&) src/app/srs_app_server.cpp:1267, r0=1093
[2025-02-14 02:10:57.075][ERROR][80557][i8224766][0] #19 0x7f62275fe34f (
Version Desribe your SRS Server version here. SRS/6.0.134(Hang)
To Reproduce Steps to reproduce the behavior: I have a device located in a factory that collects GB28181 information from Hikvision cameras. It is equipped with SRS/6.0.134(Hang). After collection, the data is pushed to an SRS server deployed on Alibaba Cloud ECS via RTMP. Initially, it operated normally, but recently, the process on Alibaba Cloud often crashes automatically. Upon analyzing the error logs from each crash, I discovered the aforementioned error. 4. See error
Expected behavior The system normally receives RTMP pushes and converts them for HLS playback. However, recently, after running for a period of time, it consistently encounters the aforementioned exception.
TRANS_BY_GPT4
- Check if a core dump file has been generated; if so, please upload it.
- Test if recording the GB28181 stream as an MP4 file can be replicated; if successful, please upload the MP4 file.
- Please send the configuration file as well.
TRANS_BY_GPT4
I have compiled several times on the VPS, and after running for a while, this issue occurs with RTMP streaming and HLS playback.
TRANS_BY_GPT4
- I don't know how to export a core dump file I don't know where to find this;
- I am unable to provide the current MP4 file that has been circulated, as it is currently a confidential monitoring content;
- What configuration is required? I am using gb28181.conf under conf;
I have also encountered this issue; how was it resolved?
TRANS_BY_GPT4
I have used the latest version of SRS, the latest version of 6, which is 6.155. After execution, I found that there was no problem with the issue I sent. From the current running time, I have not found the problem with me
---- Replied Message ---- | From | @.> | | Date | 04/16/2025 10:45 | | To | @.> | | Cc | @.>@.> | | Subject | Re: [ossrs/srs] Heap-buffer-overflow error in SRS version 6.x logged on February 14, 2025 (Issue #4290) |
I have also encountered this issue; how was it resolved?
TRANS_BY_GPT4
It appears you've entered an em dash or a long dash (—). If you intended to convey a message or ask a question, please provide more information. Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>
hz13521639772 left a comment (ossrs/srs#4290)
I have also encountered this issue; how was it resolved?
TRANS_BY_GPT4
You've entered an em dash again. If you have a specific message or question, please provide the text so it can be rephrased into simple, technical English. Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>
Same error XCORE-SRS/5.0.222 Build from sources
Jul 08 19:05:49 Schrodinger srs[461772]: [2025-07-08 19:05:49.355][WARN][461772][h84s9jox][4] client disconnect peer. ret=1009
Jul 08 19:05:49 Schrodinger srs[461772]: [2025-07-08 19:05:49.355][INFO][461772][9u31bb9y] RTC: clear zombies=2 resources, conns=40, removing=0, unsubs=1
Jul 08 19:05:49 Schrodinger srs[461772]: [2025-07-08 19:05:49.355][INFO][461772][h84s9jox] RTC: disposing #0 resource(RtcConn)(0x51d0000aa080), conns=40, disposing=2, zombies=0
Jul 08 19:05:49 Schrodinger srs[461772]: [2025-07-08 19:05:49.355][INFO][461772][j1039186] RTC: disposing #1 resource(RtcConn)(0x51d000143280), conns=39, disposing=2, zombies=0
Jul 08 19:05:49 Schrodinger srs[461772]: [2025-07-08 19:05:49.355][INFO][461772][3775y977] TCP: clear zombies=4 resources, conns=111, removing=0, unsubs=0
Jul 08 19:05:49 Schrodinger srs[461772]: [2025-07-08 19:05:49.355][INFO][461772][75e62o34] TCP: disposing #0 resource(HttpConn)(0x5070000c4100), conns=111, disposing=4, zombies=0
Jul 08 19:05:49 Schrodinger srs[461772]: [2025-07-08 19:05:49.355][INFO][461772][9ta60290] TCP: disposing #1 resource(HttpConn)(0x50700011cd20), conns=110, disposing=4, zombies=0
Jul 08 19:05:49 Schrodinger srs[461772]: [2025-07-08 19:05:49.355][INFO][461772][2y7773g4] TCP: disposing #2 resource(HttpConn)(0x50700013e660), conns=109, disposing=4, zombies=0
Jul 08 19:05:49 Schrodinger srs[461772]: [2025-07-08 19:05:49.355][INFO][461772][10fecji8] TCP: disposing #3 resource(Tcp)(0x50c0000b8d80), conns=108, disposing=4, zombies=0
Jul 08 19:05:49 Schrodinger srs[461772]: AddressSanitizer:DEADLYSIGNAL
Jul 08 19:05:49 Schrodinger srs[461772]: =================================================================
Jul 08 19:05:49 Schrodinger srs[461772]: ==461772==ERROR: AddressSanitizer: SEGV on unknown address (pc 0x7944886aca10 bp 0x79448776d210 sp 0x79448776d1c0 T1)
Jul 08 19:05:49 Schrodinger srs[461772]: ==461772==The signal is caused by a READ memory access.
Jul 08 19:05:49 Schrodinger srs[461772]: ==461772==Hint: this fault was caused by a dereference of a high value address (see register values below). Disassemble the provided pc to learn which register was used.
Jul 08 19:05:49 Schrodinger srs[461772]: AddressSanitizer:DEADLYSIGNAL
Jul 08 19:05:49 Schrodinger srs[461772]: AddressSanitizer: nested bug in the same thread, aborting.
Jul 08 19:05:49 Schrodinger systemd[1]: srs.service: Main process exited, code=exited, status=1/FAILURE
Jul 08 19:05:49 Schrodinger systemd[1]: srs.service: Failed with result 'exit-code'.
Jul 08 19:05:49 Schrodinger systemd[1]: srs.service: Consumed 54.350s CPU time.
Jul 08 19:05:49 Schrodinger systemd[1]: srs.service: Scheduled restart job, restart counter is at 414.
Jul 08 19:05:49 Schrodinger systemd[1]: Started srs.service - Srs PROD.
Jul 08 19:05:49 Schrodinger srs[462068]: [2025-07-08 19:05:49.558][INFO][462068][a0cg9od9] XCORE-SRS/5.0.222(Bee)
Jul 08 19:05:49 Schrodinger srs[462068]: [2025-07-08 19:05:49.559][INFO][462068][a0cg9od9] config parse complete
Jul 08 19:05:49 Schrodinger srs[462068]: [2025-07-08 19:05:49.559][INFO][462068][a0cg9od9] write log to console
