Malloc assertion failure / core dump on youtube commands

[andrewrembrandt]

Issue

Description

When running any of the youtube commands a malloc assertion failure always causes tizonia to core dump, for exmaple:

>  tizonia --youtube-audio-stream https://www.youtube.com/watch\?v\=mnc9pvuvSuk
tizonia 0.22.0. Copyright (C) 2020 Juan A. Rubio and contributors
This software is part of the Tizonia project <https://tizonia.org>

tizonia: malloc.c:2617: sysmalloc: Assertion `(old_top == initial_top (av) && old_size == 0) || ((unsigned long) (old_size) >= MINSIZE && prev_inuse (old_top) && ((unsigned long) old_end & (pagesize - 1)) == 0)' failed.
[1]    1210203 IOT instruction (core dumped)  tizonia --youtube-audio-stream https://www.youtube.com/watch\?v\=mnc9pvuvSuk

Steps to Reproduce

1. Run with any of the youtube commands

Expected behavior:

Not core dump / malloc assertion failure

Actual behaviour:

Not core dump / malloc assertion failure

Reproduces how often:

Everytime

Versions

tizonia 0.22.0. Copyright (C) 2020 Juan A. Rubio and contributors
This software is part of the Tizonia project <https://tizonia.org>

Dependency Info:

* [Boost 1_78]
* [TagLib 1.12.0]
* [MediaInfoLib - v22.03]
* [gmusicapi 13.0.0 ]
* [soundcloud 0.5.0 ]
* [youtube-dl 2021.12.17 ]
* [pafy 0.5.5 ]
* [pycountry 22.3.5 ]
* [titlecase 2.2.0 ]
* [pychromecast 12.1.2 ]
* [plexapi 4.10.0 ]
* [spotipy 2.19.0 ]
* [fuzzywuzzy 0.18.0 ]
* [eventlet 0.33.0 ]
* [python-Levenshtein 0.12.2 ]
* [joblib 1.1.0 ]

System Info:

Linux@5.17.6-zen1-1-zen-#1 ZEN SMP PREEMPT Tue, 10 May 2022 23:00:41 +0000
NAME="Arch Linux"
PRETTY_NAME="Arch Linux"
ID=arch
BUILD_ID=rolling
ANSI_COLOR="38;2;23;147;209"
HOME_URL="https://archlinux.org/"
DOCUMENTATION_URL="https://wiki.archlinux.org/"
SUPPORT_URL="https://bbs.archlinux.org/"
BUG_REPORT_URL="https://bugs.archlinux.org/"
LOGO=archlinux-logo

Installation Method Used

Arch linux, aur, same with both the tizonia-all and tizonia-all-git packages

Additional Information

I ran a debug build under valgrind, and the issue might be pretty easy to fix (many of these):

==1054519== Invalid read of size 8
==1054519==    at 0x484F947: memmove (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==1054519==    by 0x702B3D3: class_ctor (tizobject.c:126)
==1054519==    by 0x702B72B: ctor (tizobject.c:204)
==1054519==    by 0x702B66D: factory_new (tizobject.c:183)
==1054519==    by 0x702D488: tiz_api_class_init (tizapi.c:671)
==1054519==    by 0x702A68D: os_register_type (tizobjsys.c:455)
==1054519==    by 0x702A8AC: register_base_types (tizobjsys.c:491)
==1054519==    by 0x702AB7F: tiz_os_register_base_types (tizobjsys.c:558)
==1054519==    by 0x702825D: init_servants (tizscheduler.c:2591)
==1054519==    by 0x7021A3B: do_init (tizscheduler.c:829)
==1054519==    by 0x7027044: dispatch_msg (tizscheduler.c:2322)
==1054519==    by 0x702753E: il_sched_thread_func (tizscheduler.c:2410)
==1054519==  Address 0x6c50f70 is 0 bytes after a block of size 64 alloc'd
==1054519==    at 0x484AA83: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==1054519==    by 0x490E56E: tiz_mem_calloc (tizmem.c:64)
==1054519==    by 0x702B8AF: tiz_class_init (tizobject.c:252)
==1054519==    by 0x702A68D: os_register_type (tizobjsys.c:455)
==1054519==    by 0x702A8AC: register_base_types (tizobjsys.c:491)
==1054519==    by 0x702AB7F: tiz_os_register_base_types (tizobjsys.c:558)
==1054519==    by 0x702825D: init_servants (tizscheduler.c:2591)
==1054519==    by 0x7021A3B: do_init (tizscheduler.c:829)
==1054519==    by 0x7027044: dispatch_msg (tizscheduler.c:2322)
==1054519==    by 0x702753E: il_sched_thread_func (tizscheduler.c:2410)
==1054519==    by 0x5A363DC: start_thread (in /usr/lib/libc.so.6)
==1054519==    by 0x5ABB2C3: clone (in /usr/lib/libc.so.6)
==1054519==

Full log attached:
valgrind-out.txt

[zlocate]

Same issue.