Решено: APPCRASH как искать или как исправить?

[Лекс Айрин]

Стек пока я увеличивать не буду, так как не смог понять что это и почему мне не хватает стандартного (у меня рекурсий нет).

Тут не обязательно рекурсия... возможно просто слишком глубоко вложенная процедура/функция с большим количеством параметров на каждом уровне вложенности. Каждая подпрограмма создает собственный "кадр" в стеке (резервирует место под собственные параметры вызова). Правда, я не думаю, что это касается данного случая. А стек... это особый сегмент данных для временного хранения данных необходимый для многих инструкций процессора.

[zub]

Получить стек

Если что - я имел ввиду стек вызовов на момент ошибки))

[azsx]

угу. Если быть точнее: это может стать поводом...

что делать? Я могу как то супер освобождать TStringList?

Построчное чтение из файла, или "кусками" не подойдут варианты?

нет, крайне долго. И для некоторых файлов почти невозможно.

Получить стек - отладить программу. Если стек не поможет - сделать подробный лог и ловить момент когда программа начинает вести себя нештатно

логи я сделаю, а вот что такое "Получить стек"?

Есть соответствующие инструменты для ловли утечек - ключик -gh

не знал.

Добавлено спустя 2 минуты 59 секунд:
и как получить "стек вызовов на момент ошибки"?

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

точно не мой случай, штук 6 процедур, работают по принципу отработал - вышел с процедуры. Запуск по времени каждую секунду с отключением таймера на время выполнения.

[pupsik]

Код: Выделить всё

  St:= TStringList.Create;
  try
    St.LoadFromFile(FName);
    Result:= St.Text
  finally
    St.Free
    end

по поводу этого участка... Вы уверены что он освобождается? А если исключение сработает? И, вполне возможно, где то ещё у вас собака "зарыта".
А теперь предположим.
Загрузили 100 метровый файлик, получили исключение, а программа работает и грузить новую порцию. И так несколько раз подряд...
Напрашивается странный вопрос: как среагирует система на подобное???

Добавлено спустя 6 минут 28 секунд:

что делать? Я могу как то супер освобождать TStringList?

повод и причина разное Я имел ввиду: смотря как работать. И да.. сам stringlist может быть поводом.

нет, крайне долго. И для некоторых файлов почти невозможно.

хм... Да же не знаю что сказать. Может вы не правильно готовите?

по времени каждую секунду с отключением таймера на

хм.. таймер, "исключение по тихому", переполнение...

[azsx]

Таким образом надо?

Код: Выделить всё

  St:= TStringList.Create;
  try
    St.LoadFromFile(FName);
    Result:= St.Text
  except
    St.Free
end 
finally
    St.Free
    end

[zub]

>>и как получить "стек вызовов на момент ошибки"?
Самый простой: Собрать программу с отладочной инфой. Запустить ее под GDB. Дождаться вылета или справоцировать вылет. Ввести bt. http://wiki.freepascal.org/Creating_a_B ... e_with_GDB
Элементарный способ проверки на утечки - посматривать в диспетчере задачь за динамикой отъедания вашей программой памяти у системы. Если вылет происходит по причине окончания памяти - это быдет видно.

[pupsik]

Код: Выделить всё

  Result := '';
  try
    St:= TStringList.Create;
    try
      St.LoadFromFile(FName);
     Result:= St.Text
    except
      //обработка исключения
   end;
  finally
    St.Free
end;


[zub]

Код: Выделить всё

  St:= TStringList.Create;
  try
    St.LoadFromFile(FName);
    Result:= St.Text
  finally
    St.Free
    end

Этот способ конечно рабочий, но содержит в себе кучу "ненужных" действий. Почему просто не выделить в Result нужный размер и не прочитать туда файл одним куском?

[pupsik]

zub

туда файл одним куском?

=

нет, крайне долго.

Добавлено спустя 3 минуты 7 секунд:
по поводу StringList - простое предположение... Возможно ошибка иная....

[azsx]

Загрузили 100 метровый файлик, получили исключение, а программа работает и грузить новую порцию. И так несколько раз подряд...
Напрашивается странный вопрос: как среагирует система на подобное???

в реальности файлы занимают мегабайты, обычно килобайты и по логике там исключений на чтение быть не должно. Но я проверю.
Зашел в процедуру, инициализировал объект, считал - передал результат вышел с процедуры. Разве TStringList после выхода с процедуры остался в оперативной памяти?

[Лекс Айрин]

Разве TStringList после выхода с процедуры остался в оперативной памяти?

может и остаться... рекомендуется очищать явно.

[zub]

zub

туда файл одним куском?

=

нет, крайне долго.

Добавлено спустя 3 минуты 7 секунд:
по поводу StringList - простое предположение... Возможно ошибка иная....

Как может самый быстрый способ чтения файла (влязящего в память 1м куском) медленнее кучи ненужных прокладок?

[pupsik]

в реальности файлы занимают мегабайты

возможно поэтому не столь быстро "срабатывает"?

Разве TStringList после выхода с процедуры остался в оперативной памяти?

В процедуре его создали, исключение.... он остался "мёртвым грузом", прога работает. Освобождается только после выхода из программы.

Повторяю: не зацикливайтесь... Возможно ошибка в ином.

п.с.
zub а это не я писал... Выше посмотрите

[azsx]

pupsik спасибо, я ошибся. Надо попробовать (заодно посмотрю есть ли там исключения).

Почему просто не выделить в Result нужный размер и не прочитать туда файл одним куском?

потому что это очень небольшой участок программы. Когда обработка переменной была проще и файлы формировались на другом компе я сотнями тысяч обрабатывал файлов в сутки. На практике способ с чтением через TStringList оказался самым быстрым. По сути я не разбирался почему другие методы мне показались медленее.

[zub]

Ок. завязываем телепатировать и ждем от ТС отчета heaptrc и стека. Там всё станет ясно