#27 Event wait causes segfault in 3.1_pre2

closed-fixed
5
2003-05-20
2002-11-13
Anonymous
No

LOG: after python setup.py build:

vrgateway:/home/bmt/kinterbasdb-3.1_pre2 # python
setup.py install
running install
running build
running build_py
not copying ./services.py (output up-to-date)
not copying ./__init__.py (output up-to-date)
running build_ext
skipping 'kinterbasdb._kinterbasdb' extension (up-to-date)
skipping 'kinterbasdb._kiservices' extension (up-to-date)
running install_lib
creating /usr/lib/python2.1/site-packages/kinterbasdb
copying
build/lib.linux-i686-2.1/kinterbasdb/services.py ->
/usr/lib/python2.1/site-packages/kinterbasdb
copying
build/lib.linux-i686-2.1/kinterbasdb/__init__.py ->
/usr/lib/python2.1/site-packages/kinterbasdb
copying
build/lib.linux-i686-2.1/kinterbasdb/_kinterbasdb.so ->
/usr/lib/python2.1/site-packages/kinterbasdb
copying
build/lib.linux-i686-2.1/kinterbasdb/_kiservices.so ->
/usr/lib/python2.1/site-packages/kinterbasdbbyte-compiling
/usr/lib/python2.1/site-packages/kinterbasdb/services.py
to services.pyc
byte-compiling
/usr/lib/python2.1/site-packages/kinterbasdb/__init__.py
to __init__.pyc
writing byte-compilation script '/tmp/@3208.0.py'
/usr/bin/python -O /tmp/@3208.0.py
byte-compiling
/usr/lib/python2.1/site-packages/kinterbasdb/services.py
to services.pyo
byte-compiling
/usr/lib/python2.1/site-packages/kinterbasdb/__init__.py
to __init__.pyo
removing /tmp/@3208.0.py
running install_data
not copying docs/index.html (output up-to-date)
not copying docs/installation-source.html (output
up-to-date)
not copying docs/installation-binary.html (output
up-to-date)
not copying docs/usage.html (output up-to-date)
not copying docs/changelog.txt (output up-to-date)
not copying docs/license.txt (output up-to-date)
not copying docs/Python-DB-API-2.0.html (output up-to-date)
not copying docs/links.html (output up-to-date)
not copying docs/global.css (output up-to-date)
vrgateway:/home/bmt/kinterbasdb-3.1_pre2 # python

Python 2.1.1 (#1, Sep 24 2001, 05:28:47)
[GCC 2.95.3 20010315 (SuSE)] on linux2
Type "copyright", "credits" or "license" for more
information.
>>> import kinterbasdb,pickle,os
>>>
>>> con
=kinterbasdb.connect(dsn="vrmetas:e:/tabellen/metas.gdb",user="EXPORTUSER",password="xxxx",charset="win1252"
)
>>> con.wait("metas_insert10")
Segmentation fault

Discussion

  • David S. Rushby

    David S. Rushby - 2002-11-16

    Logged In: YES
    user_id=414645

    As you have no doubt observed, kinterbasdb's support for
    database events is new, suffers from some onerous
    restrictions (only one wait()ing thread per process), and has
    not yet been tested very much. It certainly behaves more
    responsibly than this on the (limited range of) platforms where
    I've tested it, though.

    I'll be reviewing the implementation of kinterbasdb's
    database event support as soon as I have time to invest in
    kinterbasdb again, which will probably be about two weeks
    from now (but I might be able to fix this particular segfault this
    weekend).

    Additionally, I hope to discuss the internals of Firebird's
    event implementation with the Firebird implementors, with an
    eye toward lifting the one-waiting-thread-per-process
    restriction if the database engine will allow it.

    By the way, thank you for the exemplary bug report.

     
  • David S. Rushby

    David S. Rushby - 2002-12-21

    Logged In: YES
    user_id=414645

    I attempted to address this issue (among others) in my most
    recent CVS checkins, but I found that the isc_wait_for_event
    function is apparently not implemented on Linux, just as it
    is not implemented on Windows.

    Page 191 of the IB 6 Beta API Guide says:
    """
    isc_wait_for_event() cannot be used in Microsoft Windows
    applications or under any other operating system that does
    not permit processes to pause. Applications on these
    platforms must use asynchronous event handling.
    """

    On Windows, I've implemented event waiting using the
    database client library's asynchronous facilities coupled
    with a native Event object (which is like a Python
    threading.Condition object) to simulate synchronous event
    handling.

    I was expecting to be able to use the database client
    library's synchronous facilities (that is,
    isc_wait_for_event) on Linux, but apparently they were never
    implemented for Linux, even if Linux would be capable.

    I plan to communicate with the Firebird developers about
    this. If it's true that the client library doesn't support
    synchronous event handling on Linux, I'll do a pthreads
    rendition of the
    simulate-synch-handling-with-asynch-handling-plus-Event-object
    implementation that I've already done for Windows.

    However, the Windows implementation still has some
    unresolved faults; I'll wait until they're squared away to
    port the workaround to Linux.

     
  • David S. Rushby

    David S. Rushby - 2002-12-21
    • assigned_to: nobody --> woodsplitter
     
  • David S. Rushby

    David S. Rushby - 2003-02-26

    Logged In: YES
    user_id=414645

    > However, the Windows implementation still has some
    > unresolved faults; I'll wait until they're squared away to
    > port the workaround to Linux.

    Recent discussion on ib-support may shed some light on
    these "faults" (which, as far as I can tell, are caused by a
    multithreading pitfall in the Firebird client library).

    In any case, I'd like to resolve the issues, and port the
    implementation to *nix, before 3.1 final; I regard database
    event handling as an important feature.

     
  • David S. Rushby

    David S. Rushby - 2003-03-05
    • status: open --> open-fixed
     
  • David S. Rushby

    David S. Rushby - 2003-03-05

    Logged In: YES
    user_id=414645

    > Recent discussion on ib-support may shed some light
    > on these "faults" (which, as far as I can tell, are
    > caused by a multithreading pitfall in the Firebird
    > client library).
    >
    > In any case, I'd like to resolve the issues, and port
    > the implementation to *nix, before 3.1 final; I regard
    > database event handling as an important feature.

    I've now ported event support to POSIX threads; see
    today's CVS checkins.

    kinterbasdb 3.1_pre4 will have event support enabled by
    default, and a Usage Guide section to document the API's
    subtleties.

    In a nutshell, kinterbasdb inherits the following
    limitations from the Firebird client library:

    - only one wait()ing thread per process (in kinterbasdb
    terms, this means only one open EventConduit per process)

    - NEVER use the local connection protocol (as opposed to the
    network protocol) in the same process with event handling.
    For example, if you intend to use events you should always
    use the DSN 'localhost:/path/to/database.db' rather than
    just '/path/to/database.db'. This applies to *all
    connections in the process*, not only to the connection
    whose event_conduit() method you invoke to create an
    EventConduit object.

    The latter issue is the one that was tripping me up. After
    my revision of kinterbasdb's event handling implementation
    in late December, I suspected that the event handling thread
    (which is started by the Firebird client library, and
    operates beyond kinterbasdb's control at times) was running
    afoul of concurrent operations within the client library.

    A recent post to ib-support confirmed my suspicion.
    However, as long the *local* connection protocol is not used
    within the same process as event handling, everything
    appears to be okay. kinterbasdb's implementation of event
    support has always managed thread synchronization in a way
    that *should* have worked, but I was unaware of the
    concurrency pitfall with the local connection protocol until
    just a few days ago.

     
  • David S. Rushby

    David S. Rushby - 2003-05-20
    • status: open-fixed --> closed-fixed
     
  • David S. Rushby

    David S. Rushby - 2003-05-20

    Logged In: YES
    user_id=414645

    As far as I know, everything's peachy with event
    notification in 3.1_pre4. It's been ported to POSIX, and so
    forth.

    There are a couple of caveats, which are discussed in the
    extensive Usage Guide chapter on event notification.

     

Log in to post a comment.

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

Sign up for the SourceForge newsletter:





No, thanks