[bootstrap/1.53] jam0.exe crashes when bootstrapping for VC2012 AMD64
Hi, I'm trying to build Boost 1.53 using VC2012 amd64 (toolset=msvc-11.0 address-model=64) and Windows Server 2012 Standard. Bootstrapping fails with jam0.exe crash - some crash info: Crash stacktrace: ntdll.dll!000007f9bc781069() KernelBase.dll!000007f9b978764e() KernelBase.dll!000007f9b97d3658() jam0.exe!_findnext64i32(__int64 hFile, _finddata64i32_t * pfd) Line 165 jam0.exe!file_dirscan(_object * dir, void (void *, _object *, int, __int64) * func, void * closure) Line 180 jam0.exe!builtin_glob(frame * frame, int flags) Line 718 jam0.exe!function_run(_function * function_, frame * frame, _stack * s) Line 3390 jam0.exe!evaluate_rule(_object * rulename, frame * frame) Line 264 jam0.exe!function_call_rule(_jam_function * function, frame * frame, _stack * s, int n_args, const char * unexpanded, _object * file, int line) Line 468 jam0.exe!function_run(_function * function_, frame * frame, _stack * s) Line 3950 jam0.exe!parse_file(_object * f, frame * frame) Line 57 jam0.exe!main(int argc, char * * argv, char * * arg_environ) Line 488 jam0.exe!__tmainCRTStartup() Line 241 jam0.exe!mainCRTStartup() Line 164 kernel32.dll!000007f9b9de167e() ntdll.dll!000007f9bc7a3501() Line where it crashed was: if (!FindNextFile((HANDLE)hFile, &wfd)) { I've tried to watch the values of arguments passes to FindNextFile() - hFile looked like proper handle, however wfd.cFileName and wfd.cAlternateFileName contained garbage. Is this a known issue for 1.53? I've compiled version 1.52 using the same environment and the same configuration and everything went ok, I did not manage to reproduce the crash. It looks like only version 1.53 is affected. Regards, Rafael Jeczalik
AMDG On 03/07/2013 12:17 AM, rjeczalik wrote:
Hi,
I'm trying to build Boost 1.53 using VC2012 amd64 (toolset=msvc-11.0 address-model=64) and Windows Server 2012 Standard. Bootstrapping fails with jam0.exe crash - some crash info:
Crash stacktrace:
ntdll.dll!000007f9bc781069() KernelBase.dll!000007f9b978764e() KernelBase.dll!000007f9b97d3658() jam0.exe!_findnext64i32(__int64 hFile, _finddata64i32_t * pfd) Line 165 jam0.exe!file_dirscan(_object * dir, void (void *, _object *, int, __int64) * func, void * closure) Line 180 <snip>
Line where it crashed was:
if (!FindNextFile((HANDLE)hFile, &wfd)) {
I've tried to watch the values of arguments passes to FindNextFile() - hFile looked like proper handle, however wfd.cFileName and wfd.cAlternateFileName contained garbage.
Is this a known issue for 1.53? I've compiled version 1.52 using the same environment and the same configuration and everything went ok, I did not manage to reproduce the crash. It looks like only version 1.53 is affected.
That's very odd, as b2 did not change between 1.52 and 1.53. Can you diff the tools/build/v2/engine directories in both versions just to verify this? In Christ, Steven Watanabe
On 3/7/2013 3:17 AM, rjeczalik wrote:
Hi,
I'm trying to build Boost 1.53 using VC2012 amd64 (toolset=msvc-11.0 address-model=64) and Windows Server 2012 Standard. Bootstrapping fails with jam0.exe crash - some crash info:
Crash stacktrace:
ntdll.dll!000007f9bc781069() KernelBase.dll!000007f9b978764e() KernelBase.dll!000007f9b97d3658() jam0.exe!_findnext64i32(__int64 hFile, _finddata64i32_t * pfd) Line 165 jam0.exe!file_dirscan(_object * dir, void (void *, _object *, int, __int64) * func, void * closure) Line 180 jam0.exe!builtin_glob(frame * frame, int flags) Line 718 jam0.exe!function_run(_function * function_, frame * frame, _stack * s) Line 3390 jam0.exe!evaluate_rule(_object * rulename, frame * frame) Line 264 jam0.exe!function_call_rule(_jam_function * function, frame * frame, _stack * s, int n_args, const char * unexpanded, _object * file, int line) Line 468 jam0.exe!function_run(_function * function_, frame * frame, _stack * s) Line 3950 jam0.exe!parse_file(_object * f, frame * frame) Line 57 jam0.exe!main(int argc, char * * argv, char * * arg_environ) Line 488 jam0.exe!__tmainCRTStartup() Line 241 jam0.exe!mainCRTStartup() Line 164 kernel32.dll!000007f9b9de167e() ntdll.dll!000007f9bc7a3501()
I've been running into this for a while now in different environments
and finally figured it out tonight. I think this might be specific to
the x86_amd64 compiler, but I don't have a native amd64 version to test.
The issue is kind of apparent from the callstack, as the call from
file_dirscan to _findnext actually becomes a call to _findnext64i32.
That takes a 64-bit handle, but we have a 32-bit handle that we got back
from _findfirst. That's the problem -- the handle returned from
_findfirst (_findfirst64i32) is actually 64-bit. In the best case, the
lower 32-bits of that handle happen to represent a negative value and
the function exits. More likely, you have a garbage value being passed
along, and you crash soon thereafter.
For my purposes, I simply changed the type of the handle variable from
long to uint64_t, and I now finally have a bjam for x86_64. This change
will break the x86 compile, however.
C:\src\boost_1_53_0\tools\build\v2\engine>diff -u2 filent.c.orig filent.c
--- filent.c.orig 2013-05-10 02:45:01.156195300 -0400
+++ filent.c 2013-05-10 02:19:57.535285000 -0400
@@ -34,4 +34,5 @@
# include
On Fri, May 10, 2013 at 02:56:34AM -0400, Matt Weber wrote:
I've been running into this for a while now in different environments and finally figured it out tonight. I think this might be specific to the x86_amd64 compiler, but I don't have a native amd64 version to test. The issue is kind of apparent from the callstack, as the call from file_dirscan to _findnext actually becomes a call to _findnext64i32. That takes a 64-bit handle, but we have a 32-bit handle that we got back from _findfirst. That's the problem -- the handle returned from _findfirst (_findfirst64i32) is actually 64-bit. In the best case, the lower 32-bits of that handle happen to represent a negative value and the function exits. More likely, you have a garbage value being passed along, and you crash soon thereafter.
For my purposes, I simply changed the type of the handle variable from long to uint64_t, and I now finally have a bjam for x86_64. This change will break the x86 compile, however.
If you're going to change data types, consider a type like intptr_t, which is what _findfirst seems to return according to MSDN.
C:\src\boost_1_53_0\tools\build\v2\engine>diff -u2 filent.c.orig filent.c --- filent.c.orig 2013-05-10 02:45:01.156195300 -0400 +++ filent.c 2013-05-10 02:19:57.535285000 -0400 @@ -34,4 +34,5 @@ # include
# include +# include /* @@ -80,5 +81,5 @@ string filespec[ 1 ]; string filename[ 1 ]; - long handle; + uint64_t handle; int ret; struct _finddata_t finfo[ 1 ];
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Lars Viklund | zao@acc.umu.se
[Matt Weber]
That takes a 64-bit handle, but we have a 32-bit handle that we got back from _findfirst. That's the problem -- the handle returned from _findfirst (_findfirst64i32) is actually 64-bit.
_findfirst() is documented[1] as returning intptr_t, so that's what you should be declaring your variable as. That should work on both x86 and x64. STL [1] http://msdn.microsoft.com/en-us/library/zyzxfzac.aspx
AMDG On 05/10/2013 12:11 PM, Stephan T. Lavavej wrote:
[Matt Weber]
That takes a 64-bit handle, but we have a 32-bit handle that we got back from _findfirst. That's the problem -- the handle returned from _findfirst (_findfirst64i32) is actually 64-bit.
_findfirst() is documented[1] as returning intptr_t, so that's what you should be declaring your variable as. That should work on both x86 and x64.
This looks like it has already been fixed in the trunk. In Christ, Steven Watanabe
participants (5)
-
Lars Viklund -
Matt Weber -
rjeczalik -
Stephan T. Lavavej -
Steven Watanabe