FreeBSD 13.1-RELEASE releng/13.1-n250148-fc952ac2212 GENERIC amd64 sox-14.4.2_5 using libmad-0.16.0 (both via pkg, then rebuilt for debugging) To reproduce: sox filename.mp3 out.wav (or) play filename.mp3 Workaround: ffmpeg -i filename.mp3 filename.wav sox filename.wav out.wav (or) play out.wav Invoking as 'sox' on certain files: * thread #1, name = 'sox', stop reason = signal SIGBUS * frame #0: 0x000000080043f194 libmad.so.0.16.0`mad_frame_init(frame=0x00007fffffffbed0) at frame.c:93:18 frame #1: 0x0000000800305ead libsox.so.3`mp3_duration_ms(ft=0x0000000801433900) at mp3-util.h:271:3 frame #2: 0x000000080030319b libsox.so.3`startread(ft=0x0000000801433900) at mp3.c:392:29 frame #3: 0x00000008002957b0 libsox.so.3`open_read(path="goldberg-variations-gould.mp3", buffer=0x0000000000000000, buffer_size=0, signal=0x000000080147f010, encoding=0x000000080147f030, filetype="mp3") at formats.c:545:32 frame #4: 0x0000000800294fe4 libsox.so.3`sox_open_read(path="goldberg-variations-gould.mp3", signal=0x000000080147f010, encoding=0x000000080147f030, filetype=0x0000000000000000) at formats.c:585:10 frame #5: 0x00000000002086d1 sox`main(argc=3, argv=0x00007fffffffe7e0) at sox.c:2945:20 frame #6: 0x0000000000207df0 sox`_start(ap=<unavailable>, cleanup=<unavailable>) at crt1_c.c:75:7 Invoking as 'play' on the same files gives a similar backtrace. Invoking as 'sox' on other files: * thread #1, name = 'sox', stop reason = signal SIGSEGV * frame #0: 0x0000000000000000 frame #1: 0x00000008003037b4 libsox.so.3`sox_mp3read(ft=0x0000000801433900, buf=0x00000008014c94c0, len=8192) at mp3.c:520:13 frame #2: 0x0000000800298aba libsox.so.3`sox_read(ft=0x0000000801433900, buf=0x00000008014c94c0, len=8192) at formats.c:978:30 frame #3: 0x0000000000212864 sox`sox_read_wide(ft=0x0000000801433900, buf=0x00000008014c94c0, max=8192) at sox.c:490:9 frame #4: 0x0000000000211daa sox`combiner_drain(effp=0x00000008014c8100, obuf=0x00000008014c94c0, osamp=0x00007fffffffe530) at sox.c:552:16 frame #5: 0x00000008002afbe7 libsox.so.3`drain_effect(chain=0x0000000801419040, n=0) at effects.c:352:17 frame #6: 0x00000008002af689 libsox.so.3`sox_flow_effects(chain=0x0000000801419040, callback=(sox`update_status at sox.c:1342), client_data=0x0000000000000000) at effects.c:445:11 frame #7: 0x000000000020ae67 sox`process at sox.c:1802:17 frame #8: 0x0000000000208afa sox`main(argc=3, argv=0x00007fffffffe7b8) at sox.c:3008:10 frame #9: 0x0000000000207df0 sox`_start(ap=<unavailable>, cleanup=<unavailable>) at crt1_c.c:75:7 Invoking as 'play' on the same files: Assertion failed: (factor > 0), function rate_init, file rate.c, line 303. * thread #1, name = 'sox', stop reason = signal SIGABRT * frame #0: 0x000000080091033a libc.so.7`__sys_thr_kill at thr_kill.S:4 frame #1: 0x0000000800888c74 libc.so.7`__raise(s=6) at raise.c:52:10 frame #2: 0x000000080093a109 libc.so.7`abort at abort.c:67:8 frame #3: 0x000000080086ba11 libc.so.7`__assert(func=<unavailable>, file=<unavailable>, line=<unavailable>, failedexpr=<unavailable>) at assert.c:51:2 frame #4: 0x00000008002c93a3 libsox.so.3`rate_init(p=0x00000008014a5048, shared=0x00000008014a5070, factor=-1.9999999962747097, bits=16, phase=50, bw_pc=67.625, anti_aliasing_pc=100, rolloff=rolloff_medium, maintain_3dB_pt=sox_false, use_hi_prec_clock=sox_false, interpolator=-1, max_coefs_size=400, noSmallIntOpt=sox_false) at rate.c:303:3 frame #5: 0x00000008002c8f98 libsox.so.3`start(effp=0x00000008014c8000) at rate.c:632:3 frame #6: 0x00000008002aed3a libsox.so.3`sox_add_effect(chain=0x0000000801419040, effp=0x00000008014c8000, in=0x00007fffffffe5f0, out=0x0000000801433c08) at effects.c:157:9 frame #7: 0x0000000000211adf play`add_effect(chain=0x0000000801419040, effp=0x00000008014c8000, in=0x00007fffffffe5f0, out=0x0000000801433c08, guard=0x00007fffffffe5ec) at sox.c:708:10 frame #8: 0x0000000000211b9f play`auto_effect(chain=0x0000000801419040, name="", argc=1, argv=0x00007fffffffe5e0, signal=0x00007fffffffe5f0, guard=0x00007fffffffe5ec) at sox.c:721:7 frame #9: 0x0000000000210d82 play`add_effects(chain=0x0000000801419040) at sox.c:1086:5 frame #10: 0x000000000020ac12 play`process at sox.c:1759:3 frame #11: 0x0000000000208afa play`main(argc=2, argv=0x00007fffffffe7c8) at sox.c:3008:10 frame #12: 0x0000000000207df0 play`_start(ap=<unavailable>, cleanup=<unavailable>) at crt1_c.c:75:7
@Reporter Could you: - confirm your ports tree or package is up to date - if not up to date, update and retry reproduction - include pkg version -v output (as an attachment) - if using ports: /etc/make.conf contents (if not empty)
(In reply to Kubilay Kocak from comment #1) Apologies, missed "(both via pkg, then rebuilt for debugging)"
Created attachment 234430 [details] pkg version -v Packages were upgraded to latest with 'pkg upgrade' and sox and its dependencies were reinstalled with 'pkg install -f'. To build with debugging symbols, I issued 'portsnap auto' and temporarily placed the following in /etc/make.conf (otherwise empty): WITH_DEBUG_PORTS= audio/sox audio/libmad DEBUG_FLAGS= -g -O0
(In reply to Benjamin Stoker from comment #0) This looks like a bug in libmad, where it internally defines a mad_fixed_t type as long, but in the public header that it installs, defines it as an int. Reverting to libmad-0.15.1b_7 seems to make it work again for me. The underlying problem is that there's a fixed.h file in the libmad source with this block: # if SIZEOF_INT >= 4 typedef signed int mad_fixed_t; typedef signed int mad_fixed64hi_t; typedef unsigned int mad_fixed64lo_t; # else typedef signed long mad_fixed_t; typedef signed long mad_fixed64hi_t; typedef unsigned long mad_fixed64lo_t; # endif , but SIZEOF_INT isn't defined in that header. It's defined in mad.h.in , which is installed as mad.h for other tools to use: # define SIZEOF_INT 4 # define SIZEOF_LONG 4 # define SIZEOF_LONG_LONG 8 A workaround might be to copy those defines into fixed.h so that the types inside libmad.so match the installed header. The real fix, imho, would be to get rid of all the SIZEOF defines and just use the standard int32_t/uint32_t types if a 32-bit variable is required. The defines aren't even generated by the config process - they're hardcoded, so it will probably break on other architectures.
(In reply to Dan Nelson from comment #4) Yes, that's it. It works with either int or long, provided the type is the same between the two files. Am I correct then that the proper solution (assuming the goal is to avoid wasting memory) would be something like: #include <stdint.h> typedef int32_t mad_fixed_t; ... and so on?
Created attachment 234433 [details] patch for libmad fixed.h
Created attachment 234434 [details] patch for mad.h.in
(In reply to Benjamin Stoker from comment #5) Yes, making the same changes to both fixed.h and mad.h.in ; something like the attached patches. I left FPM_INTEL unconditionally assigned, but my guess is that should be autodetected somehow as well.
(In reply to Dan Nelson from comment #7) Are these patches to be committed in audio/libmad, or does sox bundle/vendor libmad? audio/libmad was updated to 0.16.0 in ports 519c89efe3a9 by diizzy@ via bug 262874 ^Triage: Update title and request feedback accordingly
(In reply to Kubilay Kocak from comment #9) Those are patches for the audio/libmad port. Sox just links to the installed library.
Hi, Thanks for tracking this down and sorry for the breakage, instead of carrying it in our ports tree can you please submit a PR to upstream? https://github.com/tenacityteam/libmad Ultimately it would be great if SoX could use something else than libmad since it's old and very slow. Someone did add support for mpg123 but it only seems to be partial as far as I can tell, https://github.com/anaelorlinski/libsox . Maybe it also worth starting to track master branch like other distros as it seems to carry many bugfixes etc. Best regards, Daniel
^Triage: Re-classify per comment 10
^Triage: Correct assignment to maintainer, leave libmad ports update committer on feedback request
fyi, https://github.com/tenacityteam/libmad/pull/3
I plan to downgrade this port back to 0.15.1b temporarily but keep PORTVERSION as 0.16.0 for now to avoid PORTEPOCH.
If possible please test, https://github.com/tenacityteam/libmad/pull/3 It works for me
Created attachment 234588 [details] Patch for libmad (evaluation) Here's a patch that includes that pull request mentioned
(In reply to Daniel Engberg from comment #17) Thanks, I'll test it.
(In reply to Po-Chuan Hsieh from comment #18) Works for me on aarch64 and amd64 using FreeBSD 13.1, converting a mp3 file to wav using sox and madplay
Created attachment 234765 [details] Patch for libmad v2 This is now released as 0.16.1 by upstream Changelog: https://github.com/tenacityteam/libmad/releases/tag/0.16.1 sunpoet, as for as style consistency goes Porters Handbook explicitly tells you to use DISTVERSION with USE_GITHUB
Dan and Benjamin, can you please test my latest patch (which bumps libmad to 0.16.1), you need to rebuild users.
(In reply to Daniel Engberg from comment #21) It looks like the updated libmad version does solve the crashing issue in my quick tests.
(In reply to Daniel Engberg from comment #21) Yes, sorry for the slow response, but it does fix the crashes. I ran several sox commands on a couple hundred files without problems.
Thanks for testing! sunpoet, friendly ping
Updated as of e0b51d322893b00805bd3e233476f5983b692894