Menu
▾
▴
#27 Event wait causes segfault in 3.1_pre2
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
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.
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.
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.
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.
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.