Juergen Stiebert

Hi Sergei, We do not use sanitizers, at least not for C++ code. The Github analysis is implemented to update it's code checking rules automatically via internet, so they are changing from time to time. The description from the tool is this: "This rule finds accesses through a pointer of a memory location that has already been freed (i.e. through a dangling pointer). Such memory blocks have already been released to the dynamic memory manager, and modifying them can lead to anything from a segfault...

Hi, we use it as part of a Github Enterprise license for our customer, it is not for free. Juergen

otlv4.h version 498 line 5182 Hello, we are regularly on every commit running the Github Advanced Security Checking on our code. From this tool the error "Potential use after free" is reported for the last 3 lines of the function listed above. The variables hv, inout and pl_tab_size indeed have been deleted in line 5229ff, but have been reassigned to other variables (temp_hv, temp_inout, temp_pl_tab_size) afterwards. Can this error from the tool be ignored ? Best regards Juergen void add_var(int...

Hello Sergei, yes, I did. The compilation with the newest otlv4.h works fine in VS2019 without this issue. The problem here is, that the new version differs completely from my old one, so I would have to run excessive testing of all applications using it (we have >10.000 users/day) to avoid any regression. This is possible, but not planned or budgeted currently. Doing test I have seen, that the error can be workarounded simply replacing the line: define OTL_ANSI_CPP_11_NOEXCEPT NOEXCEPT with define...

screenshot added

Hello * , We are using otlv4.h version 4.0.360 for many years in C++ applications on Windows 10 and AIX with Visual Studio 2015. Moving forward now to Vs 2019 I get a compilation warning: warning STL4006: std::uncaught_exception() is deprecated in C++17 and a compilation error: error C3646: "_NOEXCEPT": Unbekannter šberschreibungsspezifizierer from the header. Is anybody facing the same issues and is there a workaround/solution available ? I did myself some investigation and found the following section...

Hello Sergej, We took 3 measures to improve the open cursor situation: Activated the auto_commit parameter for the otl_connect::rlogon method This reduced number of open cursors and blocking sessions Duplicated the critical PL/SQL procedures in database and implemented a small dispatcher logic randomly switching between these procedures. Thereby the number of possible locks is multiplicated. Activated OTL_TRACE_LEVEL to 0x4 Analyzing the traces I found some code doing unnecessary DB calls and changed...

Hello Sergei, Ok, so there should be no difference from running this statement directly in SQL. Good. I stopped your statement after 40 minutes, cannot do test on productive environment too long. CURSOR_SHARING is set to 'FORCE' for the process running this Oracle session, not generally. Yes, it is a single database instance and connection pooling is used. It looks like we have some trouble in high load situations. We have many Oracle sessions holding locks on the same database object (PL/SQL procedures)....