irtlab / rtptools

RTP Tools
http://www.cs.columbia.edu/irt/software/rtptools/
Other
166 stars 64 forks source link

rtpdump segfaults #92

Open janstary opened 6 years ago

janstary commented 6 years ago

Running the trivial tests proposed in https://github.com/columbia-irt/rtptools/pull/91 reveals failures already.

While on some systems, ./rtpdump < bark.rtp works just fine, on this OpenBSD 6.2/ppc box:

$ ./rtpdump < bark.rtp                                        
Segmentation fault (core dumped) 

Some output formats (rtpdump -F) work, some don't:

$ ./rtpdump -F hex < bark.rtp
Segmentation fault (core dumped) 

$ ./rtpdump -F ascii < bark.rtp
Segmentation fault (core dumped)

$ ./rtpdump -F rtcp < bark.rtp
Segmentation fault (core dumped)

$ ./rtpdump -F short < bark.rtp 
-1.-00044 20000
0.000044 50000
0.000044 70000
0.000044 90000
0.000044 110000
0.000044 130000
0.000044 150000
0.000044 170000
0.000044 190000
0.000044 220000
0.000044 230000
0.000044 260000
0.000044 280000
0.000044 290000
0.000044 380000

$ ./rtpdump -F payload < bark.rtp > bark.raw 
fwrite: Bad address

$ ./rtpdump -F payload < bark.rtp            
tt@͒P    ͒0` @"@^@^@4}
[...]
Segmentation fault (core dumped) 

$ ./rtpdump -F dump < bark.rtp > dump.rtp            
$ ./rtpdump -F header < bark.rtp  > dump.hdr

The files dump.rtp and dump.hdr start, respectively, with

#!rtpplay1.0 0.0.16.0/59904
#!rtpplay1.0 0.0.16.0/11696

How did those numbers get there?

Also,

$ ls -l dump.* bark.raw                      
-rw-r--r--  1 hans  hans     0 Mar 31 17:16 bark.raw
-rw-r--r--  1 hans  hans  8044 Mar 31 17:13 dump.hdr
-rw-r--r--  1 hans  hans  2825 Mar 31 17:12 dump.rtp

so the payload dump didn't actually work, and saving just the headers is more than saving everything.

The -1.-00044 20000 seems strange too.

A similar thing happens on OpenBSD 6.3/armv7, except ./rtpdump -F payload < bark.rtp > dump.raw works, -F short gives

$ ./rtpdump -F short < bark.rtp  
-44.-00001 20000 3988999488
44.000000 50000 3988999648
44.000000 70000 3988999808
44.000000 90000 3988999968
44.000000 110000 3989000128
44.000000 130000 3989000288
44.000000 150000 3989000448
44.000000 170000 3989000608
44.000000 190000 3989000768
44.000000 220000 3989000928
44.000000 230000 3989001088
44.000000 260000 3989001248
44.000000 280000 3989001408
44.000000 290000 3989001568
44.000000 380000 3989001728

(compare to the -F short output above), and -F dump and -F header output starts with

#!rtpplay1.0 152.153.253.191/4618
#!rtpplay1.0 56.189.254.191/5415

Something is definitely amiss on a very basic level.

janstary commented 6 years ago

The very same works just fine on another OpenBSD 6.3/amd64 box, various linuxes, and one sparc machine (the bogus addr/port are still there though).