b>j)΄!Pԫ&;"kB޶}pSVT(wę!j x;-m@JnQ+պכ7MajfJͱ4jѲ撆RxZMz7vIW/dٞТזcZM~ji ߒsQzԠDW3Den"M+/B:-uIJ7j委9p='mANޭ=/B:-n&nUfqxZM~c Ϲ+,&ᾺܢF[(1*" ϒ"Jԧ<;b" "jܢF[x ,!q қ*]/؝27SMcs"ޭDQ/应ܢF_! :s" 7`F+SVTn"IJnQ/应B 4 wD"IJ׭-`S9DrjiEJ߅gJ应矁[xZM~n"IB؃!'Тѕ+(mIKʭ/|ϐܢF[xZMzG %嬩/c[[ IBProvider v3.49.1

IBProvider v3.49.1

В задумчивости тыкая в интерфейсе «OLE DB Rowset Viewer» (это стандартная штука для проверки провайдеров «руками и глазами»), запросил неправильный интерфейс результата и спровоцировал ассерт внутри ICommand::Execute. Релизный бинарник, как положено, возвращает E_NOINTERFACE.

Изучение этой проблемы показало, что ассерт был по делу — FAILED-ошибки (типа E_NOINTERFACE) должны обрабатываться другой веткой кода, в которой (до кучи) освобождаются сформированные значения OUT-параметров.

То есть, получалось, что ICommand::Execute возвращал OUT-параметры и FAILED-код. Это вполне могло приводить к тому что клиент, видя FAILED-ошибку, мог забить на освобождение значений OUT-параметров. А это, в свою очередь, приводит к утечке ресурсов.

Вот такая вот головоломка.

А все почему — не были написаны тесты, проверяющие реакцию ICommand::Execute на неправильные параметры.

Так что пришлось, ругаясь, устранять проблему, создавать необходимые тесты и выпускать незапланированное обновление IBProvider — v3.49.1.

Dmitry Kovalenko on 21 марта, 2018 | Filed Under IBProvider

Leave a Comment