Curl crashes moc

Submitted by eugenez on Sat, 2019-08-24 09:04

Forums:

MOC version: 
2.5.2

Hello, friends!

I am one of moc package mainainers at NixOS repository.
https://github.com/aethelz/nixpkgs/blob/master/pkgs/applications/audio/moc/default.nix

A couple of month ago I did a major refactor of package to allow for pretty much all compilation options.

Unfortunately, I found out that even though moc works fine, it now segfaults on exit.

I narrowed it down to curl support flag. Without it, it exits gracefully.

I'm willing to provide any info necessary to debug this issue and willing to follow through.

Thank you very much in advance!

This is an excerpt from valgrind log pertaining to segfault (not sure if much help)

--13812-- Discarding syms at 0xffe5240-0xfff4a65 in /nix/store/hjk92a5igzjqvm73zdb49iq28zg6829c-speex-1.2.0/lib/libspeex.so.1.5.1 (have_dinfo 1) --13812-- Discarding syms at 0x10a922a0-0x10a92df3 in /nix/store/9f88spzzy73v1nmgn1vd8mif8r79j5iw-moc-2.5.2/lib/moc/decoder_plugins/libvorbis_decoder.so (have_dinfo 1) --13812-- Discarding syms at 0x10a98430-0x10a9ea1c in /nix/store/g2dayjij5aw16vig0fbj7cy246bhbsgj-libvorbis-1.3.6/lib/libvorbisfile.so.3.3.7 (have_dinfo 1) --13812-- Discarding syms at 0x10aa41c0-0x10aa4938 in /nix/store/9f88spzzy73v1nmgn1vd8mif8r79j5iw-moc-2.5.2/lib/moc/decoder_plugins/libwavpack_decoder.so (have_dinfo 1) --13812-- Discarding syms at 0x10aab400-0x10ac9392 in /nix/store/w6q7iy7f4k3zw8vfzrp537nrdvbmzamc-wavpack-5.1.0/lib/libwavpack.so.1.2.0 (have_dinfo 1) ==13812== Jump to the invalid address stated on the next line ==13812== at 0x100BEC50: ??? ==13812== by 0x24603D: ??? ==13812== by 0x2: ??? ==13812== by 0x3E8000041EC: ??? ==13812== by 0x63: ??? ==13812== Address 0x100bec50 is not stack'd, malloc'd or (recently) free'd ==13812== ==13812== ==13812== Process terminating with default action of signal 11 (SIGSEGV) ==13812== Access not within mapped region at address 0x100BEC50 ==13812== at 0x100BEC50: ??? ==13812== by 0x24603D: ??? ==13812== by 0x2: ??? ==13812== by 0x3E8000041EC: ??? ==13812== by 0x63: ??? ==13812== If you believe this happened as a result of a stack ==13812== overflow in your program's main thread (unlikely but ==13812== possible), you can try to increase the size of the ==13812== main thread stack using the --main-stacksize= flag. ==13812== The main thread stack size used in this run was 8388608. --13812-- Discarding syms at 0x10960070-0x10960bfe in /nix/store/c745s6cnnxy6c98bvhi0qsijrh3ikag1-glibc-2.27/lib/gconv/CP1250.so (have_dinfo 1)

eugenez

Sat, 2019-08-24 09:27

Actually it's a little bit more complicated than just curl. When BOTH ffmpeg and curl flags are on, it segfaults, when you disable either one of those flags, segfault are gone.

Debug info:

CAug 24 12:25:40.145520: log.c:119 log_signals_raised(): SIGINT Aug 24 12:25:40.145554: server.c:1748 server_loop(): Exiting... Aug 24 12:25:40.145578: server.c:678 server_shutdown(): Server exiting... Aug 24 12:25:40.146199: out_buf.c:134 read_thread(): exit Aug 24 12:25:40.146227: out_buf.c:190 read_thread(): exiting Aug 24 12:25:40.146336: out_buf.c:259 out_buf_destroy(): buffer destroyed Aug 24 12:25:40.146369: player.c:355 precache_wait(): Precache thread is not running Aug 24 12:25:40.146606: softmixer.c:252 softmixer_write_config(): Softmixer configuration written Aug 24 12:25:40.146629: softmixer.c:64 softmixer_shutdown(): Softmixer stopped Aug 24 12:25:40.146763: equalizer.c:478 equalizer_write_config(): Equalizer configuration written Aug 24 12:25:40.146783: equalizer.c:519 equalizer_shutdown(): Equalizer stopped Aug 24 12:25:40.146834: tags_cache.c:683 reader_thread(): Exiting tags reader thread Aug 24 12:25:40.147065: server.c:686 server_shutdown(): Server exited Segmentation fault (core dumped)

jcf

Sat, 2019-08-24 10:07

Could you provide me with the specific releases of cURL and FFmpeg which you are using, and the specific flags involved, please.

Feel free to do so by e-mail to mocmaint as it usually expedites matters.

eugenez

Sat, 2019-08-24 11:25

Wow. This is uncanny. This issue been bothering me for the past two month ago, and just when I got around to debug and solve it, a PR updating some OpenSSL stuff gets merged into NixOS a day ago and now everything works as it should. I'm not sure how OpenSSL interacts with moc (maybe through curl?) but it seems like this is definitely not a moc issue ))

Sorry to disturb you for nothing, glad that the issue resolved itself ))

Thank you very much for making moc!

jcf

Sat, 2019-08-24 20:17

That was an easy fix... for me anyway.

This issue been bothering me for the past two month ago, ...

I'm just glad I didn't get too far into chasing this as a MOC bug.

I'm not sure how OpenSSL interacts with moc (maybe through curl?)...

MOC does not currently use cURL's SSL support and neither does it make explicit use of it in OpenSSL, but maybe these libraries are initialising it when they are themselves intialised. You say that having both cURL and FFmpeg configured are a prerequiste to trigger this segfault, so maybe OpenSSL being intialised or finalised from both cURL and FFmpeg was causing the dereferencing of already free()ed memory with OpenSSL during termination.

Possibly cURL and FFmpeg libraries were previously linked against different OpenSSL library versions and that was causing a conflict.

Sorry to disturb you for nothing, glad that the issue resolved itself

I don't mind being disturbed by someone who is willing to participate in the debugging of their problem. What I [bold]do[/bold] mind is when people initiate debugging then go silent leaving the problem unresolved and the debugging effort wasted.

So in recognition of your having updated me as to the resolution of this problem, I grant you licence to use MOC free of charge forever.