Дебагер GDB в QT Creator ведет себя неожиданно Опции

[Гость_Гость_Kanareyka_*_*]

Добрый день!

Нужна помощь, я совершенно застряла. Ранее задавала аналогичные вопросы на других QTшных форумах, но решения пока не получила.

QT Creator 2.7.2 на QT 5.1.0 (32bit) и MinGW.
Пытаюсь реализовать комбинацию QTreeView + QAbstractItemModel + QSortFilterModel, не все получается - соответственно, начала отлаживаться. И то, что я вижу в выводе gdb, я не понимаю. Я новичок в QT, но в целом разработке лет 15 уже и дебагерами раньше пользовалась, в том числе для c++. Но то, что я вижу у себя - оно по-моему логике не поддается... Или у меня не хватает какого-то базового знания.

Чтобы не было сомнений, что я это вижу: сейчас буду показывать скриншотами.
Скриншоты демонстририруют отладку функции insertRow.
Перед запуском функции я
а) выбираю (select) ветку в дереве и
б) ввожу некоторый текст (переменная pSubject).
После этого запускается функция.


На этой картинке видно, что я
- остановила дебагер на "QModelIndex index = выбранный index из selection model",
- нажала F10 чтобы перейти на следующий оператор.
Здесь я вижу корректные - а главное, ожидаемые мной - значения column = 0, row = 9, model = ExTreeProxy (это прокси-модель - наследник от QSortFilterModel)
Т.е. на этом скрине все ок.

Что здесь не видно, но может быть важно:
- в прокси-модели активен фильтр (реализована функция ExTreeProxy::filterAcceptsRow);
- все items базовой модели под этот фильтр попадают (т.е. все items, которые есть в базовой модели, через фильтр проходят и отображаются в дереве).

Дальше начинаются странности:


Здесь видим:
1) Пометка "1" на картинке - демонстрирует, что я получаю после выполнения "sourceIndex = map from index"
По-моему это фигня - ведь я точно знаю, что
- выбрала ветку в дереве (это доказывает предыдущая картинка - index там совершенно нормальный);
- что index - это правильный индекс в прокси, а значит маппинг должен какой-то быть. И все же я вижу невалидный индекс после map from index.

2) Пометка "2" на картинке - демонстрирует, что при входе в else мой нормальный хороший index превращается в index.col = 0, index.row - 0 (и, конечно, следующие операторы из-за этого работают неправильно). Отчего вдруг оно 0/0 стало???

Я думала, это из-за кривого дебагера в поставке - собрала сама (по инструкции на qtlinux.narod.ru). Но новая сборка ведет себя так же.

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

P.S. По запросу в форуме prog.org.ru сделала минимальный компилируемый пример - чтобы можно было другим запустить и посмотреть.
Не вижу, как здесь аттач сделать, если нужно - см. пост по ссылке: Пост с описанием примера и аттачем

[Iron Bug]

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

[Гость_Гость_Kanareyka_*_*]

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

Не расскажете, о чем речь? Как это смотрят?

[Iron Bug]

Не расскажете, о чем речь? Как это смотрят?

о грубых ошибках программистов при работе с памятью. смотрят код на предмет наличия подобных ошибок. общих методов нет.
но не факт, что это именно этот случай.

[Гость_Гость_Kanareyka_*_*]

А, имеются в виду ошибки в приложении... Я подумала, Вы про ошибки в дебагере
В приложении - негде стек затирать... Все операторы очень простые. На скринах это видно, мне кажется.