OCI_SubscriptionRegister() generates a segfault on failure

[unficyp]

Hi,
looks like #3 is back ?
using 4.7.4 on Manjaro Linux, test program connects against an 19.18 EE, oracle client:
instantclient 19.6

gdb backtrace:
`(gdb) r
Starting program: /media/gweber/Data1/develop/cpp/playground/oci_subscription_test/bin/Debug/oci_subscription_test

This GDB supports auto-downloading debuginfo from the following URLs:
https://debuginfod.archlinux.org
Enable debuginfod for this session? (y or [n]) y
Debuginfod has been enabled.
To make this setting permanent, add 'set debuginfod enabled on' to .gdbinit.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
[New Thread 0x7ffff29ff680 (LWP 15881)]
[New Thread 0x7fffea3ff6c0 (LWP 15882)]
free(): double free detected in tcache 2

Thread 1 "oci_subscriptio" received signal SIGABRT, Aborted.
0x00007ffff79b964c in ?? () from /usr/lib/libc.so.6
(gdb) bt full
#0 0x00007ffff79b964c in ?? () from /usr/lib/libc.so.6
No symbol table info available.
#1 0x00007ffff7969938 in raise () from /usr/lib/libc.so.6
No symbol table info available.
#2 0x00007ffff795353d in abort () from /usr/lib/libc.so.6
No symbol table info available.
#3 0x00007ffff79ad7ee in ?? () from /usr/lib/libc.so.6
No symbol table info available.
#4 0x00007ffff79c33dc in ?? () from /usr/lib/libc.so.6
No symbol table info available.
#5 0x00007ffff79c5737 in ?? () from /usr/lib/libc.so.6
No symbol table info available.
#6 0x00007ffff79c7ba3 in free () from /usr/lib/libc.so.6
No symbol table info available.
#7 0x00007ffff7f71e71 in OcilibMemoryFree (ptr_mem=) at memory.c:184
block =
#8 0x00007ffff7f9933c in OcilibSubscriptionRegister (con=, name=, type=7, handler=, port=, timeout=)
at subscription.c:330
call_retval =
call_status =
call_context = {source_ptr = 0x5555556193f8, location = 0x7ffff7fa88a0 <func.6> "OcilibSubscriptionRegister", source_type = 11}
func = "OcilibSubscriptionRegister"
attr = 1
dbsize = 6
dbstr =
sub =
#9 0x000055555555c48c in ocilib::Subscription::Register (this=0x7fffffffd650, connection=..., name="sub-00", changeTypes=...,
handler=0x55555555a5a0 <EventHandler(ocilib::Event&)>, port=5468, timeout=0) at /usr/local/include/ocilibcpp/detail/Subscription.hpp:43
No locals.
#10 0x0000555555559a9d in main (argc=1, argv=0x7fffffffd978) at /media/gweber/Data1/develop/cpp/playground/oci_subscription_test/main.cpp:38
con = {<ocilib::core::HandleHolder<OCI_Connection*>> = {_smartHandle = 0x5555556692e0}, }
st = {<ocilib::core::HandleHolder<OCI_Statement*>> = {_smartHandle = 0x555555669380}, }
sub = {<ocilib::core::HandleHolder<OCI_Subscription*>> = {_smartHandle = 0x0}, }
ex = <error reading variable: Cannot access memory at address 0x0>
(gdb)
`

source is the same from https://vrogier.github.io/ocilib/doc/html/group___ocilib_cpp_api_demo_list_application.html "Database notifications" (except the instance shutdown/startup)

regards

[vrogier]

Hi,

I will have a look.
On subscription.c, line 338, if you replace FREE(sub) with sub = NULL, and then recompile ocilib, does it fix the issue ?

The issues seems to be caused by the fact OcilibSubscriptionUnregister() frees the input OCI_Subscription pointer.
In case of failure in OcilibSubscriptionRegister(), the CLEANUP_AND_EXIT_FUNC block calls OcilibSubscriptionUnregister(sub) and then calls FREE(sub) where sub is already freed.

Typcipal case of double free :( That's weird I did not see that in 4.7.4 (might be a merge issue in local branchs).

I will fixe that asap !!

Regards,

Vincent

[unficyp]

hi,
thanks, yes that works, no more crashes :)

But something other caught my attention:
** Notification : sub-00 ** Database : **CDBHOME** ** Event : Object Changed .... Object : HOME.TABLE1 .... Action : Alter .... RowID :

"CDBHOME" is my container database, the PDB i'm connecting to is "HOME" - not quite sure if this is provied from oracle by design.

regards

[vrogier]

About the database name, I noticed that too recently when using pluggable databases.
in notifications, it remains the container database name. I will check if they introduced a new attribute to retrieve the PDN name.

[vrogier]

Hi,

Fix committed in v4.7.5 branch.

And about the db name issue, it seems that there is no way to retrieve the real pdb name from notifications :(

Vincent

[vrogier]

Hi,

v4.7.5 released.

btw, doc update to mention that OCI_EventGetDatabase() remains the container database.

Regards,

Vincent

[cjbj]

About the database name, I noticed that too recently when using pluggable databases.
in notifications, it remains the container database name.

I'll prod the CQN developers about it too.

[vrogier]

Thank you @cjbj :)