Re: [cx-oracle-users] Using cx_Oracle 6.0rc1 on Windows

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

On Wed, Jul 5, 2017 at 4:12 PM, Anthony Tuininga <ant...@gm...
> wrote:

> On Wed, Jul 5, 2017 at 8:21 AM, Anthony Tuininga <
> ant...@gm...> wrote:
>
>>
>>
>> On Wed, Jul 5, 2017 at 6:29 AM, Walter Dörwald <wa...@li...>
>> wrote:
>>
>>> On 4 Jul 2017, at 16:35, Anthony Tuininga wrote:
>>>
>>> On Tue, Jul 4, 2017 at 3:18 AM, Walter Dörwald <wa...@li...>
>>>> wrote:
>>>>
>>>> On 3 Jul 2017, at 15:59, Anthony Tuininga wrote:
>>>>>
>>>>> Hi Walter,
>>>>>
>>>>>>
>>>>>> DPI_DEBUG_LEVEL=7 causes a bunch of output that tells me which public
>>>>>> ODPI-C functions are being called. The fact that you are not getting
>>>>>> any
>>>>>> at
>>>>>> all suggests something is going wrong even before cx_Oracle code is
>>>>>> involved. Can you try a few more things?
>>>>>>
>>>>>> 1) Use python -v so you can see if the error is occurring prior to the
>>>>>> actual import of cx_Oracle (it may not help but it might, too)
>>>>>>
>>>>>>
>>>>> Here is the output of importing cx_Oracle in a verbose Python session:
>>>>> [...]
>>>>> Traceback (most recent call last):
>>>>>   File "<stdin>", line 1, in <module>
>>>>>   File "<frozen importlib._bootstrap>", line 961, in _find_and_load
>>>>>   File "<frozen importlib._bootstrap>", line 950, in
>>>>> _find_and_load_unlocked
>>>>>   File "<frozen importlib._bootstrap>", line 648, in _load_unlocked
>>>>>   File "<frozen importlib._bootstrap>", line 560, in module_from_spec
>>>>>   File "<frozen importlib._bootstrap_external>", line 922, in
>>>>> create_module
>>>>>   File "<frozen importlib._bootstrap>", line 205, in
>>>>> _call_with_frames_removed
>>>>> UnicodeDecodeError: 'utf-8' codec can't decode byte 0xe4 in position
>>>>> 66:
>>>>> invalid continuation byte
>>>>>
>>>>>
>>>> Looks like it may have started running code in the module as the first
>>>> thing it does is imports the datetime and decimal modules. If you're
>>>> able
>>>> to add some printf() statements at key positions in the
>>>> Module_Initialize()
>>>> function in src/cx_Oracle.c that would be helpful. In particular, at the
>>>> very beginning (to confirm that it is running), after the imports, after
>>>> the PyModule_Create() call, just prior to the dpiContext_create() call,
>>>> just after it, and just at the end. I wish I could replicate this
>>>> myself!
>>>>
>>>
>>> We've found the spot where the error occurs with the following patch:
>>>
>>> ============================================================
>>> ====================
>>>
>>> C:\checkouts\python-cx_Oracle\odpi>git diff
>>> diff --git a/src/dpiOci.c b/src/dpiOci.c
>>> index f881bed..e588b1c 100644
>>> --- a/src/dpiOci.c
>>> +++ b/src/dpiOci.c
>>> @@ -1338,6 +1338,7 @@ static int dpiOci__loadLib(dpiError *error)
>>>  #ifdef _WIN32
>>>      DWORD length, errorNum;
>>>  #endif
>>> +    printf("Start dpiOci__loadLib()\n");
>>>
>>>      // dynamically load the OCI library
>>>      for (i = 0; !dpiOciLibHandle; i++) {
>>> @@ -1356,6 +1357,7 @@ static int dpiOci__loadLib(dpiError *error)
>>>              if (length > 3)
>>>                  loadError[length - 3] = '\0';
>>>              else strcpy(loadError, "DLL load failed");
>>> +            printf("loadError: %s\n",loadError);
>>>          }
>>>  #else
>>>          dpiOciLibHandle = dlopen(libName, RTLD_LAZY);
>>> @@ -1370,6 +1372,7 @@ static int dpiOci__loadLib(dpiError *error)
>>>          return dpiError__set(error, "load library",
>>> DPI_ERR_LOAD_LIBRARY,
>>>                  loadError);
>>>
>>> +    printf("After LoadLibrary()\n");
>>>      // validate library
>>>      if (dpiOci__loadLibValidate(error) < 0) {
>>>  #ifdef _WIN32
>>>
>>> ============================================================
>>> ====================
>>>
>>> With this patch, we get the following output:
>>>
>>> ============================================================
>>> ====================
>>>
>>> import cx_Oracle
>>>>>>
>>>>> Start dpiOci__loadLib()
>>> loadError: %1 ist keine zulõssige Win32-Anwendung
>>> Traceback (most recent call last):
>>>   File "<stdin>", line 1, in <module>
>>>   File "<frozen importlib._bootstrap>", line 961, in _find_and_load
>>>   File "<frozen importlib._bootstrap>", line 950, in
>>> _find_and_load_unlocked
>>>   File "<frozen importlib._bootstrap>", line 648, in _load_unlocked
>>>   File "<frozen importlib._bootstrap>", line 560, in module_from_spec
>>>   File "<frozen importlib._bootstrap_external>", line 922, in
>>> create_module
>>>   File "<frozen importlib._bootstrap>", line 205, in
>>> _call_with_frames_removed
>>> UnicodeDecodeError: 'utf-8' codec can't decode byte 0xe4 in position 66:
>>> invalid continuation byte
>>>
>>> ============================================================
>>> ====================
>>>
>>> "%1 ist keine zulõssige Win32-Anwendung" (which should read "%1 ist
>>> keine zulässige Win32-Anwendung", i.e. the "ö" should be an "ä") means "%1
>>> is not an acceptable win32 application".
>>>
>>> So we don't see the real problem because cx_Oracle fails to create the
>>> proper Unicode string from the OS error message.
>>>
>>> It's not clear what encoding this is (probable latin-1 or cp1252, but
>>> definitely *not* UTF-8). A
>>>
>>>    grep 'xe4.*LATIN SMALL LETTER A WITH DIAERESIS' Lib/encodings/*.py
>>>
>>> in the Python source code returns 40 encodings that map the byte 0xE4 to
>>> ä.
>>>
>>> If the correct encoding can't be determined from the environment it
>>> might be best to use a less strict error handling (like e.g.
>>> backslashreplace) when decoding the bytes of the error message.
>>>
>>
>> Thanks, Walter. This is very helpful. We'll have to see what makes the
>> most sense in this case. Do you see information in the event log regarding
>> this error?
>>
>
> I have discovered the source of the problem. I was able to replicate the
> issue thanks to this pointer and have corrected it in the source. If you
> can do a new pull and compile you should get the correct error message now.
> If you can confirm that would be helpful! Thanks.
>

Just to be clear since the process is a bit different now: in your
cx_Oracle repository you need to issue the following commands:

git pull
git submodule update

That will update ODPI-C (where the correction was made) as well as
cx_Oracle itself.

>
>
>>
>>
>>>
>>> And of cause it would help if %1 was resolved to a useful filename.
>>>
>>
>> Naturally. But that information isn't directly provided. I'll look into
>> that, too.
>>
>
> This is a limitation of Windows and there isn't much that can be done
> about it. Sorry!
>
>
>>
>>
>>>
>>> But now for the real error...
>>>
>>> [...]
>>>>
>>>>>
>>>>> I also note that you are using VS 2017. Another person noted that
>>>>>
>>>>>> uninstalling VS 2017 and using an earlier version worked for him --
>>>>>> why
>>>>>> that would be is an interesting question (!!?) but if you have a
>>>>>> machine
>>>>>> that doesn't have VS 2017 but an earlier version that would be worth
>>>>>> testing, too.
>>>>>>
>>>>>>
>>>>> We currently don't have a Windows 10 machine without VS 2017, but we're
>>>>> going to
>>>>> uninstall VS 2017 on this machine and retry with and an older version.
>>>>>
>>>>> Also, IIRC this exception means that the VS Redistributables are
>>>>> missing
>>>>> or are
>>>>> installed incorrectly.
>>>>>
>>>>> However I don't know how we can check this.
>>>>>
>>>>
>>>>
>>>> You can use this tool: http://www.dependencywalker.com/ which will
>>>> tell you
>>>> what dependencies the cx_Oracle.pyd file and all of their dependencies,
>>>> too. Hopefully it helps.
>>>>
>>>
>>> OK, we tried that. The output is here:
>>>
>>>    http://styx.livinglogic.de/~walter/cx_Oracle/cx_Oracle.cp36
>>> -win_amd64.txt
>>>
>>> dependencywalker seem that have many problems with this DLL, but what
>>> sticks out is VCRUNTIME140.dll. This seems to be part of the "Visual C++
>>> Redistributable for Visual Studio 2015" which we downloaded from here:
>>>
>>>    https://www.microsoft.com/en-us/download/details.aspx?id=48145
>>>
>>> (we've downloaded vc_redist.x64.exe). When we install it, it complains
>>> that another version is already installed. After we've uninstalled the 2017
>>> Redistributables installation works, but the output of "import cx_Oracle"
>>> remains the same.
>>>
>>
>> So the problem isn't resolved by the change of VS redistributable. Can
>> you take a look in the event log? Can you also provide a list of all of the
>> VS redistributables you have installed? I am going to try to replicate this
>> myself.
>>
>>
>>>
>>> [...]
>>>>
>>>
>>> Servus,
>>>    Walter
>>>
>>> ------------------------------------------------------------
>>> ------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> cx-oracle-users mailing list
>>> cx-...@li...
>>> https://lists.sourceforge.net/lists/listinfo/cx-oracle-users
>>>
>>
>>
>