Если бы ты сделал реально рабочий (в том числе и "на стороне") пример с небольшой пробной табличкой-болванкой, упаковал все и пристегнул к сообщению так, чтобы архив даже и в 2 частях был где-то в пределах 50кб+50кб, возможно что-то бы и прояснилось. А иначе мне кажется - получаются больше несколько абстрактные рассуждения.

Pashka_J
В prg около 950 строк.
Сообщения об ошибках если есть-выводятся (не подавляются то есть).
Что значит "хитрое заворачивание нумарации" ? Может и оно, только что это такое?
Удалил все записи о бреках из фоксюзер - все равно то же самое.
Инетерсно: поменял так (прошляпил if и в результате переменная lcst ваще отсутствовала до вызова последней строки:

if !oSvc.MkLocalResizedPic(alltrim(csJpg.name),alltrim(csJpg.name),1024,758,.f.,72,72,@lcs)
lError=.t.
lcst=lcs
endif
if !lError
lcst=strconv(lcst,14)

И таки в отладчике программа остановилась на lcst=strconv(lcst,14) при дальнейшем шаге выдала ошибку. То есть вывод - с функцией не связано. Остается или тайное местоположение записи точки останова или останов по имени переменной, но это бред, ибо выше она уже менялась и использовалась не раз. Вернулись к тому, с чего начали - всё непонятно

Какая ошибка произошла при дальнейшем шаге? Сообщение привести можете?
По-моему я когда-то сталкивался с поведением, подобным описанному вами. Насколько я помню, происходило это в момент, когда завершалась процедура (или метод) и фокспро принимался неявно уничтожать локальные переменные, содержащие объектные ссылки. Если уничтожение объекта происходило некорректно (сейчас не вспомню, по какой причине) - программа вела себя подобным образом.
Попробуйте проверить наличие таких локальных объектных ссылок в процедуре и явно присвоить им .null. перед завершением метода.





Исправлено 1 раз(а). Последнее : Igor VS, 22.08.11 16:02

Igor VS
Какая ошибка произошла при дальнейшем шаге? Сообщение привести можете?

Что-то вроде "не определена переменная lcst. Но это и справедливо - не определена.

Igor VS
По-моему я когда-то сталкивался с поведением, подобным описанному вами.

Поведение в смысле брекпоинтов непонятных ?

Ради интереса закоментил вызов соап функции:

scan
if file(cPicPathWeb+alltrim(csJpg.name))
lError=.f.
&& 1024x768
lcs=filetostr(cPicPathWeb+alltrim(csJpg.name))
lcs = strconv(lcs, 13)
* if !oSvc.MkLocalResizedPic(alltrim(csJpg.name),alltrim(csJpg.name),1024,758,.f.,72,72,@lcs)
* lError=.t.
* endif
if !lError
lcs=strconv(lcs,14)
RandFileName=sys(3)+"-"+left(sys(3),4)+"-"+left(sys(3),4)+"-"+left(sys(3),4)+"-"+sys(3)+left(sys(3),4)

Все равно останавливается на lcs = strconv(lcs, 13)

Присоединяюсь к наблюдениям автора - есть такой недостаток у отладчика. Вот как это у меня:

1) Поведение отладчика совершенно устойчивое, но неожиданное. Если код программы не менять, то повторная установка реальных точек приводит к устойчивому появлению одной (редко двух) невидимых остановок. Места этих невидимых остановок могут быть очень далеки от реальных, но всегда в этом же prg-файле. Незначительное изменение кода (например, добавление/удаление трассировки) может приводить к их исчезновению.

2) Насколько я помню несколько лет назад уже поднималась эта тема. Тогда после поста кого-то (кажется это была Наоми), я перестал обращать внимание на неожиданные остановки. Если они возникают внутри цикла, чуть меняю код. Если срабатывают раз-два за запуск - вообще терплю.

3) Общее впечатление: это баг отладчика, но не опасный, а скорее неприятный.

kvichans
1) Поведение отладчика совершенно устойчивое, но неожиданное. Если код программы не менять, то повторная установка реальных точек приводит к устойчивому появлению одной (редко двух) невидимых остановок. Места этих невидимых остановок могут быть очень далеки от реальных, но всегда в этом же prg-файле. Незначительное изменение кода (например, добавление/удаление трассировки) может приводить к их исчезновению.

Один к одному. Только найти бы систему в том ,как изменить код, чтобы точка пропала.

kvichans
2) Насколько я помню несколько лет назад уже поднималась эта тема.

Да-да. Вы и поднимали этут тему forum.foxclub.ru , только решения не было найдено.

kvichans
3) Общее впечатление: это баг отладчика, но не опасный, а скорее неприятный.

Оччень неприятный если в цикле около тысячи записей...

Дело в том, что если "поменять код", то точка остановки не становится "невидимой" - она может не отражаться красной точкой (например если стояла она на 300-й строке, а посли модификации в файле осталось только 250 строк), но в списке всех точек останова она есть, и там её можно удалить/временно подавить. Лично я не помню чтобы когда-то встречался с описываемыми чудесами. Однако, само по себе это средство (прописанные в отладчике точки останова) несколько неудобное - и "сползают" при модификациях, и не срабатывают если по ошибке закрыл окно отладчика, и привязаны к одному конкретному foxuser (а мало ли откуда я запускал отладку последний раз - может быть вообще из другой версии фокса) - потому лично я гораздо чаще использую в фоксе "тот самый" SET STEP ON - а конкретно "точки останова" - достаточно редко. При том, как правило, я их не сохраняю между сеансами - т.е. всегда их все удаляю после отработки интересующего куска кода.
Кстати, автор темы не рассказал какой именно версией фокса он пользуется (с точностью до последних 4-х цифр номера версии) - а это вполне может влиять на проявления проблемы.

Игорь, завидую вам. Похоже, в вашем коде отладка идет гладко.
Вы, насколько я вижу, не представили себе ситуацию. Загляните в обсуждение. Я там писал, что отладчик неожиданно останавливается на строкеи проходит ее мимо если изменить в ней (и во всей программе) ОДИН символ
Давайте подумаем, чем отличаются коды тех, у кого такой эффект наблюдается.
Про себя могу сказать, что все мои коды в prg.
А у вас Игорь? А у Pashka_J?
А у остальных?

Я вроде как чётко написал, что
1) С таким не сталкивался (и с тем что изменение 1 буквы в литерале влияет на останов - тоже).
2) Крайне редко пользуюсь точками останова отладчика - мне удобнее вставить куда надо SET STEP ON (который, естественно такими "весёлыми прибабахами" не страдает), плюс к тому я пользуюсь ASSERT-ами - раньше вообще практически все методы начинались с кучи ASSERT-ов, что немало помогает как при начальной отладке, так и в качестве защиты от последующего "дурного использования".
3) Я пользуюсь и prg и vcx и scx.

Igor Korolyov
мне удобнее вставить куда надо SET STEP ON

Аналогично. Еще с FPD все эти точки останова вызывали впечатление чего-то не совсем логичного при отладке. Куда как проще бросать/убирать когда надо всего лишь одну команду и не зависеть от FOXUSER, который например однажды можно нечаянно и подтереть вместе со всеми своими "продуманными" точками и придется снова думать куда их ставить. И даже если допустить, что все это дело вкуса, все равно, на мой взгляд - подобные рассуждения о "независимости" точек останова от (по сути единственного) назначенного для подобных вещей хранилища фокса и полной невозможности их подтереть - уже нечто вроде веры в бабая. Тем более, как показывает практика, обычно все подобные "чудеса" в итоге объясняются чем-то элементарным.

kvichans
Я там писал, что отладчик неожиданно останавливается на строке

CASE sAct = 'vtree-flip-agent'

и проходит ее мимо если изменить в ней (и во всей программе) ОДИН символ

CASE sAct = 'vtree-flip-agnt'

Закрываем фокс, руками находим и удаляем все найденные файлы с именем FOXUSER (надеюсь используется имя стандартное) - и все. Никаких точек больше вообще в принципе быть не может. Или обнаружено иное измерение, где фокспро дополнительно что-то хранит?

kvichans

CASE sAct = 'vtree-flip-agent'

и проходит ее мимо если изменить в ней (и во всей программе) ОДИН символ

CASE sAct = 'vtree-flip-agnt'

Давайте подумаем, чем отличаются коды тех, у кого такой эффект наблюдается.
Про себя могу сказать, что все мои коды в prg.
А у вас Игорь? А у Pashka_J?
А у остальных?

У меня такое встречалось и в prg (с чем собствено сюда и пришел), до этого было в методе формы. И как назло тоже в цикле. Но вот так, чтобы от заменя одной литеры пропадал баг - такого не было.

Нащет Set step on. Когда после долгих лет клиппера перешел на фокс - поначалу использовал эту команду. Потом показалось более удобным (и наглядным) использование штатных точек останова. В общем это и оправдано-даблклик и точка стоит.
Указаный в начале эффект - довольно редкое явление. Причем встречается почему-то только когда код многократно дописывается/исправляется и следовательно многократно в разных местах ставятся/снимаются точки останова.

А фокс у меня 9 версия 09.00.0000.2412

Фокс стоит обновить (безотносительно этой проблемы) - актуальная версия 9-ки это 9.0.0.7423 (SP2 + Hotfix - ставить нужно И то И другое).

Igor Korolyov
Фокс стоит обновить (безотносительно этой проблемы) - актуальная версия 9-ки это 9.0.0.7423 (SP2 + Hotfix - ставить нужно И то И другое).

Кстати - да. Вспомнил, что необъяснимые чудеса, о которых я писал выше, наблюдались при переносе проекта с рабочего места где был установлен VFP9 + SP1, на другое, где девятка была без сервиспаков.

Pashka_J

Igor VS
Какая ошибка произошла при дальнейшем шаге? Сообщение привести можете?

Что-то вроде "не определена переменная lcst. Но это и справедливо - не определена.

Igor VS
По-моему я когда-то сталкивался с поведением, подобным описанному вами.

Поведение в смысле брекпоинтов непонятных ?

Только без всяких брекпоинтов. При прогоне под отладчиком выполнение останавливалось на последнем операторе обнуления объектной ссылки, а при попытке продолжить выполнение возникало не относящееся к событиям сообщение об ошибке, при этом указатель текущего положения был за последним оператором метода. Как оказалось потом проект был изначально написан на VFP9+SP1 и разработка продолжена на другом рабочем месте, где сервиспак не был установлен.





Исправлено 1 раз(а). Последнее : Igor VS, 24.08.11 00:06

Подтвержу наличие неназначенных брекпойнтов. На VFP9sp2 проект давно уже, VFP лиц. Тенденция вроде такова, что если назначить в проекте точку останова (ТО) и запустить EXEшник, под средой разработки, то неназначенная ТО проявляется (если она есть) обычно уже на первых PRGшках, хотя их (пргшек) штук с 10, очистка всех ТО не помогает, установка, после очистки, ТО на том же, нужном, месте приводит опять к остановке на том же незаказанном месте, т.е. есть какая-то корреляция с назначенной ТО. Чистить resource.dbf не пробовал.

ТО пользуюсь редко, т.к. в режиме, когда назначена ТО, программа выполняется медленно, стартовый кусок можно ждать с минуту, что нехорошо, поэтому ставлю, где надо SET STEP ON, а там доставляю ТО по ходу проекта, где там посмотреть надо. Перед следующим запуском проекта окно отладчика закрываю...

Вобщем, отношусь к случайным ТО как к глюкам, системы не нашел, да и не сильно напрягает, ... ну если не попадет эта ТО внутрь цикла какого, тогда переставлят нужную ТО немного в другое место, вроде избавляло...

Кажется понял когда возникают эти фантомные точки останова. Если в коде комментишь кусок, при этом ниже по коду ставишь точку, убираешь точку, в общем отлаживаешь, а поом раскоментишь вышерасположенный кусок. Вот тогда все и случается. Щас раскоментил практически четверть текста выше - так мало того, что стало проходить мимо Return, но и в пошаговом режиме уходит непонятно куда
Переходит непонятно куда после многострочного Select. Причем курсор от этого селекта формируется вполне правильный.

Да, обновил фокса до SP2 теперь версия 09.00.0000.5815

Сегодня столкнулся с той же проблемой.

Убил пол-воскресенья на эксперименты... Удалял все Foxuser (dbf/fpt), чистил брекпоинты, реестр, перегружался для "чистоты" на другую операционку - у меня на машине их две - ENG и RU, при этом одна - XP Pro, другая - XP Home: на одной Фокса установлена, на второй нет (но виден общий диск). Так что варианты распробовал самые разные. Короче, "наэкспериментировался" вдоволь.

Однако Ошибка оставалась, но благодаря этому стало ясно, что это проблема не внешняя, а внутренняя (Фоксы).
Тогда стал сокращать текст программы, чтобы вычленить то место, в котором при некотором сочетание условий возникает эта проблема.

При этом удалось добиться восхитительного результата!

Вся порождающая проблему "выщелоченная" программа состоит всего из двух строк:


Имена всех литералов специально для "выщелоченного" случая упрощены и стандартизированны, символы подмены '\','/' - могут быть заменены на любые другие - хоть "пробел"-на-"пробел" (впрочем см. ниже комментарии):

Для воспроизведения результата необходимо очистить точки останова (Ctrl+B),
поставить точку останова на второй строке и запустить эту программу.

Останов произойдет на первой строке.

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


Но следует заметить, что последний пример избыточен (действия те же, что и для примера выше) - проблему порождает даже предыдущая двухстрочная программа.

Поэтому вернемся к ней:

1. Не имеет никакого значения, что в строке INSERT присутствуют ещё не определенные переменные и курсор;
2. Изменение длины литерала TTTT в большую или меньшую сторону убирает проблему, т.е. от самих символов не зависит, только длина.
3. Обязательно должна быть CHRTRANS(), от имени и длины имени литерала SomeString результат не зависит, также как и от значений символов подмены, например: '\','/', но зависит от длины этих строк подмены - обязательно 1х1.
4. Изменение количества переменных F0..F5 и/или количества их будущих значений CHRT()..5 - также влияет на результат, от их значений не зависит. То есть INSERT должен быть на шесть полей: 6x6.

Из всего выше приведенного, можно сделать заключение, что это бага Фоксы, которая, скорее всего, возникает при
очередной Jit-компиляции (на лету) при генерации и размещении P-кода, либо Fox-овый Debugger подслеповат и в "темноте"
некоторые комбинации P-кода воспринимает как повод трактовать их как точки останова (или и то и другое вместе взятое).

Короче, самое простое решение в такой ситуации - изменить длину имени Таблицы/Курсора.
Только что попробовал - все заработало! - Фантомные точки останова исчезли!

PS: VFP9 Ver. 09.00.0000.2412
PPS: Повторится ли эта ошибка у людей с пропатченной Фоксой?
PPPS: Помогут ли соответствующие SP-ки и т.п.?



Исправлено 17 раз(а). Последнее : meligo, 13.09.11 11:06

meligo
PPS: Повторится ли эта ошибка у людей с пропатченной Фоксой?

Да, на 9.0.0.7423 поведение точно такое-же

meligo
PPPS: Помогут ли соответствующие SP-ки и т.п.?

Ну, если бы MS не прекратило поддержку, то возможно и пофиксили бы - раз уж получилось сделать 100% воспроизводимый пример. А так - шанс исправления ошибки хоть когда-то оценивается бесконечно малой величиной
P.S. Небольшие изменения "плохого кода" (например "разбиение" команды на 2 строки - неважно в каком месте) приводят к интересным эффектам - поведение будет зависеть от того на какой из 2-х строк поставить точку останова - в одном случае вместо "фантома" просто произойдёт перемещение точки останова на предыдущую команду, в другом действительно возникнет 2 точки останова. При том генерируемый P-код на самом деле идентичен - отличие будет только в блоке "стыковки" номеров строк исходника с P-кодом (там по сути для каждой скомпилированной "команды" хранится сколько строк в исходнике она занимает - включая пустые предыдущие строки, или строки с комментариями). Т.е. дело не в P-коде самом по себе (иначе останов происходил бы и без заданных точек останова - а это уж наверняка выявили бы QA), а именно в том как отладчик "подсчитывает строки".

С подобным поведением фокса сталкивался давно.
Кстати описанное поведение воспроизводится и на 06.00.8961.00.
Так что это древний баг который и в девятке не устранен.

Возможно он неустраним в принципе в силу особенностей формата Р-кода.
Не думаю что за 14 лет в МС этого не заметили.



Исправлено 1 раз(а). Последнее : _vit, 12.09.11 15:40

Igor Korolyov, _vit, спасибо! - любопытнные наблюдения и ценная информация!

Подумать только, целых 14 лет с этим багом живут, и не "чешутся"

А весь инет завален вопросами по этой проблеме!

Особенно любопытно, как на вопросы по этой теме на импортных сайтах отвечают
спецы по Support'у Фоксы из MicroSoft:

Invisible-or-phantom-breakpoints

Это я к вопросу о том - "знают или не знают..."

Может быть послать им BugReport, раз уж удалось локализовать проблему?

PS: А то, может быть позвать Наоми, пусть пояснит им по своему, на своей, на Аглицкой мове,
а то я там на Google-Translate English выступал? Не уверен - внятно получилось или нет...

PPS: Igor Korolyov, Вы правы, похоже именно Debugger врёт.



Исправлено 8 раз(а). Последнее : meligo, 13.09.11 11:00