Segfault in gbak when restoring broken backup file over the wire

[AlexPeshkoff]

Reported by Vlad privately.

gbak predicts the size of data buffer in XDR operations required for table record. But in case of broken data in backup file data is reallocated which together with a fact that original buffer is freed in Array's dtor once again causes double deallocation and segfault.

[pavel-zotov]

::: test issues :::
Not enough info. Sent letter to Alex, 26.02.2023 12:28. Waiting for reply.

[AlexPeshkoff]

Pavel, I definitely do not remember that letter in Feb. What info do you need?

[pavel-zotov]

In that letter I meant the following: what must be written in a fbk file to make it in such 'broken state' that attempt to restore from it caused crash ?
I've tried to put some kind of garbage in .fbk but got every time

gbak: ERROR:string truncated
gbak:Exiting before completion due to errors

(or some other error, but FB not crashed
Checked on 5.0.0.509 (date of build: 07-jun-2022)

[AlexPeshkoff]

You should try to make length of damaged record much bigger (like 40 Kb instead 1 Kb) than normal one. But that also does not guarantee crash - it's related with double de-allocation of same memory region, and may cause AV not at once or not cause at all.

[AlexPeshkoff]

I suggest not to have special test for it - even if you reproduce a crash with some particular version (fb4 for example) that does not mean that same data kills fb3 or fb5.

[pavel-zotov]

suggest not to have special test for it
So be it. Set mark 'can not be tested' for this.