justdan96
segfault with cli demuxing m2ts if track parameter absent
using nightly-2021-12-12-02-06-49 with hand-crafted meta file i got segfault if I forgot to specify track parameter in meta file.
this meta works:
$ cat bd.meta
MUXOPT --blu-ray --no-asyncio
V_MPEG4/ISO/AVC, /data/data/com.termux/files/home/tmp/bd_20211123-061432/bd.m2ts, fps=29,97, track=4113
A_MP3, /data/data/com.termux/files/home/tmp/bd_20211123-061432/stream.mp3
$
remove track param = segfault.
Additionally, it seems tsmuxer clamps fps to integer value at least in diag output?
$ ./tsmuxer bd.meta udf.iso
tsMuxeR version 2.6.16-dev. github.com/justdan96/tsMuxer Decoding H264 stream (track 1): Profile: [email protected] Resolution: 720:480i Frame rate: 29.97
H.264 manual defined fps doesn't equal to stream fps. Change H.264 fps from 29.97 to 29
4.2% complete
Decoding MPEG-Audio stream (track 2): Bitrate: 64Kbps Sample Rate: 48KHz Channels: 2 Layer: 3
Processed 46 video frames
100.0% complete
Flushing write buffer
Creating Blu-ray stream info and seek index
Creating Blu-ray playlist
Mux successful complete
Finalize ISO disk
Muxing time: 0 sec
$
@Randrianasulu I can't reproduce the issue: if I remove track param from .meta, I have message error "For streams inside TS/M2TS container need track parameter". Can we please have a sample creating this fault ?
Have you tried replacing the "29,97" with "29.97" in the .meta ? The second error likely comes from there. Edit: maybe even the first error comes from there ;)
On Sunday, December 12, 2021, jcdr428 @.***> wrote:
@Randrianasulu https://github.com/Randrianasulu I can't reproduce the issue: if I remove track param from .meta, I have message error "For streams inside TS/M2TS container need track parameter". Can we please have a sample creating this fault ?
yes, i'll upload to somecloud in a moment...
Have you tried replacing the "29,97" with "29.97" in the .meta ?
yes, i completely missed fact ',' used as element separator... no problem with rounded 29 if I use '.' as separator in fps value...
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/justdan96/tsMuxer/issues/505#issuecomment-991853803, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJSS7TJLLBVUL44XQ6ZE7GTUQRLSRANCNFSM5J36NERQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
https://cloud.mail.ru/public/ZxY9/x7M4N7FyN
bd.m2ts and bd.meta (I can upload arm binary of tsmuxer too... but I guess it will be harder to debug cross-arch)
@Randrianasulu sorry I can't help, no segfault or other issues with Windows / Visual Studio. I've never explored debugging cross-arch...
No repro on Linux either. Running with the same metafile with the track parameter removed doesn't even cause Valgrind to report any invalid reads/writes which could've hinted at the underlying problem. All references to the track parameter also seem to be guarded with ifs in order to handle the case that it might not exist.
A stack trace would be useful, as it would at least point to a specific function where the crash occurred : perhaps it's not even related to the track parameter at all.
BTW. --no-asyncio doesn't do anything on Linux.
@xavery it might be again a problem of locale (fps=29,97 in .meta)...
Unfortunately, even running with LC_ALL=ru_RU.UTF-8 LANG=ru_RU.UTF-8 doesn't change the behaviour at all, i.e. there's no crash.
The only thing that we can - perhaps - take from all this is to treat unparsable float/double values as an error and quit right away. This would eliminate the confusing "H.264 manual defined fps doesn't equal to stream fps. Change H.264 fps from 29.97 to 29" if you've just got a decimal point/comma mismatch due to the locale settings, or using a metafile created in a different locale.
On the other hand, we do use C++17 now, which means that std::from_chars is available. This function gives us locale-independent float/double parsing (i.e. the decimal point is always .), which is the way it should've been from the beginning. For backwards compatibility, we could just try replacing all , with . in memory and retrying parsing if it fails.
backtrace probably specific to libc++ (clang/llvm)
tsMuxeR version 2.6.16-dev. github.com/justdan96/tsMuxer
Program received signal SIGSEGV, Segmentation fault.
0xf7a10072 in std::__ndk1::__shared_count::__release_shared() ()
from /data/data/com.termux/files/usr/lib/libc++_shared.so
(gdb) bt full
#0 0xf7a10072 in std::__ndk1::__shared_count::__release_shared() ()
from /data/data/com.termux/files/usr/lib/libc++_shared.so
No symbol table info available.
#1 0xf79fcbc8 in std::__ndk1::locale::~locale() ()
from /data/data/com.termux/files/usr/lib/libc++_shared.so
No symbol table info available.
#2 0xf79f4aa8 in std::__ndk1::basic_streambuf<char, std::__ndk1::char_traits<char> >::~basic_streambuf() ()
from /data/data/com.termux/files/usr/lib/libc++_shared.so
No symbol table info available.
#3 0x00421352 in std::__ndk1::basic_ostringstream<char, std::__ndk1::char_traits<char>, std::__ndk1::allocator<char> >::~basic_ostringstream() ()
No symbol table info available.
#4 0x0042119e in std::__ndk1::basic_ostringstream<char, std::__ndk1::char_traits<char>, std::__ndk1::allocator<char> >::~basic_ostringstream() ()
No symbol table info available.
#5 0x0045b9a2 in METADemuxer::addStream(std::__ndk1::basic_string<char, std::__ndk1::char_traits<char>, std::__ndk1::allocator<char> >, std::__ndk1::basic_string<char, std::__ndk1::char_traits<char>, std::__ndk1::allocator<char> > const&, std::__ndk1::map<std::__ndk1::basic_string<char, std::__ndk1::char_traits<char>, std::__ndk1::allocator<char> >, std::__ndk1::basic_string<char, std::__ndk1::char_traits<char>, std::__ndk1::allocator<char> >, std::__ndk1::less<std::__ndk1::basic_string<char, std::__ndk1::char_traits<char>, std::__ndk1::allocator<char> > >, std::__ndk1::allocator<std::__ndk1::pair<std::__ndk1::basic_string<char, std::__ndk1::char_traits<char>, std::__ndk1::allocator<char> > const, std::__ndk1::basic_string<char, std::__ndk1::char_traits<char>, std::__ndk1::allocator<char> > > > > const&) ()
No symbol table info available.
--Type <RET> for more, q to quit, c to continue without paging--
#6 0x00459da2 in METADemuxer::openFile(std::__ndk1::basic_string<char, std::__ndk1::char_traits<char>, std::__ndk1::allocator<char> > const&) ()
No symbol table info available.
#7 0x00473764 in MuxerManager::openMetaFile(std::__ndk1::basic_string<char, std::__ndk1::char_traits<char>, std::__ndk1::allocator<char> > const&) ()
No symbol table info available.
#8 0x0044d754 in main ()
No symbol table info available.
(gdb)
I see there was some refactoring since I compiled this version, will try to update my build and see if bug persist..
@Randrianasulu there seems to be a problems with the nightly uploads, please tests latest build for your platform from https://github.com/justdan96/tsMuxer/actions
So it's not an ordinary ARM build, but a build for Android specifically on top of that. Thanks.
Bizarre... metaDemuxer.cpp line 481, tsMuxer shouldn't even go there unless there is a mov/mp4/m4v/m4a in the meta file ?
Running a build compiled with clang and using libc++ similarly yields no crash under x86-64. Running such a build with valgrind reports no issues. I presume the issue as described here might be caused by our own code, or it might be related to that specific ARM build or that specific clang/libc++ combination which said build uses when running. Perhaps tsmuxer was built with headers for a different libc/libc++ than the one used at runtime? On the other hand, if that were the case, then the binary would probably crash much earlier...
A build that I attempted with a qemu-simulated ARM machine also processes these files correctly and doesn't crash. I have to admit that I'm out of ideas here.
Coming back to this one - for a quick fix shall we just replace commas with full stops for the FPS parameter?
commas with full stops for the FPS parameter?
You do understand the actual fps is 30/1.001? That (30000/1001) is what we use in ffmpeg and it is different.
... can this issue come from badly (re) defined THROW? (if such thing even possible..)