tStringlist отказывает умирать на выходе из программы

[Stilet]

Turbine

Что бы все споры были отброшены и "некоторые умники" перестали делать свои советовбросы бессмысленные приложи сюда код программы целиком. Иначе еще постов 20 бесполезных будет.

[Turbine]

Сообщение от Stilet

Что бы все споры были отброшены и "некоторые умники" перестали делать свои советовбросы бессмысленные приложи сюда код программы целиком. Иначе еще постов 20 бесполезных будет.

Спасибо за совет.!
Но это свыше 50000 строк кода, десяток модулей и данные для обработки свыше 17 мб. И такая странная ошибка, поэтому спросил из-за чего может быть такое? Решение нашлось. Оно противоречит здравому смыслу. Но благодаря нему все встало на все места.
Спасибо!

[Stilet]

И какое же решение нашлось?

[Turbine]

Сообщение от Stilet

И какое же решение нашлось?

Перенести temp_1: tStringList; в другое место раздела public того же компонента.

А до этого его не получалось освободить перед завершение программы в отличие от других tStringList.
И ReportMemoryLeaksOnShutdown показывал утечку именно в temp_1

[Stilet]

Т.е. изначально он был описан в секции, где обычно описываются вложенные компоненты класса?

[Turbine]

Да. Это было ошибочным решением?

[Stilet]

Ну не то чтобы совсем ошибочным, однако не рекомендуемым.
Насколько я помню D6 была строга - никаких левых свойств в главной секции класса. D2009 это позволяла. По крайней мере не ругалась у меня на такие исходники, хотя я по привычке как мог их адаптировал под нормальное состояние. ИМХО это уже зависит от компилятора, поэтому лучше не рисковать, и подобные "неVCLные" свойства хранить в секциях Private или Public.

[Turbine]

Сообщение от Stilet

ИМХО это уже зависит от компилятора, поэтому лучше не рисковать, и подобные "неVCLные" свойства хранить в секциях Private или Public.

В том то и дело... что оно было в паблик, в паблике и осталось, только в другом месте.

[Stilet]

В таком случае я не "понимайтен".

[StriderX]

Сообщение от Stilet

В таком случае я не "понимайтен".

Скорее всего просто где-то повреждает память приложения. Это не обязательно запись мимо массива. Есть и нюансы со строками, и со связкой dll\exe, и какой-нибудь мискаст указателя и т.п.
В своё время занимались перестановкой "asm nop end" строчкой выше\ниже пока не нашли источник проблем %)
По диагностике. Если есть стабильное воспроизведение, то иногда выходит проще найти повреждённые данные и поставить бряк на запись по адресу.