www.digitalmars.com         C & C++   DMDScript  

c++.stlsoft - x64 WinSTL issue with registry and scoped_handle: Urgent help needed

reply Austin Ziegler <austin.ziegler evault.com> writes:
I have an issue with scoped_handle on x64 that I need rather urgent assistance
with.

I feel like I'm actually close to figuring out the problem, but getting lost in
the corners of how abstracted things like scoped_handle are. The problem is an
exception being thrown on line 161 of scoped_handle.hpp:

   static void translate(holder_type& h, degenerate_function_type pv)
   {
        function_type   fn  =   reinterpret_cast<function_type>(pv);

        STLSOFT_ASSERT(!h.bPointer);
        STLSOFT_MESSAGE_ASSERT("function pointer must not be NULL", NULL != fn);

        fn(h.u.h); // <-- Here's line 161
   }

The call that's causing this problem is around this:

        // trying to get HKU/.DEFAULT/Environment 
    std::wstring hku_env_rk = FilenameHelper::join(m_userid_wstr,
                SystemConfiguration::HKU_ENVIRONMENT_RK_SUBPATH);
 
    try
    {
        reg_value_sequence_w env(HKEY_USERS, hku_env_rk.c_str());
 
        for (reg_value_sequence_w::const_iterator envvar = env.begin();
                    env.end() != envvar; ++envvar)
        {
            ...
        }
    }
    catch (const registry_exception&)
    {
    }
    catch (...)
    {
    }

The exception thrown is not a registry_exception, but it might be an
invalid_calling_convention_exception. 

We have that secondary catch (...), but that's completely inappropriate as we
are not able to complete this code path on x64 at all. I've got a sample
program, but it includes some of our source code that I can't post to a public
newsgroup. Can you contact me off-group to arrange the source? I can do any
testing necessary if you don't have an x64 server ready for this.

-austin
Sep 11 2008
next sibling parent "Matthew Wilson" <matthew hat.stlsoft.dot.org> writes:
Am just doing a Pantheios release, and then will attend to this. Will email you
separately now ...

"Austin Ziegler" <austin.ziegler evault.com> wrote in message
news:gac0hg$gau$1 digitalmars.com...
 I have an issue with scoped_handle on x64 that I need rather urgent assistance
with.

 I feel like I'm actually close to figuring out the problem, but getting lost
in the corners of how abstracted things like

    static void translate(holder_type& h, degenerate_function_type pv)
    {
         function_type   fn  =   reinterpret_cast<function_type>(pv);

         STLSOFT_ASSERT(!h.bPointer);
         STLSOFT_MESSAGE_ASSERT("function pointer must not be NULL", NULL !=
fn);

         fn(h.u.h); // <-- Here's line 161
    }

 The call that's causing this problem is around this:

         // trying to get HKU/.DEFAULT/Environment
     std::wstring hku_env_rk = FilenameHelper::join(m_userid_wstr,
                 SystemConfiguration::HKU_ENVIRONMENT_RK_SUBPATH);

     try
     {
         reg_value_sequence_w env(HKEY_USERS, hku_env_rk.c_str());

         for (reg_value_sequence_w::const_iterator envvar = env.begin();
                     env.end() != envvar; ++envvar)
         {
             ...
         }
     }
     catch (const registry_exception&)
     {
     }
     catch (...)
     {
     }

 The exception thrown is not a registry_exception, but it might be an
invalid_calling_convention_exception.

 We have that secondary catch (...), but that's completely inappropriate as we
are not able to complete this code path on x64 at

off-group to arrange the source? I can do any testing necessary if you don't have an x64 server ready for this.
 -austin

Sep 11 2008
prev sibling parent reply "Matthew Wilson" <matthew hat.stlsoft.dot.org> writes:
Austin

Just checking this one off as complete.

Can you let me know whether you get any issues with the next release - 1.9.55 -
which should be out today/tomorrow.

Cheers

Matt

"Austin Ziegler" <austin.ziegler evault.com> wrote in message
news:gac0hg$gau$1 digitalmars.com...
 I have an issue with scoped_handle on x64 that I need rather urgent assistance
with.

 I feel like I'm actually close to figuring out the problem, but getting lost
in the corners of how abstracted things like

    static void translate(holder_type& h, degenerate_function_type pv)
    {
         function_type   fn  =   reinterpret_cast<function_type>(pv);

         STLSOFT_ASSERT(!h.bPointer);
         STLSOFT_MESSAGE_ASSERT("function pointer must not be NULL", NULL !=
fn);

         fn(h.u.h); // <-- Here's line 161
    }

 The call that's causing this problem is around this:

         // trying to get HKU/.DEFAULT/Environment
     std::wstring hku_env_rk = FilenameHelper::join(m_userid_wstr,
                 SystemConfiguration::HKU_ENVIRONMENT_RK_SUBPATH);

     try
     {
         reg_value_sequence_w env(HKEY_USERS, hku_env_rk.c_str());

         for (reg_value_sequence_w::const_iterator envvar = env.begin();
                     env.end() != envvar; ++envvar)
         {
             ...
         }
     }
     catch (const registry_exception&)
     {
     }
     catch (...)
     {
     }

 The exception thrown is not a registry_exception, but it might be an
invalid_calling_convention_exception.

 We have that secondary catch (...), but that's completely inappropriate as we
are not able to complete this code path on x64 at

off-group to arrange the source? I can do any testing necessary if you don't have an x64 server ready for this.
 -austin

Sep 22 2008
next sibling parent Austin Ziegler <austin.ziegler evault.com> writes:
Matthew Wilson Wrote:
 Just checking this one off as complete.
 
 Can you let me know whether you get any issues with the next release - 1.9.55
- which should be out today/tomorrow.

Will do. If the changes are similar to the patches we sent you, this shouldn't be a problem. -austin
Sep 30 2008
prev sibling next sibling parent reply Gabor.Fischer systecs.com (Gabor Fischer) writes:
Hello Matthew,

I have the same problem with the latest version of STLSOFT (1.9.99) and  
Visual Studio 2008 running under Windows 7 x64. The Exception thrown is  
stlsoft::winstl_project::invalid_calling_convention_exception. It happens  
when I try to iterate over a reg_value_sequence. I traced it back to the  
very same line as Austin (see quoted message below), but didn't get  
further. It complains about an unsupported calling convention "S".



 Austin

 Just checking this one off as complete.

 Can you let me know whether you get any issues with the next release -
 1.9.55 - which should be out today/tomorrow.

 Cheers

 Matt

 "Austin Ziegler" <austin.ziegler evault.com> wrote in message
 news:gac0hg$gau$1 digitalmars.com...
 I have an issue with scoped_handle on x64 that I need rather urgent
 assistance with.

 I feel like I'm actually close to figuring out the problem, but getting
 lost in the corners of how abstracted things like

scoped_handle.hpp:
    static void translate(holder_type& h, degenerate_function_type pv)
    {
         function_type   fn  =   reinterpret_cast<function_type>(pv);

         STLSOFT_ASSERT(!h.bPointer);
         STLSOFT_MESSAGE_ASSERT("function pointer must not be NULL", NULL !=
         fn);

         fn(h.u.h); // <-- Here's line 161
    }

 The call that's causing this problem is around this:

         // trying to get HKU/.DEFAULT/Environment
     std::wstring hku_env_rk = FilenameHelper::join(m_userid_wstr,
                 SystemConfiguration::HKU_ENVIRONMENT_RK_SUBPATH);

     try
     {
         reg_value_sequence_w env(HKEY_USERS, hku_env_rk.c_str());

         for (reg_value_sequence_w::const_iterator envvar = env.begin();
                     env.end() != envvar; ++envvar)
         {
             ...
         }
     }
     catch (const registry_exception&)
     {
     }
     catch (...)
     {
     }

 The exception thrown is not a registry_exception, but it might be an
 invalid_calling_convention_exception.

 We have that secondary catch (...), but that's completely inappropriate as
 we are not able to complete this code path on x64 at

I can't post to a public newsgroup. Can you contact me off-group to arrange the source? I can do any testing necessary if you don't have an x64 server ready for this.
 -austin


So Long... Gabor
Jul 28 2010
parent Gabor.Fischer systecs.com (Gabor Fischer) writes:
Hello Matthew!

 This should now be addressed with the latest version: 1.9.105

Yes, it works now. :-) Thanks. So Long... Gabor
Jan 10 2011
prev sibling next sibling parent reply Gabor.Fischer systecs.com (Gabor Fischer) writes:
Hello Matthew,

On July 28th I wrote:

 I have the same problem with the latest version of STLSOFT (1.9.99) and
 Visual Studio 2008 running under Windows 7 x64. The Exception thrown is
 stlsoft::winstl_project::invalid_calling_convention_exception. It happens
 when I try to iterate over a reg_value_sequence. I traced it back to the
 very same line as Austin (see quoted message below), but didn't get
 further. It complains about an unsupported calling convention "S".

The problem ist still present in STLSOFT 1.9.101. This simple program can reproduce the problem: #include "stdafx.h" #include <iostream> #include <algorithm> #include "winstl/registry/reg_key_sequence.hpp" void print(const winstl::reg_key& key) { std::cout << key.name().c_str() << std::endl; } int _tmain(int argc, _TCHAR* argv[]) { try { winstl::reg_key_sequence keys(HKEY_LOCAL_MACHINE, _T("SOFTWARE\\Microsoft\\Windows\\CurrentVersion")); std::for_each(keys.begin(), keys.end(), print); return 0; } catch (std::exception& e) { std::cout << e.what() << std::endl; return 1; } } I debugged the program to find out what the problem is, and in winstl.h I found following definitions: #if defined(WIN64) # define WINSTL_OS_IS_WIN64 #elif defined(WIN32) # define WINSTL_OS_IS_WIN32 #else /* ? WIN?? */ # error WinSTL is only compatible with Win32 and Win64 #endif /* WIN?? */ But WIN64 wasn't defined. _WIN64 was. So, I added following lines to my test program, before the include of reg_key_sequence.h: #ifdef _WIN64 #define WIN64 #endif Then everything worked fine. So I googled a bit, and it seems that, for Win64 projects, _WIN64 is automatically defined, whereas WIN64 is not. So, to correct this problem, the line in winstl.h should be changed to "#if defined (_WIN64)". So Long... Gabor
Oct 20 2010
parent "Matt Wilson" <matthewwilson acm.org> writes:
This should now be addressed with the latest version: 1.9.105

"Gabor Fischer" <Gabor.Fischer systecs.com> wrote in message 
news:BbS9VkAKQNB systecs.com...
 Hell Matthew,


 The problem still exists in STLSOFT 1.9.104. The suggested workaround
 still works, but it should be included into STLSOFT.

 I have the same problem with the latest version of STLSOFT (1.9.99) and
 Visual Studio 2008 running under Windows 7 x64. The Exception thrown is
 stlsoft::winstl_project::invalid_calling_convention_exception. It 
 happens
 when I try to iterate over a reg_value_sequence. I traced it back to the
 very same line as Austin (see quoted message below), but didn't get
 further. It complains about an unsupported calling convention "S".


 The problem ist still present in STLSOFT 1.9.101. This simple program can
 reproduce the problem:

 #include "stdafx.h"
 #include <iostream>
 #include <algorithm>
 #include "winstl/registry/reg_key_sequence.hpp"

 void print(const winstl::reg_key& key)
 {
     std::cout << key.name().c_str() << std::endl;
 }

 int _tmain(int argc, _TCHAR* argv[])
 {
     try
     {
         winstl::reg_key_sequence keys(HKEY_LOCAL_MACHINE,
             _T("SOFTWARE\\Microsoft\\Windows\\CurrentVersion"));

         std::for_each(keys.begin(), keys.end(), print);
         return 0;
     }

     catch (std::exception& e)
     {
         std::cout << e.what() << std::endl;
         return 1;
     }
 }

 I debugged the program to find out what the problem is, and in winstl.h I
 found following definitions:

 #if defined(WIN64)
 # define WINSTL_OS_IS_WIN64
 #elif defined(WIN32)
 # define WINSTL_OS_IS_WIN32
 #else /* ? WIN?? */
 # error WinSTL is only compatible with Win32 and Win64
 #endif /* WIN?? */

 But WIN64 wasn't defined. _WIN64 was. So, I added following lines to my
 test program, before the include of reg_key_sequence.h:

 #ifdef _WIN64
 #define WIN64
 #endif

 Then everything worked fine. So I googled a bit, and it seems that, for
 Win64 projects, _WIN64 is automatically defined, whereas WIN64 is not. 
 So,
 to correct this problem, the line in winstl.h should be changed to "#if
 defined (_WIN64)".

 So Long...

 Gabor

So Long... Gabor

Dec 26 2010
prev sibling parent Gabor.Fischer systecs.com (Gabor Fischer) writes:
Hell Matthew,


The problem still exists in STLSOFT 1.9.104. The suggested workaround  
still works, but it should be included into STLSOFT.

 I have the same problem with the latest version of STLSOFT (1.9.99) and
 Visual Studio 2008 running under Windows 7 x64. The Exception thrown is
 stlsoft::winstl_project::invalid_calling_convention_exception. It happens
 when I try to iterate over a reg_value_sequence. I traced it back to the
 very same line as Austin (see quoted message below), but didn't get
 further. It complains about an unsupported calling convention "S".


 The problem ist still present in STLSOFT 1.9.101. This simple program can
 reproduce the problem:

 #include "stdafx.h"
 #include <iostream>
 #include <algorithm>
 #include "winstl/registry/reg_key_sequence.hpp"

 void print(const winstl::reg_key& key)
 {
     std::cout << key.name().c_str() << std::endl;
 }

 int _tmain(int argc, _TCHAR* argv[])
 {
     try
     {
         winstl::reg_key_sequence keys(HKEY_LOCAL_MACHINE,
             _T("SOFTWARE\\Microsoft\\Windows\\CurrentVersion"));

         std::for_each(keys.begin(), keys.end(), print);
         return 0;
     }

     catch (std::exception& e)
     {
         std::cout << e.what() << std::endl;
         return 1;
     }
 }

 I debugged the program to find out what the problem is, and in winstl.h I
 found following definitions:

 #if defined(WIN64)
 # define WINSTL_OS_IS_WIN64
 #elif defined(WIN32)
 # define WINSTL_OS_IS_WIN32
 #else /* ? WIN?? */
 # error WinSTL is only compatible with Win32 and Win64
 #endif /* WIN?? */

 But WIN64 wasn't defined. _WIN64 was. So, I added following lines to my
 test program, before the include of reg_key_sequence.h:

 #ifdef _WIN64
 #define WIN64
 #endif

 Then everything worked fine. So I googled a bit, and it seems that, for
 Win64 projects, _WIN64 is automatically defined, whereas WIN64 is not. So,
 to correct this problem, the line in winstl.h should be changed to "#if
 defined (_WIN64)".

 So Long...

 Gabor

So Long... Gabor
Dec 08 2010