> В программе активно пользуется AnsiString может ли из-за > него сьедаться память? А вылетает программа на выполнении > функции IntToStr()! AnsiString в билдере сам заботится о памяти под строку или ему надо буфер? Если надо выделять, то возможно, как уже сказано, не выделен буфер. Лучший способ борьбы с переполнениями - понять что переполняется и проверять границы выделенной памяти.
Для нахождения утечек лучше пользоваться специальными отладочными версиями malloc/free или new/delete. Можно также пользоваться чем нибудь типа BoundsChecker-а, или специальными отладочными библиотеками (ищи в гугле по запросам типа memory leak debugging, memory leak detection) - существуют бесплатные версии.
Работая в Билдере 6.0, программа велетает из-за переполнения буфера, но немогу понять где утечка, есть ли какая тулся для этого дела???
В программе активно пользуется AnsiString может ли из-за него сьедаться память? А вылетает программа на выполнении функции IntToStr()!
[C++] Мысли недоспециалиста о шаманстве21.01.04 00:57 Автор: void <Grebnev Valery> Статус: Elderman
> Работая в Билдере 6.0, программа велетает из-за > функции IntToStr()!
Прошу прощения, что вмешиваюсь.
Не зная проект в подробностях трудно сказать наверняка, конечно. Но...
Было замечено в некоторых случаях, что когда, например,
Вы пытаетесь записать в мембер String str некоторого класса, "расположенного" в dll, то возникает аналогичная ситуация.
Здесь не имеется ввиду известная ситуация с передечей String str в качестве прараметра в функцию в dll. Передаваться может и LPCSTR.
В этих случаях я (особо не разбираясь в чём дело) в конструкторе тех классов инициализировал String str = "". Это делалось переде первым осмысленным обращением к мембер переменной String str.
Попробуйте инициализировать String str = "" где-то в начале программы. А только затем выполнять IntToStr. Может и поможет.
ПС. Могу ошибаться в той части, где именно это было - или в BC++ с классом String, или в VC++ с классом CString.
Я тоже в билдере весьма часто пишу. Никаких глюков со...19.01.04 02:08 Автор: Killer{R} <Dmitry> Статус: Elderman Отредактировано 19.01.04 02:15 Количество правок: 1
Я тоже в билдере весьма часто пишу. Никаких глюков со строками не видел. Код бы глянуть.. Если он не слишком большой. Что касается IntToStr. Я замечал что .ToInt() под 98й виндой не любит большие числа - переполнения буфера не происходит а просто преобразование вылетает типа это неправильный интежер. Потому я обычно юзаю atoi, да и с ним результирующий код кстати получается меньше. Может и у тебя чтото подобное... Попробуй itoa, правда он немного неудобен.
Кода много, даже очень, поэтому невыложить! а с IntToStr(),...19.01.04 02:22 Автор: CrazyPitbull Статус: Незарегистрированный пользователь
Кода много, даже очень, поэтому невыложить! а с IntToStr(), то вылетает, то нет...
Вообще всё это дело пашет в отдельном потоке, и несмотря, на то, что все действия по работе с интерфейсом и компонентами я синхронизирую, глюки вылетают при обращении к нему(время от времени)...Кстате, при обращении к компаненту, уоторого невидно(типо TTimer) нужно синхронизироваться или нет?
так бы и сказал что много... и с потоками..19.01.04 02:30 Автор: Killer{R} <Dmitry> Статус: Elderman
> Кода много, даже очень, поэтому невыложить! а с IntToStr(), > то вылетает, то нет... > Вообще всё это дело пашет в отдельном потоке, Что ты для создания потока юзаешь?
>и несмотря,
> на то, что все действия по работе с интерфейсом и > компонентами я синхронизирую, Как именно?
>глюки вылетают при обращении
> к нему(время от времени)...Кстате, при обращении к > компаненту, уоторого невидно(типо TTimer) нужно > синхронизироваться или нет? Вообще надо независимо видимый компонент или нет. Но если ты тока со своего потока к нему обращаешься то конкретно в случае с TTimer наверно необязательно. Потому как там тока SetTimer\KillTimer юзается при работе с ним.
для создания потока, отнаследую свой класс от TThread, поток...19.01.04 02:46 Автор: CrazyPitbull Статус: Незарегистрированный пользователь
для создания потока, отнаследую свой класс от TThread, поток запускается, в нём создаёться цикл, который крутиться всё время, пока я его не прибью... Одна итерация успешна, далее ошибки... Синхронизирую при помощи Synhronize()...
Есть идеи?
> Есть идеи? Есть.
Project->Options->CodeGuard Validation поможет найти обращения к левым адресам, срывы стека и прочую фигню. Очень полезно юзать его для отлова неочевидных багов, каким твой имхо и является.
В ANSI C нет itoa19.01.04 02:19 Автор: amirul <Serge> Статус: The Elderman
> чтото подобное... Попробуй itoa, правда он немного > неудобен. Не знаю как с этим в билдере. Но в качестве перевода из int в string я всегда использовал sprintf
Отсталый человек :)19.01.04 14:52 Автор: Ktirf <Æ Rusakov> Статус: Elderman
> > чтото подобное... Попробуй itoa, правда он немного > > неудобен. > Не знаю как с этим в билдере. Но в качестве перевода из int > в string я всегда использовал sprintf stringstream::operator<< не модно, нет? :)
По существу могу сказать только то, что в проекте, в котором я сейчас занят, itoa переписано с сигнатурой примерно такой: string itoa(int); с перегрузками для других числовых типов. И не надо мне про производительность :) И вообще говоря, ничто не мешает написать template <typename T> anytoa(const T &);
А я на Plain C пишу - там stringstream-а нет :-)19.01.04 16:07 Автор: amirul <Serge> Статус: The Elderman
> Не знаю как с этим в билдере. Но в качестве перевода из int > в string я всегда использовал sprintf Ну енто по вкусу. Зато имхо atoi пошустрее будет потому как ему не надо разбирать исходные параметры. Если конечно не нужны всяки примочки типа добивания числа ноликами.
[C++] Утечка или переполнение?18.01.04 20:43 Автор: amirul <Serge> Статус: The Elderman
> В программе активно пользуется AnsiString может ли из-за > него сьедаться память? А вылетает программа на выполнении > функции IntToStr()! AnsiString в билдере сам заботится о памяти под строку или ему надо буфер? Если надо выделять, то возможно, как уже сказано, не выделен буфер. Лучший способ борьбы с переполнениями - понять что переполняется и проверять границы выделенной памяти.
Для нахождения утечек лучше пользоваться специальными отладочными версиями malloc/free или new/delete. Можно также пользоваться чем нибудь типа BoundsChecker-а, или специальными отладочными библиотеками (ищи в гугле по запросам типа memory leak debugging, memory leak detection) - существуют бесплатные версии.
[C++] Прошу прощения если я спутал терминологию!19.01.04 00:46 Автор: CrazyPitbull Статус: Незарегистрированный пользователь
Дело в том, что программа вылетает в дизасемблер на команде push, как я могу представить это из-за того, что места больше нету, т.е. буфер переполнен, а происходит это в следствии того, что гдето я забыл поставить delete, в этом месте память и утекает :), вот и встал вопрос о программе кс помощью которой я смог бы отследить время жизьни той или иной переменной(это как максимум) или как минимум отслеживать действия с памятью!
Спасибо, что откликнулись!
[C++] Команда push не только ложит на стек значение19.01.04 02:15 Автор: amirul <Serge> Статус: The Elderman
> Дело в том, что программа вылетает в дизасемблер на команде > push, как я могу представить это из-за того, что места До того, как положить, она еще и вычисляет его. Например команда
push [0]
---
совершенно однозначно приведет к Access Violation. На C эквивалентом будет попытка выложить на стек разыменованный указатель, который равен NULL:
---
char *ptr = NULL;
printf("%x", *ptr);
---
Уж лучше приведи участок кода - попробуем разобраться (хотя я борланд и не сильно люблю)
С кодом сложно, его слишком много, могу сказать, что там...19.01.04 02:43 Автор: CrazyPitbull Статус: Незарегистрированный пользователь
С кодом сложно, его слишком много, могу сказать, что там пользуется динамическая память, и причём очень часто!!! Вроде я везде прибиваю её!
Вот ещё ошибка вылетает обращения в стандартную длелелину билдера, говорит, что не в тот адрес лезу!
Хотелось бы все таки услышать какое исключение генерируется?19.01.04 16:12 Автор: Cyril <sc> Статус: Member
> С кодом сложно, его слишком много, могу сказать, что там > пользуется динамическая память, и причём очень часто!!! На свете слишком много программ где используется динамическая память, причем весьма часто ;-)
Весь код приводить и не требуется, попробуй выбросить все лишнее что не относиться к месту ошибки, совсем не обязательно приводить все детали реализации или там действительно все так тесно завязано?
> Вроде я везде прибиваю её! > Вот ещё ошибка вылетает обращения в стандартную длелелину > билдера, говорит, что не в тот адрес лезу! Если можно, то попробуй реализовать то, что выполняется в потоке как отдельную функцию и запустить ее в главном потоке, это гораздо проще отладить, чем в многопоточном приложении.
очень вряд ли19.01.04 01:24 Автор: dl <Dmitry Leonov>
Чтобы при нынешних объемах памяти ее утечка могла привести к ошибкам переполнения - это практически нереально (опять же, с этим можно бороться, проверяя результат операции выделения памяти). Разве что определено какое-то совсем смешное значение размера стека, но симптомы были бы совсем другие, да и в данном случае, как я понимаю, все равно память выделяется в куче, а не на стеке.
переполнение и утечка - две большие разницы18.01.04 20:23 Автор: dl <Dmitry Leonov>
подробно о проекте
Анализ криптографических сетевых...
новое сообщение
закрытая нитка
новое сообщение
в закрытой нитке
старое сообщение
