|
|
|
access violetion при приведении node->data к типу структуры
|
|||
|---|---|---|---|
|
#18+
Вот структура Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. Вот код где иногда, примерно один раз из 50 возникает ошибка Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.02.2005, 07:41 |
|
||
|
access violetion при приведении node->data к типу структуры
|
|||
|---|---|---|---|
|
#18+
Мб трётся память кем-то другим, и не здесь. Чекать всякими там BoundsChecker'ами -- единственное, что могу посоветовать. Потому что здесь ИМХО всё правильно и даже не вызывает подозрений. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.02.2005, 07:51 |
|
||
|
access violetion при приведении node->data к типу структуры
|
|||
|---|---|---|---|
|
#18+
if Node->Data != NULL Хммм , наверное это забыли ? ш (';') (V),(V),, Код: plaintext ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.02.2005, 07:55 |
|
||
|
access violetion при приведении node->data к типу структуры
|
|||
|---|---|---|---|
|
#18+
JibSkeartif Node->Data != NULL Хммм , наверное это забыли ? Да, надо будет поставить такое условие, хотя в моем случае этого нигде не должно быть, ибо со всеми узлами дерева связана такая структура и в большинстве случае это работает. Но если происходит такой сбой, то все, капец, только перезапуск проги помогает, начинает на всех узлах выскакивать... Подскажите еще пожалуйста - а почему такое исключение не перехватывается блоком Код: plaintext Cast3 Мб трётся память кем-то другим, и не здесь. Чекать всякими там BoundsChecker'ами -- единственное, что могу посоветовать. Потому что здесь ИМХО всё правильно и даже не вызывает подозрений. А как это делать, что это такое? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.02.2005, 09:53 |
|
||
|
access violetion при приведении node->data к типу структуры
|
|||
|---|---|---|---|
|
#18+
А вот интересно, в каком месте выделяется память для структуры и в каком она освобождается? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2005, 02:44 |
|
||
|
access violetion при приведении node->data к типу структуры
|
|||
|---|---|---|---|
|
#18+
archezА вот интересно, в каком месте выделяется память для структуры и в каком она освобождается? :-) вот кусок побольше, дальше примерно то же самое... освобождается на событие delete каждой ноды. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. авторif Node->Data != NULL Хммм , наверное это забыли ? попробовал Код: plaintext ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2005, 07:36 |
|
||
|
access violetion при приведении node->data к типу структуры
|
|||
|---|---|---|---|
|
#18+
а что делается в функции PTypeID ? ш (';') (V),(V),, Код: plaintext ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2005, 12:37 |
|
||
|
access violetion при приведении node->data к типу структуры
|
|||
|---|---|---|---|
|
#18+
JibSkeartа что делается в функции PTypeID ? Это не функция.... Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. Я не силен в C++, но по-моему это указатель на структуру типа TTypeID. Я взял это из встроенной справки и немного переделал под свои нужды. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2005, 13:22 |
|
||
|
access violetion при приведении node->data к типу структуры
|
|||
|---|---|---|---|
|
#18+
Если я правильно понимаю, - у тебя код выделяющий память висит на OnExpanding. Т.е. каждый раз когда пользователь разворачивает ветку происходит удаление всего что ниже этого узла и новое выделение памяти для подструктуры? Я бы предложил другое решение: инициализировать всю структуру разом по OnCreate. Если необходимо динамическое изменение структуры, то либо переинициализировать всю структуру заново (предварительно удалив ее и освободив память) по событию, в случае если структура большая и ее создание отнимает много времени, отслеживать добавление/удаление каждого элемента и выделять/освобождать память именно для него, а не для всей ветки. Непонятны такие моменты: 1 Выделяется ли память для элементов корневого уровня. Потому что при OnExpanding предполагается что память для Node->Data уже выделена. Иначе ты пытаешься записать что-то туда куда нельзя. 2 Освобождается ли память, для элементов подструктуры. Т.е. если OnExpanding происходит для 1-го уровня, то освободится ли память для 2-го, 3-го и ниже уровней, если нет - то утечка памяти. 3 И еще, я не уверен в корректности этого кода: TypeID *raz; ... while (...) { ... raz = new (TypeID); ... NewRaz->Data=raz; ... } Освобождает память наверно что-то вроде: delete NewRaz->Data; Я бы попробывал так: NewRaz->Data=new (TypeID); 4 Из личного опыта - когда код срабатывает 50 раз, а на 51 вылетает, то почти всегда это утечка памяти. Ищи где ты забыл освободить память. Удачи! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.03.2005, 02:50 |
|
||
|
access violetion при приведении node->data к типу структуры
|
|||
|---|---|---|---|
|
#18+
void __fastcall TMainform::TreeView1Expanding(TObject *Sender, TTreeNode *Node, bool &AllowExpansion) { Node->DeleteChildren(); // убедитесь, что ранее выполняется // Node->Data = reinterpret_cast<void*>(TypeIDStruct); TypeID* NodeData = reinterpret_cast<PTypeID>(Node->Data); if (NodeData == 0) { throw Exception("Go to debugger ;)"); } // ну и инициализация в одной строчке с объявлением как-то красивее int ID = NodeData->ID; int ParID = NodeData->ParID; int type = NodeData->Type; int dtype = NodeData->DType; int selected = TreeView1->Selected->AbsoluteIndex; if (Node->ImageIndex==3) { Node->ImageIndex=6; Node->SelectedIndex=8; } ... и прочитайте для начала Страуструпа ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.03.2005, 03:15 |
|
||
|
access violetion при приведении node->data к типу структуры
|
|||
|---|---|---|---|
|
#18+
archez Непонятны такие моменты: 1 Выделяется ли память для элементов корневого уровня. Потому что при OnExpanding предполагается что память для Node->Data уже выделена. Иначе ты пытаешься записать что-то туда куда нельзя. 2 Освобождается ли память, для элементов подструктуры. Т.е. если OnExpanding происходит для 1-го уровня, то освободится ли память для 2-го, 3-го и ниже уровней, если нет - то утечка памяти. 3 И еще, я не уверен в корректности этого кода: TypeID *raz; ... while (...) { ... raz = new (TypeID); ... NewRaz->Data=raz; ... } Освобождает память наверно что-то вроде: delete NewRaz->Data; Я бы попробывал так: NewRaz->Data=new (TypeID); 4 Из личного опыта - когда код срабатывает 50 раз, а на 51 вылетает, то почти всегда это утечка памяти. Ищи где ты забыл освободить память. Удачи! Спасибо. 1. Для корневых узлов делается то же самое только на OnCreate формы, они не меняются... 2. Да, память освобождается, удалются дети, значит удаляются и все внуки а на ondelete висит именно delete NewRaz->Data 3. Попробую хотя и не понял чем отличается. 4. Это верно, в первом варианте программы память я не освобождал вообще и ошибка появлялась гораздо чаще. Я предполагал что если память не освобождать, то просто будут заниматься лишние байты и все, структура-то не большая. Искать долго придется так как есть еще подобное OnChange и еще несколько компонентов где использется такой метод. авторNode->DeleteChildren(); Код: plaintext 1. 2. А почему оно должно ранее выполняться я ведь не детей привожу к типу, а элемент, ведь сам элемент не удаляется... чем Код: plaintext Код: plaintext 1. Спасибо всем, теперь направление поиска вроде понятно: 1. книжный магазин :-) 2. неосвобожденная память.... зы. Подскажите, если в этом обработчике обявлено столько переменных их надо в конце обработкичика освобождать например delete ID или они сами освободяться когда обработчик отработал. Вроде я читал что переменные обявленные внутри блока автоматически убиваются при выходе из блока.... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.03.2005, 08:30 |
|
||
|
access violetion при приведении node->data к типу структуры
|
|||
|---|---|---|---|
|
#18+
сам создал , сам удаляй :) но это не для всех случаев , если вы делаете так TMyComp * mycomp = new TMyComp(this); то уничтожать не надо за это сделает владелец , а если так TMyComp * mycomp = new TMyComp(nil); то нужно delete mycomp; ну это к приминению компонент так скажем . а в остальных случаях создал удали . ш (';') (V),(V),, Код: plaintext ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.03.2005, 08:36 |
|
||
|
access violetion при приведении node->data к типу структуры
|
|||
|---|---|---|---|
|
#18+
Евгений, Екатеринбург[quot archez] зы. Подскажите, если в этом обработчике обявлено столько переменных их надо в конце обработкичика освобождать например delete ID или они сами освободяться когда обработчик отработал. Вроде я читал что переменные обявленные внутри блока автоматически убиваются при выходе из блока.... Если ты просто объявляешь переменную, "int ID" - то ее удалять не нужно, более, того "delete ID" в данном случае приведет к ошибке. Насколько я помню, располагаются такие переменные в основной памяти и выделением/освобождением занимается сама программа. Переменные которые которые объявляются с использованием "new" располагаются в "куче" (читай выше JibSkeart). Однако нужно понимать, что при объявлении типа: TypeID *raz = new (TypeID); Сам указатель "ras" будет располагаться в основной памяти, а структура типа "TypeID" на которую ссылается этот указатель - в куче. Я не встречал в литературе такого приема: raz = new (TypeID); ... NewRaz->Data=raz; поэтому не уверен, что в этом случае указателю NewRaz->Data передаются, так сказать, права на эту память. Соответственно я не уверен, что она корректно освобождается при "delete NewRaz->Data". Существует класс SmartPointer, который позволяет выделять память под объекты и не переживать за ее освобождение. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.03.2005, 04:59 |
|
||
|
|

start [/forum/topic.php?fid=57&fpage=414&tid=2033663]: |
0ms |
get settings: |
10ms |
get forum list: |
19ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
55ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
50ms |
get tp. blocked users: |
1ms |
| others: | 204ms |
| total: | 362ms |

| 0 / 0 |
