Re: Threading crash using ODBC

markw wrote:
>
> Hiroshi Inoue wrote:
>
> > markw wrote:
> >
> >
> >> Here's what I have:
> >>
> >> I have an application with 1 main thread and a number of worker
> >> threads.
> >> At startup, I allocate a number of ODBC connections.
> >> I have an internal queue that is protected by a mutex.
> >> When one of the worker threads wants to use the database, it gets
> >> an un
> >> occupied SQL connection from the queue.
> >>
> >> At startup, I can execte a query just fine. When I try to execute
> >> a
> >> query from one of the worker threads, I get a core dump.
> >>
> >> I am using UNIX ODBC and the PostgreSQL driver, as shipped with
> >> RedHat 7.3.
> >>
> >> The stack trace looks like this:
> >>
> >> 0 0x402fba4c in CC_send_query () from /usr/lib/libodbcpsql.so
> >> (gdb) where
> >> #0 0x402fba4c in CC_send_query () from /usr/lib/libodbcpsql.so
> >> #1 0x40314842 in SC_execute () from /usr/lib/libodbcpsql.so
> >> #2 0x40304c45 in PG_SQLExecute () from /usr/lib/libodbcpsql.so
> >> #3 0x40304c6b in SQLExecute () from /usr/lib/libodbcpsql.so
> >> #4 0x402a13f4 in SQLExecute () from /usr/lib/libodbc.so.1
> >> #5 0x40023d6f in MSqlODBC::ExecResult (this=0x806bfd4,
> >> sql=0x4037f83c "select value, timeout from msession_sessions
> >> where
> >> session = '2b7atuahma6u9igcorr7c6q8ld7ne86o'") at modbcsql.cpp:360
> >>
> >>
> > It's the driver provided by unixODBC itself.
> > Please inquire unixODBC team about it.
> > Or try the (maybe) thread-safe driver on *nix
> > recently provided at http://odbc.postgresql.org/.
> >
>
> Actually, I tracked it down. It may be something that you are
> interested in, I had my stack set to 64K, when I bumped it up to 256K,
> the problem went away.
>
> Both the unixODBC and PostgreSQL drivers are similar, or at least have
> a similar origin. The stack utilization deserve at least a little
> scrutiny.

I've improved a little about the stack utilization of
our ODBC driver and some applications could work with
the improvement though I'm not sure if it can work with
your application.

regards,
Hiroshi Inoue
http://w2422.nsk.ne.jp/~inoue/