Issue Details (XML | Word | Printable)

Key: PYFB-73
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Pavel Cisar
Reporter: Pavel Zotov
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
Firebird driver for Python

Buffer filled with zero-characters is returnred instead of actual content of page when page number more than 64 K

Created: 20/Jan/18 07:36 PM   Updated: 13/Jul/19 09:04 AM
Component/s: None
Affects Version/s: 1.7, 1.8
Fix Version/s: 2.0

Environment:
Python 2.6, 2.7, 3.x
fdb 1.7, 1.8
Firebird 2.5 database
Linux CentOS; Windows 8.1 or Windows Server 2008 R2


 Description  « Hide
It seems that fdb incorrectly handles with obtaining page content when page number more than 64 K.
Please download this big .fdb (made in recent 2.5.x) :

https://yadi.sk/d/p0BYEF0c3RZtr8

(9 files of .7z format, total size after unpacking will be ~65 Gb).
Page size of this DB = 8192 byte

When i get content of page N 8317600:
...
page_buffer = con.get_page_contents( page_number )
(page_type,) = unpack_from('<b',page_buffer)
...

- it looks like buffer containing 8292 characters with ascii code = 0.

But actually this is pointer page of relation with id = 259 (hex 103).
Here is starting part of this page how it looks in hex editor:
===
fdd540000 : 0004 3039 0d89 0000 0000 0000 0000 0000
fdd540010 : 0069 0000 ee9e 007f 0780 0103 0009 0000
===
/* fdd540000 hex == 8317600 dec; 103 hex = 259 dec */


 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Dmitry Yemanov added a comment - 21/Jan/18 05:37 AM
In database_info (fbcore.py) I see:

        if info_code == fb_info_page_contents:
            request_buffer += int_to_bytes(2, 2)
            request_buffer += int_to_bytes(page_number, 4)

I believe the first packed chunk should be:

            request_buffer += int_to_bytes(4, 2)

as it represents the length of the page number.

That said, I dunno why error is not thrown in this case (AFAIU, remaining two bytes should be parsed by the server as next info items and this is unlikely to succeed).