#70 Assertion failed: data_type == SQL_BLOB

open-fixed
5
2007-02-10
2007-02-05
No

If comment line 40 in test.py all work Ok.

Discussion

  • Alexandr Zamaraev (aka Tonal)

    Simple script for reproduction problem

     
  • Alexandr Zamaraev (aka Tonal)

    Logged In: YES
    user_id=980085
    Originator: YES

    os: WinXP Home Rus + Sp2
    python: 2.4.4
    kinterbasdb: 3.2_20060901
    firebird: 2.0 b(12810)

     
  • David S. Rushby

    David S. Rushby - 2007-02-05

    Logged In: YES
    user_id=414645
    Originator: NO

    ---
    kinterbasdb: 3.2_20060901
    firebird: 2.0 b(12810)
    ---

    Why are you using such old versions? Why not 3.2.0?

    Does the problem occur with KInterbasDB 3.2.0, if it's compiled with 'checked_build=1' in setup.cfg?

    The official release of 3.2.0 is compiled with assertions off. If you're not able to compile 3.2.0 with check_build=1 yourself, I can provide you with a binary.

     
  • Alexandr Zamaraev (aka Tonal)

    Logged In: YES
    user_id=980085
    Originator: YES

    I use last CVS sources.
    In file version.txt - 3.2_20060901
    In __init__.py - __version__ = (3, 2, 0, 'final', 0)
    and __timestamp__ = '2006.09.01.16.03.22.UTC'
    Release date = 2006.08.12
    I use old version?

    I change only key database_home_dir in section [manual_config]
    But I compile Mingw32 v 3.4.5
    First compiller command line:
    C:\Lang\mingw\bin\gcc.exe -mno-cygwin -mdll -Wall -O3 -Wno-strict-aliasing -mtune=pentium3 -march=pentium3 -DWIN32 -IC:\Lang\Python\24\include -IC:/Lang/Firebird/Firebird_2_0\include -IC:\Lang\Python\24\include -IC:\Lang\Python\24\PC -c _kinterbasdb.c -o build\temp.win32-2.4\Release\_kinterbasdb.o -pedantic -std=c99 -fno-strict-aliasing

    Maybe You forget define NDEBUG for gcc:
    file setup.py line 1069:
    if CHECKED_BUILD:
    # Lack of a second tuple element is the distutils conventions for
    # "undefine this macro".
    allMacroDefs.append(('NDEBUG',))

     
  • Alexandr Zamaraev (aka Tonal)

    Logged In: YES
    user_id=980085
    Originator: YES

    I change setup.py and compile module with NDEBUG=1
    file setup.py line 1069:
    if CHECKED_BUILD:
    # Lack of a second tuple element is the distutils conventions for
    # "undefine this macro".
    allMacroDefs.append(('NDEBUG',))
    else:
    allMacroDefs.append(('NDEBUG', 1))

    test.py crach with output:
    1
    Traceback (most recent call last):
    File "D:\Lang\sf.net\ConcurentVS\Kinterbasdb-3.0\test.py", line 52, in ?
    main()
    File "D:\Lang\sf.net\ConcurentVS\Kinterbasdb-3.0\test.py", line 49, in main
    work()
    File "D:\Lang\sf.net\ConcurentVS\Kinterbasdb-3.0\test.py", line 42, in work
    for row in curs:
    TypeError: 'dict' object is not callable

    If in BLOB have NULL I catch crash

     
  • David S. Rushby

    David S. Rushby - 2007-02-06

    Logged In: YES
    user_id=414645
    Originator: NO

    Ok, thanks for the report. I'll investigate this tomorrow evening.

     
  • David S. Rushby

    David S. Rushby - 2007-02-06
    • assigned_to: nobody --> woodsplitter
     
  • David S. Rushby

    David S. Rushby - 2007-02-07

    Logged In: YES
    user_id=414645
    Originator: NO

    Well, I've tried running the full KInterbasDB test suite against:
    - 3.2.0
    - the current 3.2 branch (which is a bit more recent than is available in CVS, but shouldn't contain any changes relevant to this situation)
    - the current 3.3 branch

    These tests were run on the Russian version of Windows 2000 Pro SP4 (I don't have Windows XP), with Python 2.5.0, FB 2.0.0 SS, and MinGW 3.4.5 (with CHECKED_BUILD both 0 and 1, and the setup.py fix that you suggested, so that a MinGW CHECKED_BUILD=0 actually disables assertions).

    I was not able to reproduce the behavior you're seeing under any of these configurations.

    Can you provide me with example client code that triggers the problem?

     
  • Alexandr Zamaraev (aka Tonal)

    Logged In: YES
    user_id=980085
    Originator: YES

    All code in test.py:
    In functuion init() - create empty database and create table (T3).
    In functuion work() - connect, configure blob translations, full table and select.
    Problebm show in select (line 41) if in table exists NULL value (line 40)

     
  • David S. Rushby

    David S. Rushby - 2007-02-09

    Logged In: YES
    user_id=414645
    Originator: NO

    Oops, I didn't notice the attachment (duh...). I'll experiment with it tomorrow.

     
  • David S. Rushby

    David S. Rushby - 2007-02-10

    With new 3.3 snapshot, original script can be simpler

     
  • David S. Rushby

    David S. Rushby - 2007-02-10
    • status: open --> open-fixed
     
  • David S. Rushby

    David S. Rushby - 2007-02-10

    Logged In: YES
    user_id=414645
    Originator: NO

    Ok, I've posted a snapshot of KInterbasDB 3.3 in which everything is fixed. I plan to backport only the most conservative of those changes to KInterbasDB 3.2.1. This feature doesn't really work with FB < 2.1, anyway, so having it work in KIDB 3.2.x doesn't deliver much real value.

    The automatic encoding and decoding of textual blobs, which you're trying to enable in test.py, cannot work "properly" with any version of Firebird prior to 2.1, because older FB versions don't provide the information necessary for KInterbasDB to automatically determine a blob field's character set, when converting in the input direction. I discussed that in 2005 in this forum post:
    http://sourceforge.net/forum/message.php?msg_id=3213526

    In the posted snapshot of KInterbasDB 3.3, I added a type_conv code 300, which is exactly like 200, except that it also enables automatic encoding/decoding for textual blobs. It will only work *properly* with Firebird 2.1+ (yes, I tested it), but I added the following hack for earlier FB versions:

    When type_conv >= 300 is enabled and KInterbasDB is running against a version of FB prior to 2.1, KInterbasDB will assume that it should use the Connection.charset to encode and decode textual blobs. This isn't really safe, but it must be explicitly enabled by using kinterbasdb.init(type_conv=300), and becomes genuinely safe with FB 2.1+.

    So, that seems to me like a reasonable compromise. Your original test.py can now achieve its goals as shown in the attached test2.py.

    Here's the new KIDB 3.3 snapshot:
    http://kinterbasdb.sourceforge.net/snapshots/3.3/kinterbasdb-3.3_pre_20070210.src.tar.bz2

    Thank you for the bug report!
    File Added: test2.py

     
  • David S. Rushby

    David S. Rushby - 2007-04-04

    Logged In: YES
    user_id=414645
    Originator: NO

    This is to remind me that, as of 2007-04-04, I haven't yet backported this fix to 3.2.

     
  • David S. Rushby

    David S. Rushby - 2007-04-05

    Logged In: YES
    user_id=414645
    Originator: NO

    I've now backported the basic elements of the fix (don't die with an assertion) to 3.2 (you will need to use 3.3 to get the new "automatic encoding/decoding for textual input blobs" feature (and that feature can only work reliably with FB 2.1+)).

    I'll make a new 3.2 snapshot available soon.

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks