Re[7]: new + delete = Access Violation? Как быть? - C/C++

Проблема такова:

void MyFunc(void)
{
char *buf;

buf=new char[10];
...
delete buf;

buf=new char[5];
...
delete buf;  /// Вот здесь выходит Access Violation ???


}

Почему так происходит? И как с этим боротся?

P.S. Пишу на MSVC 6.

Заранее благодарен!

Здравствуйте, FlashBack, Вы писали:

FB>Проблема такова:

...

FB>Почему так происходит? И как с этим боротся?

FB>P.S. Пишу на MSVC 6.

Нельзя освобождать память выделенную new[] при помощи delete. Нужно использовать delete[].

char * a = new char[10]; delete [] a;

А в твоем случае я бы подумал над заменой массивов на vector<char> или string. Тогда и вовсе не прийдется заботиться об выделении и освобождении памяти.

Здравствуйте, alexkro, Вы писали:

A>Нельзя освобождать память выделенную new[] при помощи delete. Нужно использовать delete[].

A>char * a = new char[10]; delete [] a;

Спасиба огромное. Теперь всё ок!

Здравствуйте, FlashBack, Вы писали:

A>>Нельзя освобождать память выделенную new[] при помощи delete. Нужно использовать delete[].

A>>char * a = new char[10]; delete [] a;

FB>Спасиба огромное. Теперь всё ок!

Ответ alextro совершенно правилен. Объекты типа 'массив' должны освобождаться именно при помощи 'delete[]', а не 'delete'. Но одной из особенностей MSVC++ 6 является то, что для массивов 'char' ошибочное применение 'delete' вместо 'delete[]' не приводит к каким-либо проблемам, не говоря уже об access violation. Так что проблема в твоем случае заключалась не в этом. Советую еще раз внимательнее просмотреть и протестировать код. Если все, что ты исправил, это замена 'delete' на 'delete[]', то этот access violation ты еще увидишь.

Здравствуйте, Андрей Тарасевич, Вы писали:

ААТ>Ответ alextro совершенно правилен. Объекты типа 'массив' должны освобождаться именно при помощи 'delete[]', а не 'delete'. Но одной из особенностей MSVC++ 6 является то, что для массивов 'char' ошибочное применение 'delete' вместо 'delete[]' не приводит к каким-либо проблемам, не говоря уже об access violation. Так что проблема в твоем случае заключалась не в этом. Советую еще раз внимательнее просмотреть и протестировать код. Если все, что ты исправил, это замена 'delete' на 'delete[]', то этот access violation ты еще увидишь.

Кокда появился Access Violation я просто закомментировал все delete и всё стало ок. А сейчас дописал с исправлением и всё работает, так что я думаю проблема была всё же в этом

Совершенно с Вами согласен. Я так понимаю, что так как имеется тип char у которого нет нетривиального деструктора, в случае MSVC не важно, как удалять — все равно размер массива перед его элементами не хранится и удалено все будет нормально. Так что ошибку надо искать.

Здравствуйте, FlashBack, Вы писали:

FB>Кокда появился Access Violation я просто закомментировал все delete и всё стало ок. А сейчас дописал с исправлением и всё работает, так что я думаю проблема была всё же в этом

И все-таки, не поленись, и преведи весь код.

Здравствуйте, FlashBack, Вы писали:

ААТ>>Ответ alextro совершенно правилен. Объекты типа 'массив' должны освобождаться именно при помощи 'delete[]', а не 'delete'. Но одной из особенностей MSVC++ 6 является то, что для массивов 'char' ошибочное применение 'delete' вместо 'delete[]' не приводит к каким-либо проблемам, не говоря уже об access violation. Так что проблема в твоем случае заключалась не в этом. Советую еще раз внимательнее просмотреть и протестировать код. Если все, что ты исправил, это замена 'delete' на 'delete[]', то этот access violation ты еще увидишь.

FB>Кокда появился Access Violation я просто закомментировал все delete и всё стало ок. А сейчас дописал с исправлением и всё работает, так что я думаю проблема была всё же в этом

А теперь ради эксперимента попробуй в финальном коде заменить 'delete[]' назад на 'delete'. Если программа снова начнет падать, что мы получим очень ценный пример, наглядно демонстрирующий необходимость использования именно 'delete[]' для удаления массивов с элементами типа 'char'. До сих пор такого примера найти не удавалось.

Здравствуйте, Андрей Тарасевич, Вы писали:

АТ>А теперь ради эксперимента попробуй в финальном коде заменить 'delete[]' назад на 'delete'. Если программа снова начнет падать, что мы получим очень ценный пример, наглядно демонстрирующий необходимость использования именно 'delete[]' для удаления массивов с элементами типа 'char'. До сих пор такого примера найти не удавалось.

Пробовал.С "delete" без "[]" сразу виснет!

Здравствуйте, FlashBack, Вы писали:

FB>Пробовал.С "delete" без "[]" сразу виснет!

Я думал, на VC6 такого не может быть

А на будете ли Вы так любезны, привести код, достаточный для воспроизведения ошибки?

Очень хочется воспроизвести у себя, а не получается

Может все дело в настройках dsp?

Мне кажется, это может быть многим интерсно

Здравствуйте, Михаил Трухманов, Вы писали:

МТ>Я думал, на VC6 такого не может быть

МТ>А на будете ли Вы так любезны, привести код, достаточный для воспроизведения ошибки?

МТ>Очень хочется воспроизвести у себя, а не получается

МТ>Может все дело в настройках dsp?

МТ>Мне кажется, это может быть многим интерсно

+1

Здравствуйте, FlashBack, Вы писали:

FB>Здравствуйте, Андрей Тарасевич, Вы писали:

АТ>>А теперь ради эксперимента попробуй в финальном коде заменить 'delete[]' назад на 'delete'. Если программа снова начнет падать, что мы получим очень ценный пример, наглядно демонстрирующий необходимость использования именно 'delete[]' для удаления массивов с элементами типа 'char'. До сих пор такого примера найти не удавалось.

FB>Пробовал.С "delete" без "[]" сразу виснет! :beer:

Код, пожалуйста, на бис. Позволь нам убедится, что дело в действительн в [].

Здравствуйте, Artour Bakiev, Вы писали:

AB>Здравствуйте, FlashBack, Вы писали:

FB>>Здравствуйте, Андрей Тарасевич, Вы писали:

АТ>>>А теперь ради эксперимента попробуй в финальном коде заменить 'delete[]' назад на 'delete'. Если программа снова начнет падать, что мы получим очень ценный пример, наглядно демонстрирующий необходимость использования именно 'delete[]' для удаления массивов с элементами типа 'char'. До сих пор такого примера найти не удавалось.

FB>>Пробовал.С "delete" без "[]" сразу виснет!

AB>Код, пожалуйста, на бис. Позволь нам убедится, что дело в действительн в [].

Вот кривой код:

void MyFunc(void)
{
char *buf;

buf=new char[10];
printf(buff,"Test");
delete buf;

buf=new char[15];
printf(buff,"Test");
delete buf;  /// Вот здесь выходит Access Violation ???


}

Вот рабочий код:

void MyFunc(void)
{
char *buf;

buf=new char[10];
printf(buff,"Test");
delete [10] buf;

buf=new char[15];
printf(buff,"Test");
delete [10]buf;  /// Вот здесь  Access Violation нету!


}

Здравствуйте, FlashBack, Вы писали:

FB>Вот кривой код:
FB>

FB>void MyFunc(void)
FB>{
FB>char *buf;

FB>buf=new char[10];
FB>printf(buff,"Test");
FB>delete buf;

FB>buf=new char[15];
FB>printf(buff,"Test");
FB>delete buf;  /// Вот здесь выходит Access Violation ???

FB>}
FB>

FB>Вот рабочий код:

FB>

FB>void MyFunc(void)
FB>{
FB>char *buf;

FB>buf=new char[10];
FB>printf(buff,"Test");
FB>delete [10] buf;

FB>buf=new char[15];
FB>printf(buff,"Test");
FB>delete [10]buf;  /// Вот здесь  Access Violation нету!
FB>}
FB>

Оба варианта кривые.
В строках

printf(buff,"Test");

видимо не printf, a sprintf и не buff, a buf?

А вот

delete [10]buf;

насколько я понимаю — синтаксическая ошибка, которую VC почему-то не ловит. Надо писать delete[] buf;

Я попробовал — VC6 может принимать в квадратных скобках какой угодно тип, например этот код компилируется и правильно

работает:

struct A {} a;
char* p = new char[10];
delete[a] p;

Короче VC6 игнорирует этот "аргумент" и вызывает

void operator delete[](void* p);

либо встроенный, либо переопределенный.

Здравствуйте, folk, Вы писали:

[]

F>А вот
F>

F>delete [10]buf;
F>

F>насколько я понимаю — синтаксическая ошибка, которую VC почему-то не ловит. Надо писать delete[] buf;

F>Я попробовал — VC6 может принимать в квадратных скобках какой угодно тип, например этот код компилируется и правильно

работает:
F>

F>struct A {} a;
F>char* p = new char[10];
F>delete[a] p;
F>

F>Короче VC6 игнорирует этот "аргумент" и вызывает
F>

F>void operator delete[](void* p);
F>

F>либо встроенный, либо переопределенный.

А Comeau заявил что это анахронизм:

"ComeauTest.c", line 5: error: delete array size expression used (anachronism)
  delete[5] p;
         ^

Видимо когда-то это было стандартом?

Здравствуйте, FlashBack, Вы писали:

FB>>>Пробовал.С "delete" без "[]" сразу виснет!

AB>>Код, пожалуйста, на бис. Позволь нам убедится, что дело в действительн в [].

FB>Вот кривой код:

FB>void MyFunc(void)
FB>{
FB>char *buf;

FB>buf=new char[10];
FB>printf(buff,"Test");
FB>delete buf;

FB>buf=new char[15];
FB>printf(buff,"Test");
FB>delete buf;  /// Вот здесь выходит Access Violation ???
FB>}

Не-а, этого кода не достаточно для AV, даже если исправить buff и buf на одно имя (чтоб компилилось).
И если исправить printf на sprintf, тоже не падает

Может там на самом деле больше кода? Может (вдруг) дело в dsp?

Хотелось бы увидеть весь код, необходимый для AV

Здравствуйте, Михаил Трухманов, Вы писали:

МТ>Здравствуйте, FlashBack, Вы писали:

FB>>>>Пробовал.С "delete" без "[]" сразу виснет!

AB>>>Код, пожалуйста, на бис. Позволь нам убедится, что дело в действительн в [].

FB>>Вот кривой код:
МТ>

FB>>void MyFunc(void)
FB>>{
FB>>char *buf;

FB>>buf=new char[10];
FB>>printf(buff,"Test");
FB>>delete buf;

FB>>buf=new char[15];
FB>>printf(buff,"Test");
FB>>delete buf;  /// Вот здесь выходит Access Violation ???
FB>>}

МТ>Не-а, этого кода не достаточно для AV, даже если исправить buff и buf на одно имя (чтоб компилилось).
МТ>И если исправить printf на sprintf, тоже не падает

МТ>Может там на самом деле больше кода? Может (вдруг) дело в dsp?

МТ>Хотелось бы увидеть весь код, необходимый для AV

А вот если не править printf на sprintf, то вполне достаточно чтобы упасть.

Здравствуйте, folk, Вы писали:

F>Здравствуйте, Михаил Трухманов, Вы писали:

FB>>>printf(buff,"Test");
FB>>>delete buf;  /// Вот здесь выходит Access Violation ???

МТ>>И если исправить printf на sprintf, тоже не падает

МТ>>Хотелось бы увидеть весь код, необходимый для AV

F>А вот если не править printf на sprintf, то вполне достаточно чтобы упасть.

Но только не на delete

И только если дело дойдет до чтения памяти, которую нам нельзя даже читать. (А это возможно, только если в мусоре, куда указывает buf(f) найдется что-то типа "%s"

)
В противном случае, в stdout просто пойдет мусор.
"Я так думаю"

Здравствуйте, Михаил Трухманов, Вы писали:

МТ>Здравствуйте, folk, Вы писали:

F>>Здравствуйте, Михаил Трухманов, Вы писали:

МТ>

FB>>>>printf(buff,"Test");
FB>>>>delete buf;  /// Вот здесь выходит Access Violation ???
МТ>

МТ>>>И если исправить printf на sprintf, тоже не падает

МТ>>>Хотелось бы увидеть весь код, необходимый для AV

F>>А вот если не править printf на sprintf, то вполне достаточно чтобы упасть.

МТ>Но только не на delete

Конечно же не на delete, но мы же видим насколько точны приводимые сведения...

МТ>И только если дело дойдет до чтения памяти, которую нам нельзя даже читать. (А это возможно, только если в мусоре, куда указывает buf(f) найдется что-то типа "%s"

)
МТ>В противном случае, в stdout просто пойдет мусор.
МТ>"Я так думаю"

Думаю если набрать статистику, то в большинстве случаев действительно не упадет. Но printf будет читать строку buf пока не встретит нуль-терминатор, так что вполне может нарваться на AV.

Здравствуйте, Андрей Тарасевич, Вы писали:

A>>>Нельзя освобождать память выделенную new[] при помощи delete. Нужно использовать delete[].

А наоборот? Выделяем new и new[], удаляем всегда delete[] ???

АТ> Но одной из особенностей MSVC++ 6 является то, что для массивов 'char' ошибочное применение 'delete' вместо 'delete[]' не приводит к каким-либо проблемам, не говоря уже об access violation.

Это особенность только MSVC?

	От:	FlashBack
	Дата:	18.05.03 19:17
	Оценка:

	От:	alexkro
	Дата:	18.05.03 19:27
	Оценка:	4 (1) +1

	От:	FlashBack
	Дата:	18.05.03 19:33
	Оценка:

	От:	Андрей Тарасевич
	Дата:	18.05.03 20:11
	Оценка:	54 (3) +3

	От:	FlashBack
	Дата:	19.05.03 05:56
	Оценка:

	От:	Михаил Трухманов
	Дата:	20.05.03 09:18
	Оценка:

	От:	folk
	Дата:	21.05.03 07:33
	Оценка:

	От:	folk
	Дата:	21.05.03 08:10
	Оценка:

	От:	Аноним
	Дата:	21.05.03 08:10
	Оценка: