Re: Crash with old Windows on new CPU
От | Christian Ullrich |
---|---|
Тема | Re: Crash with old Windows on new CPU |
Дата | |
Msg-id | 56E042E6.6070200@chrullrich.net обсуждение исходный текст |
Ответ на | Re: Crash with old Windows on new CPU (Magnus Hagander <magnus@hagander.net>) |
Ответы |
Re: Crash with old Windows on new CPU
|
Список | pgsql-hackers |
* Magnus Hagander wrote: > On Sat, Feb 13, 2016 at 4:45 PM, Christian Ullrich <chris@chrullrich.net> > wrote: >> On February 13, 2016 4:10:34 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> I'm also suspicious of the "#if _MSC_VER == 1800" tests, that is, >>> the code compiles on *exactly one* MSVC version. >> >> The bug exists in only that compiler version's CRT, also, that is not the >> complete version number. There may be different builds somewhere, but they >> all start with 18.0. > IIRC, the CRT itself does explicit checks against _MSC_VER == 1800. As in, > they don't actually bump that number in different build numbers. > > How does this work wrt mingw, though? Do we have the same problem there? > AIUI this code can never run on mingw, correct? Not unless mingw defines _MSC_VER. (If they do, I suggest we make Yury Zhuravlev cry and drop MinGW support instead. IMHO everyone should boycott them anyway until they come up with a working libc of their own instead of doing unspeakable things to a helpless msvcrt.dll that is not intended for use by non-system components at all. But I digress.) > I notice the code checks IsWindows7SP1OrGreater() but the comment refers to > W7SP1 *or* 2008R2 SP1. I assume this is correct, or should there actually > be a separate check for server-windows? No, that is fine. I think it's just to keep the function name from getting too ridiculously long. The functions in <versionhelpers.h> are all named for the client versions only, and only check the version number, not the client/server capability flags. Or, rather, there is a separate function to determine that. >>> That would >>> give us some context to estimate the risks of this code executing >>> when it's not really needed. >> >> Hence all the conditions. The problem is *certain* to occur under these >> specific conditions (x64 code on Windows before 7SP1 on a CPU with AVX2 >> when built with VS2013), and under no others, and these conditions flip the >> switch exactly then. > Well, it doesn't flip it based on the specifics "running on a CPU with > AVX2". But presumably turning of AVX2 if the CPU doesn't support it is a > no-op. Precisely. >> Isn't that what the buildfarm is (among other things) for? > > The buildfarm doesn't really have a big spread of Windows animals, > unfortunately. And apparently not a single one with VS 2013. OK, I'll see what I can do about setting some up soonish, at least with (server) 2008 and (client) 7. FWIW, I have a local build of 9.5.1 with this patch in daily use on 2008 now, with no complaints. -- Christian
В списке pgsql-hackers по дате отправления: