dpiConn_close crash

[unficyp]

1. What version of ODPI-C are you using (see dpi.h)?
   5.6.2

2. What OS (and version) is your application on?
   Linux/Manjaro

3. What compiler (and version) did you use?
   g++ 15.2.1

4. What is your version of the Oracle Client (e.g. Instant Client)? How was it installed? Where it is installed?
   instantclient 23.9

5. What is your Oracle Database version?
   19.26

6. What is the PATH environment variable (on Windows) or LD_LIBRARY_PATH (on Linux) set to?
   /home/oracle/instantclient_23_9

7. What environment variables did you set? How exactly did you set them?

8. What problem or error(s) you are seeing?
   dpiConn_close segfaults, gdb backtrace gives

`#0 dpiLob__close (lob=0x555555905910, propagateErrors=1, error=0x7fffffffcfa0) at /media/gweber/Data1/develop/cpp/playground/odpilib/external/odpi-c/dpiLob.c:92

#1 0x00007ffff7d3dda9 in dpiConn__close (conn=0x555555724890, mode=0, tag=0x0, tagLength=0, propagateErrors=1, error=0x7fffffffcfa0)
at /media/gweber/Data1/develop/cpp/playground/odpilib/external/odpi-c/dpiConn.c:235

#2 0x00007ffff7d41a1c in dpiConn_close (conn=0x555555724890, mode=0, tag=0x0, tagLength=0) at /media/gweber/Data1/develop/cpp/playground/odpilib/external/odpi-c/dpiConn.c:1757

#3 0x00007ffff7dbb9c9 in odpilib::Connection::Close (this=0x7fffffffd190) at /media/gweber/Data1/develop/cpp/playground/odpilib/src/Connection.cpp:104

#4 0x0000555555639efd in test_7 (argc=2, argv=0x7fffffffd6a8) at /media/gweber/Data1/develop/cpp/playground/odplibtest/main.cpp:77

#5 0x00005555556686e5 in std::__invoke_impl<void, void (*&)(int, char**), int, char**> (__f=@0x5555556b7a10: 0x555555639c70 <test_7(int, char**)>) at /usr/include/c++/15.2.1/bits/invoke.h:63

#6 0x00005555556649e0 in std::__invoke_r<void, void (*&)(int, char**), int, char**> (__fn=@0x5555556b7a10: 0x555555639c70 <test_7(int, char**)>) at /usr/include/c++/15.2.1/bits/invoke.h:113

#7 0x000055555565e3bb in std::_Function_handler<void(int, char**), void (*)(int, char**)>::_M_invoke (__functor=..., __args#0=@0x7fffffffd4a4: 2, __args#1=@0x7fffffffd498: 0x7fffffffd6a8)
at /usr/include/c++/15.2.1/bits/std_function.h:292

#8 0x000055555564872b in std::function<void(int, char**)>::operator() (this=0x5555556b7a10, __args#0=2, __args#1=0x7fffffffd6a8) at /usr/include/c++/15.2.1/bits/std_function.h:593

#9 0x0000555555639b72 in main (argc=2, argv=0x7fffffffd6a8) at /media/gweber/Data1/develop/cpp/playground/odplibtest/main.cpp:44
`

9. Do you have a runnable code snippet to describe the problem?

code is part of a larger c++ library. basically it does:

• open context
• open connection
• dpiConn_prepareStmt and dpiStmt_execute statement
• run dpiStmt_fetch in loop until found = 0, no column values/etc fetched
• dpiConn_close

why does it try to close a lob?

thanks in advance,
gerald

[unficyp]

observation: query "select * from client" - client table contains a blob column. when i query "select id from client", no crash occurs. so it looks like the crash only happens when selecting a blob column without even touching it.

[cjbj]

Can you provide runnable code, and the SQL to create the table?

[unficyp]

files attached, hope this helps. inserts are not needed.

main.cpp

create_table.sql

funny thing: i tried to reproduce the error with a basic table like id number, name varchar2(100) content blob only - no error.
i only get the error with this table and dpiStmt_release(stmt); commented out.

[unficyp]

sounds like vodoo but, creating those 2 tables:
create table test2 (id number, content blob, name varchar2(100));
create table test3 (id number, name varchar2(100), content blob);

using select * from test2 -> crash
using select * from test3 -> no crash.

[anthony-tuininga]

I was able to figure out the source of this issue. LOB handles are being added to the internal list which don't actually have any LOB locators associated with them (since you never fetched enough rows to fill your buffer) and these are not removed from the list on free unless there IS a LOB locator associated. And no check is being made on those handles afterwards -- except when in threaded mode. If you enable threaded mode the problem will go away for this reason. In the Python and Node.js drivers that depend on ODPI-C we have enabled threaded mode as it was determined that there is little if any difference in performance and it allows for threading without strange crashes taking place! And that explains why we never noticed this issue. Thanks for bringing it to our attention!