res2001

Крашится на free скорее всего из-за того, что у вас где-то выход за границу массива и вы перезаписываете служебные данные менеджера памяти. Нужно искать выходы за границу массива.

1.Как минимум ошибка при realloc - вы увеличиваете массив только 1 раз, а что если строка попадется очень длинная и нужно будет еще увеличивать буфер?
Вам нужно в getlen передавать текущий размер буферов и возвращать из нее новый размер, если был realloc.
Кроме того нужно определить до какого максимального предела вы готовы увеличивать буфера - память не безграничная (даже виртуальная) и если буфера вырастают за допустимый предел - нужно выдать ошибку и завершить программу.

2. В del_spacetab лишние условия в if:
if ((*p1)[i] == ' ' || (*p1)[i] == '\t' && (*p1)[i] != '\n')
Если я все правильно понимаю, то не равенство с '\n' тут излишне, или может быть не хватает скобок. Обычно, если в логическом выражении нужно использовать и || и &&, то для большей читаемости нужно использовать скобки для точного определения того что вы хотите сказать этим выражением.
Следующим else if - вы обнуляете счетчик на каждом не пробельном символе ...
Ну и функция del_spacetab не делает то что вы хотите - она просто возвращает количество "пробельных" символов, потом вы при копировании их не отбрасываете.

3.В функциях, кроме getline, не нужно передавать двойные указатели на буфера - достаточно простых указателей.
В getline нужны двойные указатели потому что в случае увеличения размера буфера вы должны через них вернуть указатели на новые буфера. В остальных функциях это не требуется.

PS: Запустите программу под отладчиком и отслеживайте все изменения состояния (переменных) в ручную.

Выделяете динамически первоначальный размер памяти, читаете в него заданное количество символов (по размеру буфера), если конца строки не было, делаете resize буферу, дочитываете, проверяете конец строки и т.д.
Можно читать по 1 символу и сразу его проверять на конец строки, но память при этом так же нужно увеличивать при необходимости. Медленнее скорее всего не будет, т.к. стандартная библиотека делает буферизацию по умолчанию, т.е. фактически все равно будет читаться не по 1 байту.

Память работает просто - туда можно писать и читать из нее. Еще она плоская и одномерная. Еще она виртуальная, но для прикладного программиста - это не важно, виртуальностью занимается ОС. Нужна она для того чтоб один процесс не видел что делается в другом процессе (например, в MS-DOS не было виртуальной памяти и любая программа могла запросто уронить ОС просто записав что-нибудь не нужное в память занимаемую системой), чтоб каждый процесс имел 4 Гб (для х32 приложений) адресуемой памяти не зависимо от физического наличия этой памяти.
Кроме самой памяти есть еще регистры процессора, но о них вспоминают только переходя к ассемблеру, т.к. даже Си не умеет ими манипулировать (оно и не нужно на самом деле).
Процессы и потоки - это сущности ОС предназначенные для параллельного выполнения кода. Реально выполняются потоки, а процесс - это оболочка для объединения нескольких потоков в одном адресном пространстве. В любом процессе есть хотя бы 1 поток.
Реальную параллельность можно достичь только тогда когда физических ядер процессора >1. Причем, обычно, вы никак не можете регулировать когда у вашего потока ОС отберет процессорное время, а когда снова даст. Это можно делать только выставляя уровень приоритета потока/процесса.
Поток отличается от процесса тем, что у двух разных процессов разные адресные пространства (виртуальная память в действии) и им для общения нужно использовать какие-либо механизмы межпроцессорного взаимодействия (сокеты, pipe, shared memory, файлы, ...) предоставляемые ОС. Потоки одного процесса работают в одном адресном пространстве, поэтому для взаимодействия им ничего изобретать не нужно, т.к. они просто могут обращаться к одной и той же переменной. Но тут сразу возникает состояние "гонки" и все что с этим связано. Чтоб как-то упорядочить одновременное обращение к участкам памяти или кода нужны мьютексы и т.п. средства. Между тем, в простых случаях, можно запросто обходится и без мьютексов просто грамотно структурировав код и в правильном порядке обращаясь к "общим" участкам памяти. Если это понимать, то писать многопоточные приложения становится не сильно сложно.
Думаю можно начать с прочтения какой-нибудь толстой книги про теорию построения ОС, например Таненбаума.
А Си - да полезно, но если вы этим денег не зарабатываете, то скорее всего не нужно.
WEB, PHP, JS, CSS и т.п. питоны, как правило, далеки от железа и ОС, на которых это все функционирует.

Вот здесь:
a[dd + 1]
выход за границы массива на последней итерации цикла.