У менеджера памяти явно какая-то проблема в многопоточности, такое ощущение, что одна и та же расшаренная структура, описывающая распределение памяти, используется во всех потоках и всё хорошо работает если потоки имеют идентичные по структуре данные. Но стоит одному из них немного отличиться, один поток меняет структуру, все остальные валятся к чёртовой бабушке т.к. полагают, что структура такая, какой они её формировали. Отсюда такие дикие адреса, по которым они обращаются, отсюда же нормальная работа некоторых потоков на фоне вылета остальных - для них структура "подошла".

А у менеджера ли

Если всё так, то да, у менеджера - косвенная проблема, а прямая вина тех, кто делал многопоточность, конечно (исключая разработчиков ОС, не о них речь). Справедливости ради, это не так то просто отловить, но вполне реально. Но лично мне некогда возиться с многопоточной трассировкой, так что могу понять, почему было оставлено так, как есть. Тем более, сейчас ускорилось железо, сильно, изменились механизмы работы ОС, да и наученные горьким опытом, разработчики, похоже, не злоупотребляют потенциально опасными полиморфными динамическими структурами данных в разных экземплярах потоков. Потому для многих это - "дела давно минувших дней":


Я тоже смутно припоминаю подобное в некоторых схемах. Менял на однопоточные иили применял другие элементы, всё работало и забывал об этом, отметив в памяти, чего стоит избегать. А на новых ПК и ОС ещё реже встречалось по описанным выше причинам, так и жили )

А может, все же, в неправильной работе с потоками. Если потоки не синхронизированны по доступу к одному и тому же участку памяти, то результат может быть налицо. Зря, что ли, придумали критические секции, вот только реализованно ли это все на глобальном уровне ключевой библиотеки, которая писалась сравнительно давно

nesco, я об этом и говорю. Древний менеджер, похоже, не подразумевал многопоточности, а разработчики в дальнейшем это не учли, когда её делали. Возможно, у них таки вышли обновления иили новые версии среды Delphi, но наш-то форк замер в веках с наследственными болезнями. Ну, да это всё софистика, однако факт на лицо - вылетает именно менеджер памяти, вылетает потому, что конфликтует сам с собой из другого потока, не поделили одну и ту же секцию. Кто виноват - догадываемся, на "что делать" ответ, вероятно, "методом тыка подбирать условия, при которых проблема не проявляется", избегать лишних потоков в частности.

Как я уже говорил, не будем же мы все элементы переписывать, где слишком часто встречаются операции с динамической памятью.

Или синхронизировать их при помощи элемента кртической секции -- SafeMode (посыпаю голову пеплом , я забыл написать про него в wiki)

nesco, да и MutexThread не сильно документирован и снабжён примерами, ИМХО, потому никто нигде его и не использовал, из тех схем, что я видел. Думаю, стоит объяснить в справке, зачем вообще это нужно.

Кстати, что насчёт механизма синхронизации для потоков, порождённых таймером?

Таймер синхронизирован с главным потоком приложения, и с его очередью событий, не вижу никаких проблем запускать из него наследованный поток, а вот наоборот -- запускать таймер из порожденного потока крайне нежелательно. Точнее, можно, но только со входа SyncExec, тк этот выход синхронизирован с главным потоком

Иногда, без этого трудно работать, особенно с интернет приложениями и сетью. Там уже не рад, что его не поставил, такие глюки основного потока наблюдаются при нарушении работы с сетью, что мама не горюй. Или запускашь звук, и что, будешь сидеть и ждать, когда же он проиграет
------------ Дoбавленo в 13.45:
1nd1g0, сложностей не должно возникать с доп потоками, если четко представлять себе работу с ними. Но, увы, рядовые пользователи об этом мало чего знают, отчего и пытаются выводить данные прямо в контролы, забывая (или не зная), что так делать нельзя. Или запустят два потока с одним промежутком времени и одним потоком читаю, а другим пытаются писать в массив, что тут будет, сам черт не знает. Как правило, через определенное время вся конструкция благополучно слетает

nesco, в cmd выполняешь
получается очень даже красивый файл
а после нашего doConsoleExec, если записать из StrList в файл -- такой бардак !

Ну, а что ты хотел -- что имеем, то и имеем