Здраствуйте
Извените, что сделаю перессылку на другую ветку форума, но появилась проблема, которая в ту тему неукладывается... (так начал строить сложносоченненые обороты => пора спать   ) 

дублирование вопроса,

У меня есть метод 
char* TProtocolPOP3::iFindFirstInt(char* pzStr,int& iNum);
В первый параметр передается указатель на строку. Символы в строке перебераются, пока не получу ближайшее число. Через второй параметр это число возвращается. А сама функция возвращает указатель на первый символ после числа в исходной строке, либо ноль при неудаче.

Но проблема не в этом методе, а в операции new.
Есть метод, который помогает узнать список писем.
TProtocolPOP3::GetListID(int*& piMessageID, int*& piMessageSize, int& iNumMessage)
При первом запуске iFindFirstInt(...) из полученого с сервера сообщения узнаю, сколько писем в списке.
    // ищем кол-во писем
    ptr = iFindFirstInt(psBuf,iNumMessage);
Но далее, пытаюсь выделить память, а оператор new возвращает NULL
    // создаем возвращаемые переменные
    piMessageID = new int [iNumMessage];
    piMessageSize = new int [iNumMessage];
    if(piMessageID==NULL)return 0;
    if(piMessageSize==NULL)return 0;
Вопрос, почему в данной ситуации new не выделяет память? Как сделать так, чтоб память выделялась?

P.S. Такая фигня в VC7, в VC6 все  нормально работает


Это сообщение отредактировал(а) neosapient - 6.5.2007, 22:18

Присоединённый файл ( Кол-во скачиваний: 6 )
 Demo_problem2.rar 6,78 Kb

В обще-то странно. new не должен NULL возвращать по умолчанию.
Если память не выделить - должно быть исключение...
У вас в проверках точно двойное равно стоит, а не одинарное?

в 6 может еще и NULL он стандарт не поддерживает

Чего не знаю - того не знаю, не сталкивался.

Еще как вариант - если мусор в iNumMessage.

В приведенном фрагменте 
ptr = iFindFirstInt(psBuf,iNumMessage); 
ошибка, но в реальном коде ее скорее всего нет...

Первое, что приходит  в голову - значение iNumMessage какое-то нереальное. Поэтому память и не выделяется.

Немного смущает ссылка на указатель (int*&), но это, скорее всего, к делу не относится.

Согласен. 
neosapient, попробуй в этом месте еще и iNumMessage выводить, может он отрицательный или равный нулю.

Прежде, чем это удалось скомплировать, пришлось пофиксить кучу ошибок вида:

Это что, VC такое пропускает?   

Далее, как только выполнение программы дошло до строчки 

прога упала в segfault

Вскрытие показало:
1. В двух местах память выделяется оператором new[], а освобождается delete вместо delete[] => убивается работоспособность heap
2. strсat везде по коду также убивают heap. Например

Дальше смотреть не стал, и так всё понятно  В таких условиях надо удивляться, что выполнение вообще доходит до вызова new[iNumMessage]

Это сообщение отредактировал(а) srd - 7.5.2007, 07:09

Так, все понятно: специалисты "высокого уровня" среди нас

Это ты к чему? При сломанном heap'е любой вызов new/delete может приводить к падению программы в неожиданных местах. Разве есть сомнения?   

srd, спасибо за ответ


Да допускает, хотя и выдает предупреждение. 



Развею сомнения, которые высказывались другими участниками этой ветки форума, насчет некоректного значения iNumMessage - с числом всё нормально.
В VC7 прога не падала, просто оператор new выдавал NULL.

Что такое "segfault"?




Нашел только одно место в методе iFindFirstInt к указателю ptr3, исправил - локально заработало, но при нескольких вызовах (и других методов) программа падает. :(

Где ещё упустил?



Не, мне кажется, что здесь всё в порядке, так как я не меняю сам указатель на массив указателей MailMessage

Если я не прав, то поправь меня?

И ещё теряется память при использовании A=strcat(A,B), по указателю A?
Если да, то чем удалять память, возвращенную функцией strdup(const char*), функцией free или delete?

Это сообщение отредактировал(а) neosapient - 7.5.2007, 13:07

Так делать нельзя :(

К тому же, например, в функции TProtocolPOP3::GetListID() не указано возвращаемое значение для "нормального" сценария. Есть только return 0 в случае ошибки. При этом возвращаемое значение проверяется в другом месте:


Короче, варнинги надо читать и думать, откуда они берутся 


Попытка обратиться по несуществующему адресу в памяти, или попытка выполнить какую-то операцию с участком в памяти, для которого такая операция запрещена. Например, запись в область, доступную только для чтения и т.д.


В функции GetStream => delete MailMessage


Функция strdup выделяет памяти столько, сколько надо, чтобы туда влезла копируемая строка.



strcat не выделяет память. Она пишет в конец строки А и считает, что буфер A достаточно большой, чтобы туда ещё влезло и B.
И возвращает она тот же буфер, который ты передал первым параметром.


только free.

Немного подредактировал

- методы возвращают значения
- добавил GetStream => delete[] MailMessage

Но ошибка осталась

Присоединённый файл ( Кол-во скачиваний: 5 )
 Demo_problem3.rar 6,83 Kb

Это шо такое? (Функция большая, поэтому лишнее покоцано)



Выделяем 6 байт (через strdup()), а записываем фиг знает сколько (через strcat())?

Ну и дальше там подобное встречается.

Упс, srd уже написал про это.


Это сообщение отредактировал(а) Hurricane - 7.5.2007, 16:30

Угу, ошибки со strdup/strcat не пофиксены.

Знаю, только руки не дошли.
Да вроде и не от этого проблемы 

Ладно, сейчас подменю на буфферы

srd, специалистом высокого уровня я назвал neosapient, т.к. код у него какой-то не такой... ужасный.

neosapient, на будущее: если компилятор выводит предупреждения, то значит что-то не так, предупреждения иногда бывают страшнее ошибок, т.к. если на них не обращать внимание, то потом могут выскакивать оочень страшные результаты, а ты даже не сможешь толком понять из-за чего, т.к. вроде как ошибки-то и не было.

Я не программист - я просто учусь

Так пойдет

Это сообщение отредактировал(а) neosapient - 8.5.2007, 14:59

Присоединённый файл ( Кол-во скачиваний: 4 )
 TProtocolPOP3.rar 7,09 Kb

neosapient, ну тогда ладно 

  
Когда видишь такое название темы: "оператор new стал откровенно плохо работать".
Хочется ответить: наверное ему мало платят, или у него проблемы в семье...

Ну почему не назвать тему: я где-то накосячил выделением памяти?
Это ведь не просто придирка: ты автоматически следуешь ходу своих мыслей, а думаешь ты, что это new плохо работает или ошибка в компиляторе или синтаксис C++ неправильный или что-то в этом роде.
Что править в коде, тебе написали. А чобы самому научится эффективно искать ошибки, нужно выпрямить себе мозги: искать ошибку всегда у себя в коде, в логике.
Это странно, но, похоже, все начинающие программисты по первости валят на компилятор. И у меня тоже так было...
Еще раз извините за оффтопик... навеяло...

+1 оффтопик 
Earnest, так он и не говорит что компилятор виноват, а дает что-то вроде краткого описания проблемы, то что через какое-то время использования оператор new действиетльно работает плохо, т.к. должен выделять память, а он этого не делает.

Так пока не подсказа ли, что где то накасячил, и незнал как назвать
Такое поведение оператора new мне было незнакомо

И ещё по опыту общения на этом форуме: называть тему надо ярко, иначе тебе никто не поможет - просто не обратят внимания на твой вопрос.

К слову код считается завершенным, всмысле есть ещё видимые (не видимые) утечки памяти?

Это сообщение отредактировал(а) neosapient - 8.5.2007, 23:16

  

  

Несогласен. По своему, хоть и не очень большому, опыту.

  

Не согласен категорически. На этом форуме как раз иногда на такую фигню отвечают! Причем терпеливо и вежливо. 
Обращают внимание на все.