Начало » Программирование » Delphi » Как найти ошибки в программе, которые портят память? Что такое Assertion Error в SafeMM и как искать 
	
		
		
			| Как найти ошибки в программе, которые портят память? Что такое Assertion Error в SafeMM и как искать [сообщение #6022] | 
			Mon, 21 April 2025 14:27   | 
		 
		
			
				
				
				
					
						  
						Svetlana95
						 Сообщений: 5 Зарегистрирован: April 2025 
						
					 | 
					Junior Member  | 
					 | 
		 
		 
	 | 
 
	
		Добрый день! 
 
 
 
У меня есть приложение на Delphi 7 - примерно 800 тысяч строк, приложение регулярно дорабатывается. 
 
Использую FastMM для работы с памятью. В целом работает нормально - но иногда возникают странные глюки у клиентов и невозможно понять, в чём дело. 
 
Подозрение на то, что какой-то код в приложении портит оперативную память. Но не могу найти, что за код, потому что ошибки возникают случайным образом. 
 
Что было сделано для решения проблемы: 
 
1) Убраны все Hints и Warnings при компиляции приложения (было около 2000 штук). Исправлено несколько ошибок. 
 
2) Включены опции Range Check и Overflow Check - причём не только у меня - но и в версии, распространяемой клиентам. Сразу в первые недели удалось найти около 10 ошибок и исправить. 
 
3) Освобождение памяти Free заменено везде в программе на FreeAndNil (да, читала статьи GunSmoker про это). Тоже позволило исправить несколько ошибок. 
 
4) Может, немного некрасивое и временное решение проблемы - но поправила FastMM4, чтобы при запросе на выделение памяти он выделял в 1,5 раза больше, чем нужно +150 байт сверху. В принципе, памяти у большинства клиентов хватает, а кому не хватает - сделана возможность вручную регулировать выделение памяти по формуле size = m * size0 + a (где m - мультипликатор, a - доп. байты). Например, если m = 1.0, a = 0 - тогда лишняя память не выделяется. Если m = 1.5, а = 200 - то на каждый блок памяти выделяется в 1,5 раза больше, чем нужно + 200 байт. 
 
Остроту проблемы это временно сняло. Но однако, проблемы и глюки всё равно остались, хоть и стало их в 5 раз меньше. Хочется найти ошибки и их исправить. Полагаю, ошибки могут быть не только в моём коде, но и в VCL и в Indy - в частности, EurekaLog ругается на работу IdHttp в потоке - а он мне нужен, чтобы читать содержимое нужной веб-страницы с Интернета. 
 
EurekaLog + FastMM (Full Debug Mode) при часовом прогоне на моём компьютере ошибок не находят (кроме ошибок IdHttp в потоке - но это не моя вина, наверное). 
 
 
Если же запустить программу под SafeMM менеджером памяти - появляется куча ошибок Assertion Error, которые укаазывают на строку 437 в SafeMM - но непонятно, как это поможет найти ошибку. Если убрать IdHttp - всё равно ошибки AssertionError остаются. Вопрос такой - что делать с Assertion Error, где искать ошибки, чтобы их не было? Ведь не показывается адрес памяти, где ошибка, просто какой-то непонятный Assertion Error. 
 
Что делать с ошибками в программе, как их найти - и как добиться того, чтобы программа запускалась с менеджером памяти SafeMM без AssertionError (имею ввиду, как найти эти ошибки, а не отключить отображение ошибки)? 
 
 
 
 
 
		
		
		
 |  
	| 
		
	 | 
 
 
 |  
	| 
		
 |  
	| 
		
 |  
	| 
		
 |  
	| 
		
 |  
	| 
		
 |  
	| 
		
 |  
	
		
		
			| Re: Как найти ошибки в программе, которые портят память? Что такое Assertion Error в SafeMM и как искать [сообщение #6043 является ответом на сообщение #6040] | 
			Sun, 27 April 2025 00:50    | 
		 
		
			
				
				
				
					
						  
						Svetlana95
						 Сообщений: 5 Зарегистрирован: April 2025 
						
					 | 
					Junior Member  | 
					 | 
		 
		 
	 | 
 
	| 
		Не то, чтобы сильно глючит. Так, подглючивает немного. Проявляется это в том, что у клиентов иногда появляются странные сообщения, они просто их закрывают и продолжают работу. Иногда примерно раз в неделю в случайное время программа вылетает. Но в целом жить можно. 4 года было непонятно, в чём дело. Тут, кажется, дошло - но не факт это единственное, что глючит - как раз дело в потоках - и программный код для работы с потоками не является потокобезопасным. Проблему с потоками решаю сейчас с помощью применения CriticalSection во всех сомнительных местах (благо на всю программу то, что работает в потоках занимает от силы 5-10 строк кода, всё остальное выполняется в основном потоке и не должно глючить). И действительно, после применения CtriticalSection глючить стало меньше, но полностью глюки не ушли, это похоже не единственное что есть.
		
		
		
 |  
	| 
		
	 | 
 
 
 |  
	| 
		
 |   
Переход к форуму:
 
 Текущее время: Tue Nov 04 16:38:18 GMT+3 2025 
 Общее время, затраченное на создание страницы: 0.00841 секунд 
 |