Closed K900 closed 5 years ago
I've also pushed a fixed branch to my fork of the repo, but the policy here prevents me from submitting a pull request.
Such a bug would not happen with C++11 and range-for :) At one point, ODPI should take the plunge on modern C++, for a future version. Any plans in that direction, to use the 8 years old standard now?
Good catch! It isn't commonly discovered due to the simple fact that most of the time only a single table is being reported. :-)
The way we encountered the issue was with multiple queries and a single table, making this an out-of-bounds free.
Also, any chance of backporting this to the stable branch?
You mean 3.1.x?
Yes. I've built a fixed version locally, but it would be nice to have an upstream release.
Can you verify that the changes I just made match the ones you made yourself?
Excellent. Thanks.
Pushed to the v3.1.x branch as well.
Thanks! Waiting for the next release for this and cx_Oracle then :)
Sure. I'll give it a few days before making the patch releases for ODPI-C and cx_Oracle, though!
I've got a long running process over the weekend that's using CQN heavily (and that was crashing every few hours before the fix). I can report back on Monday if it survives :)
That would be appreciated. Thanks!
Good news: the process has survived for this whole time - about 4 days total - with no issues.
@K900 that's great. We'll schedule new releases soon.
Released in ODPI-C 3.1.2.
The code responsible for freeing CQN message objects contains a typo that causes occasional segfaults, use-after-frees, memory leaks and other related weirdness:
dpiSubscr.cpp
, line 279:The code erroneously uses
i
as a counter for freeing tables, where it should bej
.