On 03.09.2021 15:12, Dimitry Sibiryakov wrote:
In the debugger walk up call stack to find out how n got too small value (or on contrary vlen got too big). Start from showing definition of the field "ТипВорот" (as per isql SHOW TABLE and actual values of n and vlen.
I am in the process of implementing your proposal. However, I am yet unable to find a place where the memory that is later used in Sort::diddleKey is populated. The function gets called in pairs; and the first call has the proper value at *((USHORT*) (record + key->skd_vary_offset)) - which is 18 (the length of the string there after the size), while the second has it wrong, varying each time (88; 96; 104; 112; 120; 128; then suddenly 80; ...). The data looks pre-populated at some stage. The wrong values are *behind* the memory that is handled first (in chunks of 116 bytes), with the wrong data being at 'record - 116*n + 108' offsets, and does not get modified after the first call to Sort::diddleKey appears, until it is processed.
I'm still thinking how can I guess the memory address that will finally become used for the function, so that I could put "break on change" breakpoints ahead of time.
Thanks for your suggestion! -- Best regards, Mike Kaganski Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
