You are viewing a plain text version of this content. The canonical link for it is here.

Posted to log4cxx-user@logging.apache.org by Michael Schumacher <Mi...@inform-software.com> on 2022/12/01 11:54:23 UTC

log4cxx-0.13.0 SetThreadDescription Entry Point Not Found

Hi,

we have an issue with log4cxx.dll, version 0.13.0; here is what we found out so far:

  *   We built log4cxx.dll on a Windows Server 2019 with cmake (from the downloaded apache-log4cxx-0.13.0.zip).
     *   In apache-log4cxx-0.13.0\src\main\include\CMakeLists.txt the four lines below activate the SetThreadDescription / GetThreadDescription calls (because in the Windows SDK on that machine processthreadapi.h contains Set/GetThreadDescription):
if(WIN32)
    CHECK_SYMBOL_EXISTS(SetThreadDescription "windows.h;processthreadsapi.h" HAS_SETTHREADDESCRIPTION)
    CHECK_SYMBOL_EXISTS(GetThreadDescription "windows.h;processthreadsapi.h" HAS_GETTHREADDESCRIPTION)
endif(WIN32)
     *   And here is the call in threadutility.cpp:
...
#elif LOG4CXX_HAS_SETTHREADDESCRIPTION
   HRESULT hr = SetThreadDescription(static_cast<HANDLE>(nativeHandle), threadName.c_str());
...
     *   That means now log4cxx.dll needs an entry point for SetThreadDescription as soon as a client program that linked log4cxx.lib is started
  *   I made a small console program (named logConsole) with only one call to log4cxx in main() (after the "Hello World!" std::cout  output):
log4cxx::helpers::LogLog::setQuietMode(true);
  *   On a Windows Server 2019 or on Windows 10, the program starts and I see 'Hello World!'
  *   Now the issue: on a Windows Server 2016 (version 1607), the program does not start up at all.
     *   In the event viewer's system log, the following "Application popup" message appears:
Application popup: logConsole.exe - Entry Point Not Found : The procedure entry point SetThreadDescription could not be located in the dynamic link library C:\Users\xyz\Documents\log4cxx.dll.

That means any program that uses this log4cxx.dll compiled on Windows 10 won't even start up on Windows Server 2016.

Here is what Microsoft says in:
https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-setthreaddescription
Windows Server 2016, Windows 10 LTSB 2016 and Windows 10 version 1607: SetThreadDescription is only available by Run Time Dynamic Linking<https://learn.microsoft.com/en-us/windows/win32/dlls/using-run-time-dynamic-linking> in KernelBase.dll.

As far as I can see there is no Run Time Dynamic Linking (via LoadLibrary) in the source code around the SetThreadDescription and GetThreadDescription calls.

Has anyone an idea what to do to avoid the problem on old machines?

My first guess is to delete these lines (but then the new calls are never made):
if(WIN32)
    CHECK_SYMBOL_EXISTS(SetThreadDescription "windows.h;processthreadsapi.h" HAS_SETTHREADDESCRIPTION)
    CHECK_SYMBOL_EXISTS(GetThreadDescription "windows.h;processthreadsapi.h" HAS_GETTHREADDESCRIPTION)
endif(WIN32)

Thank you in advance for any responses!

Best Regards,
Michael

RE: log4cxx-0.13.0 SetThreadDescription Entry Point Not Found

Posted by Michael Schumacher <Mi...@inform-software.com>.

Hi Robert,

Thank you for your second answer!

But I guess a configuration at runtime won't work.

The sheer activation of the SetThreadDescription call in the log4cxx source code (after cmake set the LOG4CXX_HAS_SETTHREADDESCRIPTION preprocessor variable) causes that the program does not start up at all on Windows Server 2016. 
SetThreadDescription is never called in my test program (because the program does not start at all; that is far before any log4cxx configuration can be read).

But your first answer was sufficient for me: we have to compile in a way that finally the SetThreadDescription call is not in the object files.

Thank you again and best regards,
Michael


----Original Message-----
From: Robert Middleton <os...@gmail.com> 
Sent: Donnerstag, 1. Dezember 2022 14:26
To: Log4CXX User <lo...@logging.apache.org>
Subject: Re: log4cxx-0.13.0 SetThreadDescription Entry Point Not Found

[You don't often get email from osfan6313@gmail.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]

Note that you may also just be able to configure this at runtime.
Assuming that you are using a configuration file to configure Log4cxx, you can probably set the ThreadConfigurationType to not name threads, meaning the code is never called.  See this documentation for more
details: https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flogging.apache.org%2Flog4cxx%2Flatest_stable%2Fthreading.html%23threading-notes&amp;data=05%7C01%7CMichael.Schumacher%40inform-software.com%7C53a5335ebb6f46ff709108dad39fae45%7C36c737afe6e84ba685f855440ef5fd6c%7C0%7C0%7C638054980019503898%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=91tk77DKRQIo8DV1W5doA2MNo8BFk2DKD1KCQNCfUHw%3D&amp;reserved=0

-Robert Middleton

On Thu, Dec 1, 2022 at 8:20 AM Robert Middleton <os...@gmail.com> wrote:
>
> Hi Michael,
>
> The best thing for me to recommend is to simply comment out the checks 
> for SetThreadDescription and GetThreadDescription as you have done.
> This is really designed to be an optional feature, such that you can 
> print out the name of the thread rather than just its ID in hex.  At 
> least under Linux and GDB this also means that the thread name will 
> show up in the debugger; I assume the same is true on Windows.
>
> -Robert Middleton
>
> On Thu, Dec 1, 2022 at 6:55 AM Michael Schumacher 
> <Mi...@inform-software.com> wrote:
> >
> > Hi,
> >
> >
> >
> > we have an issue with log4cxx.dll, version 0.13.0; here is what we found out so far:
> >
> > We built log4cxx.dll on a Windows Server 2019 with cmake (from the downloaded apache-log4cxx-0.13.0.zip).
> >
> > In apache-log4cxx-0.13.0\src\main\include\CMakeLists.txt the four lines below activate the SetThreadDescription / GetThreadDescription calls (because in the Windows SDK on that machine processthreadapi.h contains Set/GetThreadDescription):
> > if(WIN32)
> >     CHECK_SYMBOL_EXISTS(SetThreadDescription "windows.h;processthreadsapi.h" HAS_SETTHREADDESCRIPTION)
> >     CHECK_SYMBOL_EXISTS(GetThreadDescription 
> > "windows.h;processthreadsapi.h" HAS_GETTHREADDESCRIPTION)
> > endif(WIN32)
> > And here is the call in threadutility.cpp:
> > ...
> > #elif LOG4CXX_HAS_SETTHREADDESCRIPTION
> >    HRESULT hr = 
> > SetThreadDescription(static_cast<HANDLE>(nativeHandle), threadName.c_str()); ...
> > That means now log4cxx.dll needs an entry point for 
> > SetThreadDescription as soon as a client program that linked 
> > log4cxx.lib is started
> >
> > I made a small console program (named logConsole) with only one call to log4cxx in main() (after the “Hello World!” std::cout  output):
> > log4cxx::helpers::LogLog::setQuietMode(true);
> > On a Windows Server 2019 or on Windows 10, the program starts and I see ‘Hello World!’
> > Now the issue: on a Windows Server 2016 (version 1607), the program does not start up at all.
> >
> > In the event viewer’s system log, the following “Application popup” message appears:
> > Application popup: logConsole.exe - Entry Point Not Found : The procedure entry point SetThreadDescription could not be located in the dynamic link library C:\Users\xyz\Documents\log4cxx.dll.
> >
> >
> >
> > That means any program that uses this log4cxx.dll compiled on Windows 10 won’t even start up on Windows Server 2016.
> >
> >
> >
> > Here is what Microsoft says in:
> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fle
> > arn.microsoft.com%2Fen-us%2Fwindows%2Fwin32%2Fapi%2Fprocessthreadsap
> > i%2Fnf-processthreadsapi-setthreaddescription&amp;data=05%7C01%7CMic
> > hael.Schumacher%40inform-software.com%7C53a5335ebb6f46ff709108dad39f
> > ae45%7C36c737afe6e84ba685f855440ef5fd6c%7C0%7C0%7C638054980019503898
> > %7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI
> > 6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=WsKkW1AadpuB1Jjsdq
> > ZCzoTHktN84%2BFuJ2vG0tmga7o%3D&amp;reserved=0
> >
> > Windows Server 2016, Windows 10 LTSB 2016 and Windows 10 version 1607: SetThreadDescription is only available by Run Time Dynamic Linking in KernelBase.dll.
> >
> >
> >
> > As far as I can see there is no Run Time Dynamic Linking (via LoadLibrary) in the source code around the SetThreadDescription and GetThreadDescription calls.
> >
> >
> >
> > Has anyone an idea what to do to avoid the problem on old machines?
> >
> >
> >
> > My first guess is to delete these lines (but then the new calls are never made):
> >
> > if(WIN32)
> >     CHECK_SYMBOL_EXISTS(SetThreadDescription "windows.h;processthreadsapi.h" HAS_SETTHREADDESCRIPTION)
> >     CHECK_SYMBOL_EXISTS(GetThreadDescription 
> > "windows.h;processthreadsapi.h" HAS_GETTHREADDESCRIPTION)
> > endif(WIN32)
> >
> >
> >
> > Thank you in advance for any responses!
> >
> >
> >
> > Best Regards,
> >
> > Michael
> >
> >
> >
> >

Re: log4cxx-0.13.0 SetThreadDescription Entry Point Not Found

Posted by Robert Middleton <os...@gmail.com>.

Note that you may also just be able to configure this at runtime.
Assuming that you are using a configuration file to configure Log4cxx,
you can probably set the ThreadConfigurationType to not name threads,
meaning the code is never called.  See this documentation for more
details: https://logging.apache.org/log4cxx/latest_stable/threading.html#threading-notes

-Robert Middleton

On Thu, Dec 1, 2022 at 8:20 AM Robert Middleton <os...@gmail.com> wrote:
>
> Hi Michael,
>
> The best thing for me to recommend is to simply comment out the checks
> for SetThreadDescription and GetThreadDescription as you have done.
> This is really designed to be an optional feature, such that you can
> print out the name of the thread rather than just its ID in hex.  At
> least under Linux and GDB this also means that the thread name will
> show up in the debugger; I assume the same is true on Windows.
>
> -Robert Middleton
>
> On Thu, Dec 1, 2022 at 6:55 AM Michael Schumacher
> <Mi...@inform-software.com> wrote:
> >
> > Hi,
> >
> >
> >
> > we have an issue with log4cxx.dll, version 0.13.0; here is what we found out so far:
> >
> > We built log4cxx.dll on a Windows Server 2019 with cmake (from the downloaded apache-log4cxx-0.13.0.zip).
> >
> > In apache-log4cxx-0.13.0\src\main\include\CMakeLists.txt the four lines below activate the SetThreadDescription / GetThreadDescription calls (because in the Windows SDK on that machine processthreadapi.h contains Set/GetThreadDescription):
> > if(WIN32)
> >     CHECK_SYMBOL_EXISTS(SetThreadDescription "windows.h;processthreadsapi.h" HAS_SETTHREADDESCRIPTION)
> >     CHECK_SYMBOL_EXISTS(GetThreadDescription "windows.h;processthreadsapi.h" HAS_GETTHREADDESCRIPTION)
> > endif(WIN32)
> > And here is the call in threadutility.cpp:
> > ...
> > #elif LOG4CXX_HAS_SETTHREADDESCRIPTION
> >    HRESULT hr = SetThreadDescription(static_cast<HANDLE>(nativeHandle), threadName.c_str());
> > ...
> > That means now log4cxx.dll needs an entry point for SetThreadDescription as soon as a client program that linked log4cxx.lib is started
> >
> > I made a small console program (named logConsole) with only one call to log4cxx in main() (after the “Hello World!” std::cout  output):
> > log4cxx::helpers::LogLog::setQuietMode(true);
> > On a Windows Server 2019 or on Windows 10, the program starts and I see ‘Hello World!’
> > Now the issue: on a Windows Server 2016 (version 1607), the program does not start up at all.
> >
> > In the event viewer’s system log, the following “Application popup” message appears:
> > Application popup: logConsole.exe - Entry Point Not Found : The procedure entry point SetThreadDescription could not be located in the dynamic link library C:\Users\xyz\Documents\log4cxx.dll.
> >
> >
> >
> > That means any program that uses this log4cxx.dll compiled on Windows 10 won’t even start up on Windows Server 2016.
> >
> >
> >
> > Here is what Microsoft says in:
> > https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-setthreaddescription
> >
> > Windows Server 2016, Windows 10 LTSB 2016 and Windows 10 version 1607: SetThreadDescription is only available by Run Time Dynamic Linking in KernelBase.dll.
> >
> >
> >
> > As far as I can see there is no Run Time Dynamic Linking (via LoadLibrary) in the source code around the SetThreadDescription and GetThreadDescription calls.
> >
> >
> >
> > Has anyone an idea what to do to avoid the problem on old machines?
> >
> >
> >
> > My first guess is to delete these lines (but then the new calls are never made):
> >
> > if(WIN32)
> >     CHECK_SYMBOL_EXISTS(SetThreadDescription "windows.h;processthreadsapi.h" HAS_SETTHREADDESCRIPTION)
> >     CHECK_SYMBOL_EXISTS(GetThreadDescription "windows.h;processthreadsapi.h" HAS_GETTHREADDESCRIPTION)
> > endif(WIN32)
> >
> >
> >
> > Thank you in advance for any responses!
> >
> >
> >
> > Best Regards,
> >
> > Michael
> >
> >
> >
> >

RE: log4cxx-0.13.0 SetThreadDescription Entry Point Not Found

Posted by Michael Schumacher <Mi...@inform-software.com>.

Hi Robert,

Thank you for the quick answer! Ok we will comment out the checks as you proposed.

Best Regards,
Michael

-----Original Message-----
From: Robert Middleton <os...@gmail.com> 
Sent: Donnerstag, 1. Dezember 2022 14:20
To: Log4CXX User <lo...@logging.apache.org>
Subject: Re: log4cxx-0.13.0 SetThreadDescription Entry Point Not Found

[You don't often get email from osfan6313@gmail.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]

Hi Michael,

The best thing for me to recommend is to simply comment out the checks for SetThreadDescription and GetThreadDescription as you have done.
This is really designed to be an optional feature, such that you can print out the name of the thread rather than just its ID in hex.  At least under Linux and GDB this also means that the thread name will show up in the debugger; I assume the same is true on Windows.

-Robert Middleton

On Thu, Dec 1, 2022 at 6:55 AM Michael Schumacher <Mi...@inform-software.com> wrote:
>
> Hi,
>
>
>
> we have an issue with log4cxx.dll, version 0.13.0; here is what we found out so far:
>
> We built log4cxx.dll on a Windows Server 2019 with cmake (from the downloaded apache-log4cxx-0.13.0.zip).
>
> In apache-log4cxx-0.13.0\src\main\include\CMakeLists.txt the four lines below activate the SetThreadDescription / GetThreadDescription calls (because in the Windows SDK on that machine processthreadapi.h contains Set/GetThreadDescription):
> if(WIN32)
>     CHECK_SYMBOL_EXISTS(SetThreadDescription "windows.h;processthreadsapi.h" HAS_SETTHREADDESCRIPTION)
>     CHECK_SYMBOL_EXISTS(GetThreadDescription 
> "windows.h;processthreadsapi.h" HAS_GETTHREADDESCRIPTION)
> endif(WIN32)
> And here is the call in threadutility.cpp:
> ...
> #elif LOG4CXX_HAS_SETTHREADDESCRIPTION
>    HRESULT hr = 
> SetThreadDescription(static_cast<HANDLE>(nativeHandle), threadName.c_str()); ...
> That means now log4cxx.dll needs an entry point for 
> SetThreadDescription as soon as a client program that linked 
> log4cxx.lib is started
>
> I made a small console program (named logConsole) with only one call to log4cxx in main() (after the “Hello World!” std::cout  output):
> log4cxx::helpers::LogLog::setQuietMode(true);
> On a Windows Server 2019 or on Windows 10, the program starts and I see ‘Hello World!’
> Now the issue: on a Windows Server 2016 (version 1607), the program does not start up at all.
>
> In the event viewer’s system log, the following “Application popup” message appears:
> Application popup: logConsole.exe - Entry Point Not Found : The procedure entry point SetThreadDescription could not be located in the dynamic link library C:\Users\xyz\Documents\log4cxx.dll.
>
>
>
> That means any program that uses this log4cxx.dll compiled on Windows 10 won’t even start up on Windows Server 2016.
>
>
>
> Here is what Microsoft says in:
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flear
> n.microsoft.com%2Fen-us%2Fwindows%2Fwin32%2Fapi%2Fprocessthreadsapi%2F
> nf-processthreadsapi-setthreaddescription&amp;data=05%7C01%7CMichael.S
> chumacher%40inform-software.com%7Cb0923a568fd44852757d08dad39ed856%7C3
> 6c737afe6e84ba685f855440ef5fd6c%7C0%7C0%7C638054976429474379%7CUnknown
> %7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJ
> XVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=iRF24iLX3UBiB3C1adHg0ekPvi6ez7NV
> ylBIs1y8C3I%3D&amp;reserved=0
>
> Windows Server 2016, Windows 10 LTSB 2016 and Windows 10 version 1607: SetThreadDescription is only available by Run Time Dynamic Linking in KernelBase.dll.
>
>
>
> As far as I can see there is no Run Time Dynamic Linking (via LoadLibrary) in the source code around the SetThreadDescription and GetThreadDescription calls.
>
>
>
> Has anyone an idea what to do to avoid the problem on old machines?
>
>
>
> My first guess is to delete these lines (but then the new calls are never made):
>
> if(WIN32)
>     CHECK_SYMBOL_EXISTS(SetThreadDescription "windows.h;processthreadsapi.h" HAS_SETTHREADDESCRIPTION)
>     CHECK_SYMBOL_EXISTS(GetThreadDescription 
> "windows.h;processthreadsapi.h" HAS_GETTHREADDESCRIPTION)
> endif(WIN32)
>
>
>
> Thank you in advance for any responses!
>
>
>
> Best Regards,
>
> Michael
>
>
>
>

Re: log4cxx-0.13.0 SetThreadDescription Entry Point Not Found

Posted by Robert Middleton <os...@gmail.com>.

Hi Michael,

The best thing for me to recommend is to simply comment out the checks
for SetThreadDescription and GetThreadDescription as you have done.
This is really designed to be an optional feature, such that you can
print out the name of the thread rather than just its ID in hex.  At
least under Linux and GDB this also means that the thread name will
show up in the debugger; I assume the same is true on Windows.

-Robert Middleton

On Thu, Dec 1, 2022 at 6:55 AM Michael Schumacher
<Mi...@inform-software.com> wrote:
>
> Hi,
>
>
>
> we have an issue with log4cxx.dll, version 0.13.0; here is what we found out so far:
>
> We built log4cxx.dll on a Windows Server 2019 with cmake (from the downloaded apache-log4cxx-0.13.0.zip).
>
> In apache-log4cxx-0.13.0\src\main\include\CMakeLists.txt the four lines below activate the SetThreadDescription / GetThreadDescription calls (because in the Windows SDK on that machine processthreadapi.h contains Set/GetThreadDescription):
> if(WIN32)
>     CHECK_SYMBOL_EXISTS(SetThreadDescription "windows.h;processthreadsapi.h" HAS_SETTHREADDESCRIPTION)
>     CHECK_SYMBOL_EXISTS(GetThreadDescription "windows.h;processthreadsapi.h" HAS_GETTHREADDESCRIPTION)
> endif(WIN32)
> And here is the call in threadutility.cpp:
> ...
> #elif LOG4CXX_HAS_SETTHREADDESCRIPTION
>    HRESULT hr = SetThreadDescription(static_cast<HANDLE>(nativeHandle), threadName.c_str());
> ...
> That means now log4cxx.dll needs an entry point for SetThreadDescription as soon as a client program that linked log4cxx.lib is started
>
> I made a small console program (named logConsole) with only one call to log4cxx in main() (after the “Hello World!” std::cout  output):
> log4cxx::helpers::LogLog::setQuietMode(true);
> On a Windows Server 2019 or on Windows 10, the program starts and I see ‘Hello World!’
> Now the issue: on a Windows Server 2016 (version 1607), the program does not start up at all.
>
> In the event viewer’s system log, the following “Application popup” message appears:
> Application popup: logConsole.exe - Entry Point Not Found : The procedure entry point SetThreadDescription could not be located in the dynamic link library C:\Users\xyz\Documents\log4cxx.dll.
>
>
>
> That means any program that uses this log4cxx.dll compiled on Windows 10 won’t even start up on Windows Server 2016.
>
>
>
> Here is what Microsoft says in:
> https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-setthreaddescription
>
> Windows Server 2016, Windows 10 LTSB 2016 and Windows 10 version 1607: SetThreadDescription is only available by Run Time Dynamic Linking in KernelBase.dll.
>
>
>
> As far as I can see there is no Run Time Dynamic Linking (via LoadLibrary) in the source code around the SetThreadDescription and GetThreadDescription calls.
>
>
>
> Has anyone an idea what to do to avoid the problem on old machines?
>
>
>
> My first guess is to delete these lines (but then the new calls are never made):
>
> if(WIN32)
>     CHECK_SYMBOL_EXISTS(SetThreadDescription "windows.h;processthreadsapi.h" HAS_SETTHREADDESCRIPTION)
>     CHECK_SYMBOL_EXISTS(GetThreadDescription "windows.h;processthreadsapi.h" HAS_GETTHREADDESCRIPTION)
> endif(WIN32)
>
>
>
> Thank you in advance for any responses!
>
>
>
> Best Regards,
>
> Michael
>
>
>
>