Commented by: @dyemanov

Could you please provide a reproducible test case (binary preferred)?

Commented by: Mathias Dellaert (mithandir)

Of course. My apologies for not doing so immediately. I will try and get a test case to you by this time tomorrow.

Commented by: Mathias Dellaert (mithandir)

My apologies, it seems I was mistaken. The actual error is not a timeout but as follows:

"Invalid format for transaction parameter block. Unsuccesful execution by system error that does not preclude succesful execution of subsequent statements.
Error Code: 11"

It seems thus to be an issue with the components I use (UIB) sending the wrong transaction block when timeout parameters are set. Still, the exact same code worked with 2.1 Beta 1 and 2.1 Beta 2 (and 2.0) and I could not find any documentation about a change to this format in the release notes. Presumably other packages will run into the same problem (meaning a break in backwards compatibility between 2.1 and 2.0).

Should I take this up with the component's developers instead?

I have attached a test case (binary + sourcecode) for this problem should you still want it.

Commented by: Mathias Dellaert (mithandir)

Reproducable testcase. Contains binary + source code. Simply unzip in a directory and run.

Commented by: @dyemanov

The UIB components send the timeout value wrongly. They do:

        tpLockTimeout : Result := Result \+ Char\(Ord\(tp\)\+1\) \+ PChar\(@FLockTimeout\)\[0\] \+ PChar\(@FLockTimeout\)\[1\];

but the correct code should be:

        tpLockTimeout : Result := Result \+ Char\(Ord\(tp\)\+1\) \+ Char\(2\) \+ PChar\(@FLockTimeout\)\[0\] \+ PChar\(@FLockTimeout\)\[1\];

i.e. they don't pass the timeout value length (in bytes).

Prior FB versions didn't validate the TPB format and could read garbage behind the buffer boundaries.