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 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?

>
> 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.

>
> 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
>