core dump in rtmpsrv
Trunk release built today is causing core dump in rtmpsrv with my test case. I have used rtmpsrv successfully many times previously using the stable 2.4 release. Looks like a memory management bug to me, but I could also be missing something entirely. The latest stable builds will not work for me since I am looking to leverage the new functionality for additional RTMP types / codes... System / Program info: """ $ lsb_release -idrc Distributor ID: Ubuntu Description: Ubuntu 12.10 Release: 12.10 Codename: quantal $ uname -a Linux svzu 3.5.0-18-generic #29-Ubuntu SMP Fri Oct 19 10:26:51 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux $ file rtmpsrv rtmpsrv: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=0xc5ef3983df3c92592432d8e7b5569f340bdbbba9, not stripped """ Runtime: """ $ ./rtmpsrv RTMP Server v2.4 (c) 2010 Andrej Stepanchuk, Howard Chu; license: GPL Streaming on rtmp://0.0.0.0:1935 Segmentation fault (core dumped) """ Debugging: """ $ gdb rtmpsrv core GNU gdb (GDB) 7.5-ubuntu ... This GDB was configured as "x86_64-linux-gnu". ... Core was generated by `./rtmpsrv'. Program terminated with signal 11, Segmentation fault. #0 0x00007f5285f3a4f4 in RTMPPacket_Free () from /usr/lib/x86_64-linux-gnu/librtmp.so.0 (gdb) bt #0 0x00007f5285f3a4f4 in RTMPPacket_Free () from /usr/lib/x86_64-linux-gnu/librtmp.so.0 #1 0x00007f5285f3be9d in RTMP_Close () from /usr/lib/x86_64-linux-gnu/librtmp.so.0 #2 0x00007f5285f3dae6 in ?? () from /usr/lib/x86_64-linux-gnu/librtmp.so.0 #3 0x00007f5285f3db6c in ?? () from /usr/lib/x86_64-linux-gnu/librtmp.so.0 #4 0x00000000004039a4 in doServe (server=server@entry=0x15b5160, sockfd=sockfd@entry=4) at rtmpsrv.c:906 #5 0x0000000000403b94 in serverThread (arg=0x15b5160) at rtmpsrv.c:974 #6 0x00007f5286155e9a in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #7 0x00007f5285c68cbd in clone () from /lib/x86_64-linux-gnu/libc.so.6 #8 0x0000000000000000 in ?? () (gdb) info stack #0 0x00007f5285f3a4f4 in RTMPPacket_Free () from /usr/lib/x86_64-linux-gnu/librtmp.so.0 #1 0x00007f5285f3be9d in RTMP_Close () from /usr/lib/x86_64-linux-gnu/librtmp.so.0 #2 0x00007f5285f3dae6 in ?? () from /usr/lib/x86_64-linux-gnu/librtmp.so.0 #3 0x00007f5285f3db6c in ?? () from /usr/lib/x86_64-linux-gnu/librtmp.so.0 #4 0x00000000004039a4 in doServe (server=server@entry=0x15b5160, sockfd=sockfd@entry=4) at rtmpsrv.c:906 #5 0x0000000000403b94 in serverThread (arg=0x15b5160) at rtmpsrv.c:974 #6 0x00007f5286155e9a in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #7 0x00007f5285c68cbd in clone () from /lib/x86_64-linux-gnu/libc.so.6 #8 0x0000000000000000 in ?? () (gdb) info registers rax 0x0 0 rbx 0x4 4 rcx 0x10 16 rdx 0x1 1 rsi 0x7f5285cea420 139992408957984 rdi 0x4 4 rbp 0x10027 0x10027 rsp 0x7f52843f3a20 0x7f52843f3a20 r8 0x10 16 r9 0x0 0 r10 0x7f52843f37c0 139992382781376 r11 0x7f5285f3a4f0 139992411383024 r12 0x7f527c0008c0 139992244422848 r13 0x0 0 r14 0x7f52843f3aef 139992382782191 r15 0x3 3 rip 0x7f5285f3a4f4 0x7f5285f3a4f4 <RTMPPacket_Free+4> eflags 0x10202 [ IF RF ] cs 0x33 51 ss 0x2b 43 ds 0x0 0 es 0x0 0 fs 0x0 0 gs 0x0 0 (gdb) ... """
On Tue, Oct 30, 2012 at 9:54 PM, Kristian Erik Hermansen wrote:
Trunk release built today is causing core dump in rtmpsrv with my test case.
You have failed to include a link to the page in question.
On Tue, Oct 30, 2012 at 8:03 PM, Steven Penny <svnpenn@gmail.com> wrote:
You have failed to include a link to the page in question.
It is located on an Intranet site RFC1918 address, so including it will not help you. However, I do have a packet dump if you like -> http://goo.gl/d0zrV
On Tue, Oct 30, 2012 at 10:16 PM, Kristian Erik Hermansen wrote:
It is located on an Intranet site RFC1918 address, so including it will not help you.
Taking a recent thread on stream-recorder http://stream-recorder.com/forum/help-me-friends-plssssssssssssss-t14254.htm... Give this example page http://desistreams.tv/embed/colors_hq.php Using this page with "git HEAD" appears fine. $ ./rtmpsrv RTMP Server v2.4 (c) 2010 Andrej Stepanchuk, Howard Chu; license: GPL Streaming on rtmp://0.0.0.0:1935 WARNING: Trying different position for client digest! rtmpdump -r "rtmp://95.211.197.48/app" -a "app" -f "WIN 11,4,402,278" -W "http:/ /188.122.91.7/player-licensed.swf" -p "http://www.fcast.tv/embed.php?live=colors tvlive1&vw=600&vh=430" -y "color" -o color.flv Closing connection... done! RTMPDump v2.4 (c) 2010 Andrej Stepanchuk, Howard Chu, The Flvstreamer Team; license: GPL Connecting ... INFO: Connected... Starting download at: 0.000 kB INFO: Metadata: INFO: author INFO: copyright INFO: description INFO: keywords INFO: rating INFO: title INFO: presetname Custom INFO: creationdate Tue Oct 30 21:20:50 2012 1026.084 kB / 28.86 sec
On Tue, 30 Oct 2012, Kristian Erik Hermansen wrote:
Trunk release built today is causing core dump in rtmpsrv with my test case. I have used rtmpsrv successfully many times previously using the stable 2.4 release. Looks like a memory management bug to me, but I could also be missing something entirely. The latest stable builds will not work for me since I am looking to leverage the new functionality for additional RTMP types / codes...
This sounds to me like you have an old librtmp.so in your system lib paths somewhere, and your newly built rtmpsrv tries to use those instead of the one you actually built. // Martin
On Wed, 31 Oct 2012 10:51:42 +0200 (EET), Martin Storsjö wrote:
On Tue, 30 Oct 2012, Kristian Erik Hermansen wrote:
Trunk release built today is causing core dump in rtmpsrv with my test case. I have used rtmpsrv successfully many times previously using the stable 2.4 release. Looks like a memory management bug to me, but I could also be missing something entirely. The latest stable builds will not work for me since I am looking to leverage the new functionality for additional RTMP types / codes...
This sounds to me like you have an old librtmp.so in your system lib paths somewhere, and your newly built rtmpsrv tries to use those instead of the one you actually built.
why i prefer to make static builds. -compn
On Wed, Oct 31, 2012 at 1:51 AM, Martin Storsjö <martin@martin.st> wrote:
This sounds to me like you have an old librtmp.so in your system lib paths somewhere, and your newly built rtmpsrv tries to use those instead of the one you actually built.
Correct. The solution for me and for anyone else that runs into this issue is as below, assuming you are already in the rtmpdump-trunk build directory. """ $ LD_LIBRARY_PATH=$LD_LIBRARY_PATH:librtmp; ./rtmpsrv $ LD_LIBRARY_PATH=$LD_LIBRARY_PATH:librtmp; ./rtmpdump ... """ Thanks for the assist. So, I was missing something rather naively...
participants (4)
-
compn -
Kristian Erik Hermansen -
Martin Storsjö -
Steven Penny