invalid transaction handle

[Alexey Popov]

Есть программа работающая непрерывно с FB на компе с Windows 8 (на
других компах всё ок). База на том же компе. Используются события.
Иногда работает долго и в один момент функция isc_que_events возвращает
ошибку
335544332 invalid transaction handle (expecting explicit transaction start)

После этого прога падает где в недрах gds32.dll на следующих запросах.
Проверялось на FB2.0 и FB2.1
В чём причина этого?

[Vlad Khorsun]

"Alexey Popov" ...

> Есть программа работающая непрерывно с FB на компе с Windows 8 (на других компах всё ок). База на том же компе. Используются
> события. Иногда работает долго и в один момент функция isc_que_events возвращает ошибку
> 335544332 invalid transaction handle (expecting explicit transaction start)

isc_que_events не работает с тр-циями и не может возвращать эту ошибку.

--
Хорсун Влад

PS а ты ожидал другой ответ ? :)

[Alexey Popov]

Vlad Khorsun wrote:

>> 335544332 invalid transaction handle (expecting explicit transaction
>> start)

> isc_que_events не работает с тр-циями и не может возвращать эту ошибку.
>

> PS а ты ожидал другой ответ ? :)

Я сам тоже в смятении... Но статус векторе по индексу 1 находится число
335544332, которое и выводится в лог программы. В iberror.h написано что
это соответствует isc_bad_trans_handle.
Может это конечно наведённый баг, но подозрительно что на остальных
компах всё нормально крутится, а тут х.з. что творится.

[Vlad Khorsun]

"Alexey Popov" ...wrote ...

Может ли оно остаться там от другого (предыдущего) вызова ? От вызова в другом потоке ?

--
Хорсун Влад

[Alexey Popov]

Vlad Khorsun wrote:

> Может ли оно остаться там от другого (предыдущего) вызова ? От вызова
> в другом потоке ?

Статусный вектор у меня выделяется локально на стеке...
Я вот что подумал, откуда вообще надо вызывать isc_que_events изнутри
callback или из основного потока? У меня - второе.

[Vlad Khorsun]

"Alexey Popov" ...

> Vlad Khorsun wrote:
>
>> Может ли оно остаться там от другого (предыдущего) вызова ? От вызова в другом потоке ?
>
> Статусный вектор у меня выделяется локально на стеке...

И заполняется нулями ?

> Я вот что подумал, откуда вообще надо вызывать isc_que_events изнутри callback или из основного потока? У меня - второе.

Насколько я помню, оба подхода имеют право на существование.

--
Хорсун Влад

[Alexey Popov]

Vlad Khorsun wrote:

>> Статусный вектор у меня выделяется локально на стеке...
>
> И заполняется нулями ?

Нет, а надо? Функция API в случае ошибки должна его заполнять.


Кажется я нашёл причину лютого пи%№#$. Оказывается фунции API какого то
хрена делают что то в alertable wait state. Достоверно выяснил что
например при вызове dsql_allocate_statement срабатывает обработка всех
APC потока, что и вызывает полную жопу. Проблема редка при быстрой
работе, но стоило поставить исскуственные задержки, так всё и посыпалось.

Повидимому лечению такое не поддаётся.
Получается, что из за этого лютого косяка поток работы с IB API не может
использовать APC в своей работе. Это очень печально, придётся много
переделывать.

[Vlad Khorsun]

"Alexey Popov" <a...@novgorod.net> wrote in message news:lp0p7e$skd$1...@ger.gmane.org...

> Vlad Khorsun wrote:
>
>>> Статусный вектор у меня выделяется локально на стеке...
>>
>> И заполняется нулями ?
>
> Нет, а надо?

Ты локальные переменные тоже не инициализируешь перед использованием ?

> Функция API в случае ошибки должна его заполнять.

Если ошибки не было, АПИ вполне может оставить статус без изменения.

> Кажется я нашёл причину лютого пи%№#$. Оказывается фунции API какого то хрена делают что то в alertable wait state. Достоверно
> выяснил что например при вызове dsql_allocate_statement срабатывает обработка всех APC потока, что и вызывает полную жопу.
> Проблема редка при быстрой работе, но стоило поставить исскуственные задержки, так всё и посыпалось.
>
> Повидимому лечению такое не поддаётся.
> Получается, что из за этого лютого косяка поток работы с IB API не может использовать APC в своей работе. Это очень печально,
> придётся много переделывать.

Звучит как бред, по крайней мере без деталей. Если ты в APC вызываешь
ISC API, то сам должен понимать все нюансы подобного взаимодействия...

--
Хорсун Влад

[Alexey Popov]

Vlad Khorsun wrote:

>> Функция API в случае ошибки должна его заполнять.
>
> Если ошибки не было, АПИ вполне может оставить статус без изменения.

Так я обычно проверяю то что функция возвращает
if(isc_que_events....) обработка ошибки

> Звучит как бред, по крайней мере без деталей. Если ты в APC вызываешь
> ISC API, то сам должен понимать все нюансы подобного взаимодействия...

Я сам был в шоке. Экспериментально обнаружил, что вызов первого же
оператора dsql_allocate_statement вызывает обрабоку всех APC из очереди
потока.
Проверить это просто, но думаю что менять здесь уже что то поздно.
В моём случае это приводит к рекурсивным вызовам с разрушением исходного
контекста.

[Alexey Popov]

Я выяснил где собака порылась. Виноват оказался MS.
В отладчике выяснилось, что APC вылетает из функции select, которую
использует внутри gds32.dll. Любой код вида

void APIENTRY user_apc(ULONG_PTR dwParam)
{
//1
}

void main()
{
QueueUserAPC(user_apc,GetCurrentThread(),0);
sql q("select 1 from rdb$database");
//любой sql-оператор на любых компонентах доступа

//2
}

Попадает в точку 1 перед точкой 2.

Причина этого описана в msdn:

-----------------------------------------------------------
http://msdn.microsoft.com/en-us/library/windows/desktop/ms740141(v=vs.85).aspx

Note When issuing a blocking Winsock call such as select with the
timeout parameter set to NULL, Winsock may need to wait for a network
event before the call can complete. Winsock performs an alertable wait
in this situation, which can be interrupted by an asynchronous procedure
call (APC) scheduled on the same thread. Issuing another blocking
Winsock call inside an APC that interrupted an ongoing blocking Winsock
call on the same thread will lead to undefined behavior, and must never
be attempted by Winsock clients.
-----------------------------------------------------------

Печально всё это и лечению не подлежит. Даже если переделать gds32.dll
то редистрибьютить его нереально.

[Vlad Khorsun]

"Alexey Popov" wrote ...

>Я выяснил где собака порылась. Виноват оказался MS.

Т.е. кто угодно, но только не я сам ? :-D

--
Хорсун Влад

PS как вариант "лечения", конкретно для тебя - вызывай SleepEx(1, TRUE),
если очередь APC не пуста, перед любым\избранными вызовами ISC API.
Это относительно тривиально реализовать

[Alexey Popov]

Vlad Khorsun wrote:

>> Я выяснил где собака порылась. Виноват оказался MS.
>
> Т.е. кто угодно, но только не я сам ? :-D

Нет, всётаки не MS. Это поведение там задокументировано.
А вот в документации к IB API не написано, что её функции делают
alertable wait под Windows. Это тоже косяк.
Хотя MS просто задокуметировала свой баг, вместо того чтобы его
исправить. Тоже тридваразы.

> PS как вариант "лечения", конкретно для тебя - вызывай SleepEx(1, TRUE),
> если очередь APC не пуста, перед любым\избранными вызовами ISC API.
> Это относительно тривиально реализовать

Чем же это поможет? Проблема в том, что обработчки APC трогают ресурсы,
которыми оперирует вызывающий API код, который не являеется
реентабельным. Вызов API может просходить из большой глубины стэка
вызовов и протащить туда весь контекст невозможно.

[Vlad Khorsun]

"Alexey Popov" ...

> Vlad Khorsun wrote:
>
>>> Я выяснил где собака порылась. Виноват оказался MS.
>>
>> Т.е. кто угодно, но только не я сам ? :-D
>
> Нет, всётаки не MS. Это поведение там задокументировано.
> А вот в документации к IB API не написано, что её функции делают alertable wait под Windows. Это тоже косяк.

Они его не делают.

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

> Хотя MS просто задокуметировала свой баг, вместо того чтобы его исправить. Тоже тридваразы.

Баг в твоей голове, извини.

>> PS как вариант "лечения", конкретно для тебя - вызывай SleepEx(1, TRUE),
>> если очередь APC не пуста, перед любым\избранными вызовами ISC API.
>> Это относительно тривиально реализовать
>
> Чем же это поможет?

Ничем, забудь.

--
Хорсун Влад

[Alexey Popov]

Vlad Khorsun wrote:

>> А вот в документации к IB API не написано, что её функции делают
>> alertable wait под Windows. Это тоже косяк.
>
>
> Они его не делают.

Они не делают, делает функция select из WinSock, которая и вызывается из
IB API.

Я же тебе пример кода привёл. Важен сам факт, что обработчики APC
вылетают из вызовов IB API.

Ты читал что тут написано? Или перевести?:

[Vlad Khorsun]

"Alexey Popov" ...

> Vlad Khorsun wrote:
>
>>> А вот в документации к IB API не написано, что её функции делают alertable wait под Windows. Это тоже косяк.
>>
>>
>> Они его не делают.
>
> Они не делают, делает функция select из WinSock, которая и вызывается из IB API.

И что ? А под Win16, когда этот код изначально портировался, не было никакого APC
в принципе. Что дальше ? Тебе документировать все системное API, что вызывается из
всех ISC API ф-ций ? На каждой платформе ? Ничё не треснет ?

--
Хорсун Влад

PS Я одного не понимаю - ты троллишь или дурака валяешь ?

[Alexey Popov]

Vlad Khorsun wrote:

> И что ? А под Win16, когда этот код изначально портировался, не было
> никакого APC
> в принципе. Что дальше ? Тебе документировать все системное API, что
> вызывается из
> всех ISC API ф-ций ? На каждой платформе ? Ничё не треснет ?

Alertable wait state всегда явно указывается в функциях. Это правило
хорошего тона и гигиены. Странно что ещё никто не упарывался на этом.

> PS Я одного не понимаю - ты троллишь или дурака валяешь ?

Т.е. ты не считаешь это проблемой?
А я вот считаю.