| Bug #33031 | app linked to libmysql.lib crash if run as service in vista under localsystem | ||
|---|---|---|---|
| Submitted: | 6 Dec 2007 7:03 | Modified: | 23 Oct 2008 2:18 |
| Reporter: | Shane Bester (Platinum Quality Contributor) | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server: C API (client library) | Severity: | S1 (Critical) |
| Version: | 5.0.50 | OS: | Windows (Vista Business Edition) |
| Assigned to: | Vladislav Vaintroub | CPU Architecture: | Any |
| Tags: | crash, service, vista | ||
[6 Dec 2007 7:03]
Shane Bester
[6 Dec 2007 7:03]
MySQL Verification Team
Need second opinion of some Vista expert here before setting verified.
[17 Dec 2007 10:01]
Olivier Cante
I found exactly the same problem. Even if the UAC is off, the problem still occurs. Has anybody found a solution ? Is there a new version of libmysql which works under Vista ?
[17 Dec 2007 10:16]
Valeriy Kravchuk
Bug #33285 was marked as a duplicate of this one.
[21 Dec 2007 6:51]
Tonci Grgin
Olivier, unfortunately this is not an easy bud to figure out but we are working on it.
[6 Mar 2008 11:45]
Neil Evans
Thanks for reporting this Shane, we're having the same problem on Vista too. Running MySQL 5.0.45 Our Service is compiled in Borland c++ 6, linked with libmysql.lib only. Runs fine in command line. Tried localsystem, Administrator, other user accounts, still crashes on mysql_init() on Vista. This does not occur on any other NT platform, neither on linux where I use libmysqlclient.a to link. Doing a try..catch to try and exit with manners on exception is useless too.
[18 Mar 2008 1:24]
Matthew Paulson
MS support claims that this is happening because the dll is initing winsock from dllmain, which they claim is a "no no". - Matt Paulson paulson@busiq.com
[19 Mar 2008 13:45]
Laurent TUREK
Hi, We're having the same problem on Windows Server 2008. We're running MySQL 5.0.50 sp1 enterprise. Our Service is compiled with Visual C++ 98, linked with libmysql.lib (first listed) and many others libs. This does not occur on any other NT platform, neither on linux where we use libmysqlclient.a to link. If we link with libmysql.lib in last position, the problem does not occur... Maybe it will be helpful...
[19 Mar 2008 13:52]
Matthew Paulson
I solved the problem by statically linking the client code by using mysqlclient.lib rather than libmysql.lib. The former contains all the dll code, so it gets statically linked to you application. The later is a stub lib that causes the dll (libmysql.dll) to get loaded at which time, which according to MS, is a problem, since the dll initializes winsock from dllmain(). -- Matt
[20 May 2008 7:50]
Tonci Grgin
Matthew, thank you for your analysis.
[20 May 2008 13:21]
Tonci Grgin
Shane, I'll set this to "Verified" but only on certain aspects: - "o) link with libmysql.lib,log4cxx.lib (in that order)": Quoting wlad: One cannot simply build log4cxx 0.9.7 It is using "#import <msxml.dll>" and this dll is no more present(http://www.nabble.com/Problems-with-msxml-for-log4cxx-on-Vista-td12764184.html). So I just commented out all log4cxx stuff in the sample program and wonder, everything worked OK. Also I'm a bit skeptic about the state of log4cxx- their latest (alpha?/beta?) release 0.9.7 is 4 years old and the library has *never* been officially released. I'm still guessing what the alone presence of log4cxx might break, there is no usage of it in the sample program. Might be C++ static object initialization. Might be somehow related to msxml.dll that is not present. And Miguel: We should use msxml6.dll,available in Platform SDK feb CTP. So I agree with Vlad regarding we need an update library for that. There are also posts from Matthew to be taken into account. His last post provides acceptable workaround, Thanks.
[19 Aug 2008 15:46]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/51978 2666 Vladislav Vaintroub 2008-08-19 his patch fixes Bug#37226 Explicit call of my_thread_init() on Windows for every new thread. Bug#33031 app linked to libmysql.lib crash if run as service in vista under localsystem Bug#38522 5 seconds delay when closing application using embedded server There are some problems using DllMain hook functions on Windows that automatically do global and per-thread initialization for a DLL in MySQL context 1)per-thread initialization(DLL_THREAD_ATTACH) MySQL internally counts number of active threads that and causes a delay in in my_end() if not all threads are exited. But,there are threads that can be started either by Windows internally (often in TCP/IP scenarios) or by user himself - those threads are not necessarily using libmysql.dll functionality, but nonetheless the contribute to the count of open threads. 2)process-initialization (DLL_PROCESS_ATTACH) my_init() calls WSAStartup that itself loads DLLs and can lead to a deadlock in Windows loader. Fix is to remove dll initialization code from libmysql.dll in general case. I still leave an environment variable LIBMYSQL_DLLINIT, which if set to any value will cause the old behavior (DLL init hooks will be called). This env.variable exists only to prevent breakage of existing Windows-only applications that don't do mysql_thread_init() and work ok today. Use of LIBMYSQL_DLLINIT is discouraged and it will be removed in 6.0
[26 Aug 2008 2:05]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/52514 2666 Vladislav Vaintroub 2008-08-26 [merge] This patch fixes Bug#37226 Explicit call of my_thread_init() on Windows for every new thread. Bug#33031 app linked to libmysql.lib crash if run as service in vista under localsystem There are some problems using DllMain hook functions on Windows that automatically do global and per-thread initialization for libmysqld.dll 1)per-thread initialization(DLL_THREAD_ATTACH) MySQL internally counts number of active threads that and causes a delay in in my_end() if not all threads are exited. But,there are threads that can be started either by Windows internally (often in TCP/IP scenarios) or by user himself - those threads are not necessarily using libmysql.dll functionality, but nonetheless the contribute to the count of open threads. 2)process-initialization (DLL_PROCESS_ATTACH) my_init() calls WSAStartup that itself loads DLLs and can lead to a deadlock in Windows loader. Fix is to remove dll initialization code from libmysql.dll in general case. I still leave an environment variable LIBMYSQL_DLLINIT, which if set to any value will cause the old behavior (DLL init hooks will be called). This env.variable exists only to prevent breakage of existing Windows-only applications that don't do mysql_thread_init() and work ok today. Use of LIBMYSQL_DLLINIT is discouraged and it will be removed in 6.0
[1 Sep 2008 16:23]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/53011 2674 Vladislav Vaintroub 2008-09-01 This patch fixes Bug#37226 Explicit call of my_thread_init() on Windows for every new thread. Bug#33031 app linked to libmysql.lib crash if run as service in vista under localsystem There are some problems using DllMain hook functions on Windows that automatically do global and per-thread initialization for libmysqld.dll 1)per-thread initialization(DLL_THREAD_ATTACH) MySQL internally counts number of active threads that and causes a delay in in my_end() if not all threads are exited. But,there are threads that can be started either by Windows internally (often in TCP/IP scenarios) or by user himself - those threads are not necessarily using libmysql.dll functionality, but nonetheless the contribute to the count of open threads. 2)process-initialization (DLL_PROCESS_ATTACH) my_init() calls WSAStartup that itself loads DLLs and can lead to a deadlock in Windows loader. Fix is to remove dll initialization code from libmysql.dll in general case. I still leave an environment variable LIBMYSQL_DLLINIT, which if set to any value will cause the old behavior (DLL init hooks will be called). This env.variable exists only to prevent breakage of existing Windows-only applications that don't do mysql_thread_init() and work ok today. Use of LIBMYSQL_DLLINIT is discouraged and it will be removed in 6.0
[1 Sep 2008 18:17]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/53018 2729 Vladislav Vaintroub 2008-09-01 Bug#37226 Explicit call of my_thread_init() on Windows for every new thread. Bug#33031 app linked to libmysql.lib crash if run as service in vista under localsystem There are some problems using DllMain hook functions on Windows that automatically do global and per-thread initialization for libmysqld.dll 1)per-thread initialization(DLL_THREAD_ATTACH) MySQL internally counts number of active threads that and causes a delay in in my_end() if not all threads are exited. But,there are threads that can be started either by Windows internally (often in TCP/IP scenarios) or by user himself - those threads are not necessarily using libmysql.dll functionality, but nonetheless the contribute to the count of open threads. 2)process-initialization (DLL_PROCESS_ATTACH) my_init() calls WSAStartup that itself loads DLLs and can lead to a deadlock in Windows loader. Fix is to remove dll initialization code from libmysql.dll in general case. I still leave an environment variable LIBMYSQL_DLLINIT, which if set to any value will cause the old behavior (DLL init hooks will be called). This env.variable exists only to prevent breakage of existing Windows-only applications that don't do mysql_thread_init() and work ok today. Use of LIBMYSQL_DLLINIT is discouraged and it will be removed in 6.0
[1 Sep 2008 18:20]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/53019 2729 Vladislav Vaintroub 2008-09-01 Bug#37226 Explicit call of my_thread_init() on Windows for every new thread. Bug#33031 app linked to libmysql.lib crash if run as service in vista under localsystem There are some problems using DllMain hook functions on Windows that automatically do global and per-thread initialization for libmysqld.dll 1)per-thread initialization(DLL_THREAD_ATTACH) MySQL internally counts number of active threads that and causes a delay in in my_end() if not all threads are exited. But,there are threads that can be started either by Windows internally (often in TCP/IP scenarios) or by user himself - those threads are not necessarily using libmysql.dll functionality, but nonetheless the contribute to the count of open threads. 2)process-initialization (DLL_PROCESS_ATTACH) my_init() calls WSAStartup that itself loads DLLs and can lead to a deadlock in Windows loader. Fix is to remove dll initialization code from libmysql.dll in general case. I still leave an environment variable LIBMYSQL_DLLINIT, which if set to any value will cause the old behavior (DLL init hooks will be called). This env.variable exists only to prevent breakage of existing Windows-only applications that don't do mysql_thread_init() and work ok today. Use of LIBMYSQL_DLLINIT is discouraged and it will be removed in 6.0
[1 Sep 2008 21:49]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/53026 2675 Vladislav Vaintroub 2008-09-01 Bug#37226 Explicit call of my_thread_init() on Windows for every new thread. Bug#33031 app linked to libmysql.lib crash if run as service in vista under localsystem There are some problems using DllMain hook functions on Windows that automatically do global and per-thread initialization for libmysqld.dll 1)per-thread initialization(DLL_THREAD_ATTACH) MySQL internally counts number of active threads that and causes a delay in in my_end() if not all threads are exited. But,there are threads that can be started either by Windows internally (often in TCP/IP scenarios) or by user himself - those threads are not necessarily using libmysql.dll functionality, but nonetheless the contribute to the count of open threads. 2)process-initialization (DLL_PROCESS_ATTACH) my_init() calls WSAStartup that itself loads DLLs and can lead to a deadlock in Windows loader. Fix is to remove dll initialization code from libmysql.dll in general case. I still leave an environment variable LIBMYSQL_DLLINIT, which if set to any value will cause the old behavior (DLL init hooks will be called). This env.variable exists only to prevent breakage of existing Windows-only applications that don't do mysql_thread_init() and work ok today. Use of LIBMYSQL_DLLINIT is discouraged and it will be removed in 6.0
[1 Sep 2008 22:45]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/53031 2675 Vladislav Vaintroub 2008-09-01 Bug#37226 Explicit call of my_thread_init() on Windows for every new thread. Bug#33031 app linked to libmysql.lib crash if run as service in vista under localsystem There are some problems using DllMain hook functions on Windows that automatically do global and per-thread initialization for libmysqld.dll 1)per-thread initialization(DLL_THREAD_ATTACH) MySQL internally counts number of active threads that and causes a delay in in my_end() if not all threads are exited. But,there are threads that can be started either by Windows internally (often in TCP/IP scenarios) or by user himself - those threads are not necessarily using libmysql.dll functionality, but nonetheless the contribute to the count of open threads. 2)process-initialization (DLL_PROCESS_ATTACH) my_init() calls WSAStartup that itself loads DLLs and can lead to a deadlock in Windows loader. Fix is to remove dll initialization code from libmysql.dll in general case. I still leave an environment variable LIBMYSQL_DLLINIT, which if set to any value will cause the old behavior (DLL init hooks will be called). This env.variable exists only to prevent breakage of existing Windows-only applications that don't do mysql_thread_init() and work ok today. Use of LIBMYSQL_DLLINIT is discouraged and it will be removed in 6.0
[13 Sep 2008 20:48]
Bugs System
Pushed into 6.0.7-alpha (revid:vvaintroub@mysql.com-20080901214637-vk62y7c3aqpfdnsf) (version source revid:hakan@mysql.com-20080725175322-8wgujj5xuzrjz3ke) (pib:3)
[15 Sep 2008 8:11]
Bugs System
Pushed into 5.0.70 (revid:vvaintroub@mysql.com-20080901214637-vk62y7c3aqpfdnsf) (version source revid:vvaintroub@mysql.com-20080901214637-vk62y7c3aqpfdnsf) (pib:3)
[26 Sep 2008 12:30]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/54543 2698 He Zhenxing 2008-09-26 [merge] Merge 5.1 main -> 5.1-rpl
[29 Sep 2008 17:48]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/54682 2842 Vladislav Vaintroub 2008-09-29 Bug#37226 - Explicit call of my_thread_init() on Windows for every new thread. Bug#33031 - app linked to libmysql.lib crash if run as service in vista under localsystem. This patch completely removes DllMain() from the libmysql.dll in 6.0 eliminating explicit my_thread_init()/WSAStartup() during dll load or thread attach. This patch is slightly different from what is done in 5.0/5.1. The difference is that there is no way that to reactivate DllMain() code (in 5.x it is possible with LIBMYSQL_DLLINIT environment variable)
[29 Sep 2008 17:48]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/54683 2842 Vladislav Vaintroub 2008-09-29 Bug#37226 - Explicit call of my_thread_init() on Windows for every new thread. Bug#33031 - app linked to libmysql.lib crash if run as service in vista under localsystem. This patch completely removes DllMain() from the libmysql.dll in 6.0 eliminating explicit my_thread_init()/WSAStartup() during dll load or thread attach. This patch is slightly different from what is done in 5.0/5.1. The difference is that there is no way that to reactivate DllMain() code (in 5.x it is possible with LIBMYSQL_DLLINIT environment variable)
[1 Oct 2008 16:03]
Bugs System
Pushed into 5.1.28 (revid:vvaintroub@mysql.com-20080901214637-vk62y7c3aqpfdnsf) (version source revid:vvaintroub@mysql.com-20080901215154-1reds0fnzqdvaqsm) (pib:4)
[23 Oct 2008 2:18]
Paul DuBois
Noted in 5.0.70, 5.1.28, 6.0.7 changelogs.
[28 Oct 2008 21:03]
Bugs System
Pushed into 5.1.29-ndb-6.2.17 (revid:vvaintroub@mysql.com-20080901214637-vk62y7c3aqpfdnsf) (version source revid:tomas.ulin@sun.com-20081028140209-u4emkk1xphi5tkfb) (pib:5)
[28 Oct 2008 22:22]
Bugs System
Pushed into 5.1.29-ndb-6.3.19 (revid:vvaintroub@mysql.com-20080901214637-vk62y7c3aqpfdnsf) (version source revid:tomas.ulin@sun.com-20081028194045-0353yg8cvd2c7dd1) (pib:5)
[1 Nov 2008 9:48]
Bugs System
Pushed into 5.1.29-ndb-6.4.0 (revid:vvaintroub@mysql.com-20080901214637-vk62y7c3aqpfdnsf) (version source revid:jonas@mysql.com-20081101082305-qx5a1bj0z7i8ueys) (pib:5)
