xgetbv Illegal Instruction Crash

[Zelacks]

So I am using Bullet 2 (I think?) for a project that I am working on
Downloaded from the git repo, https://github.com/bulletphysics/bullet ... -alpha.zip

Basically, when the program is compiled in debug mode, and the program attempts to create a btSequentialImpulseConstraintSolver object, it crashes in the constructor, supposedly in the getCPUFeatures function.

Unhandled exception at 0x0125CDE0 in DrivingSim.exe: 0xC000001D: Illegal Instruction.

The program runs without crashing in release mode however

In CMake, I also tried changing the configuration for SSE, though the issue was already solved in http://www.bulletphysics.org/Bullet/php ... f=9&t=3569
Of course it seems the SSE is not relevant as my CPU appears to support all SSE instruction sets anyway
From what I have found from googling, it seems that my computer may not just support the use of the xgetbv instruction
So the question is, either, is there something that I am missing from my processor (Perhaps a driver update?) that prevents the xgetbv instruction from being valid. Else, is there a way to disable the xgetbv instruction, and use a set of instructions that replicate the functionality of it?
I understand completely that I basically have no idea what I am talking about, and I am trying to be humble.
I have probably missed listing a lot of relevant details, if there is anything I should post, I will post asap
Computer is a laptop:
http://www.mytoshiba.com.au/products/co ... fications/
Intel Core i5 430M
Windows 7 Professional Service Pack 1 32 Bit

Some hopefully showing information about the crash

[Granyte]

cheq that in the project property ->c++ -> code generation ->enhanced instruction set you are using sse2 and not avx
also do you have a 32 bit windows or a 64 bit?

[Zelacks]

cheq that in the project property ->c++ -> code generation ->enhanced instruction set you are using sse2 and not avx
also do you have a 32 bit windows or a 64 bit?

Is that when building bullet or when building my project (I am pretty sure I tried building bullet with and without SSE)
Anyway, I attempted to rebuild the project with the SSE2 instruction set explicitly set my project, previously it was not set
It does not seem to work, resulting in the same error.
Also I should specify this, I have two computers: a desktop and a laptop
the desktop has Windows 7 Home Premium Service Pack 1 64 Bit
The laptop (which crashes) is Windows 7 Professional Service Pack 1 32 Bit (I thought I remembered to add this, but apprantly I didnt).
But yeah, the project works fine on the desktop computer, in both debug and release
Also I should emphasis that the project runs in release mode on the laptop computer, but not in debug
Ill add these details to the OP

But of course this should go without saying, thanks for the help.

[How I solved this:] Yes! I had been doing some research (actually looking at the file) and came to the conclusion that the only conditional for having _xgetbv() called was the define BT_ALLOW_SSE4
It seems odd that the only conditional seems to be the version of the compiler used, and that it was enabled by default.

I have removed the define BT_ALLOW_SSE4 when compiling bullet in debug mode and the program no longer crashes when using the lib, I assume the only downside is that SSE4 instructions are not used when running bullet(?). Hopefully it does not cause any other issues in other parts of bullet, for example when it expects functionality from the missing code blocks.

(Basically I am not saying that this is a fix for the issue, it could cause more issues, but it may be a viable solution to the problem)

[Granyte]

alright the reason is that xgetbv is a 64 bit pointer related instruction this is why it crashes on 32 bit windows I have no idea why bullet uses it 32 bit build

[c6burns]

xgetbv reads the extended control register into two 32 bit registers and is a valid instruction on ia32 hardware. It is not used in 2.x so I assume you are using the latest.

The code in LinearMath/btCpuFeatureUtility.h looks like the example code provided by Intel that I've seen in many avx applications. xgetbv is only called if cpuid bits that indicate avx support and use of the extended control registers are set.

[Zelacks]

Thanks a heap for the responses guys, I am pretty much entirely clueless about the entire situation.
I can perhaps confirm that this is not an issue to be due to it being a 32 or 64 bit instruction, as I have tried this on another computer, which has Windows 7 64 bit and an Intel Xeon CPU processor, which also crashes on the same instruction.

c6burns, from what I have gathered from your post, it seems that bullet is just using standard code from intel, which checks the features that the cpu reports to have correct? (using the cpuid function perhaps from this topic https://software.intel.com/en-us/forums/topic/282242 )

Are you perhaps trying to imply that my cpu is reporting AVX support when getting the cpuid bits, but does not actually have avx support?
Is there a way to check what my cpu is returning from the cpu bits using a program such as CPUID CPU-Z (like shown in the original post)?
Or perhaps there is a way to explictly disallow the system from using the AVX instruction set, such as a compile setting.

[c6burns]

Checking bit 27 (OS uses XSAVE/XRSTOR) and 28 (AVX supported by CPU) of ECX after calling cpuid is the method I have most commonly seen used before calling xgetbv. Googling, it seems chrome had an issue with some users encountering this, but it seems they chalked it up to people using XP or VMs.

Bullet calls cpuid by using __cpuid. Perhaps there is some issue with that intrinsic ... or perhaps something else is going on.

You can skip that entire block by not allowing BT_ALLOW_SSE4 to be defined, in LinearMath/btScalar.h

[Zelacks]

Checking bit 27 (OS uses XSAVE/XRSTOR) and 28 (AVX supported by CPU) of ECX after calling cpuid is the method I have most commonly seen used before calling xgetbv. Googling, it seems chrome had an issue with some users encountering this, but it seems they chalked it up to people using XP or VMs.

Bullet calls cpuid by using __cpuid. Perhaps there is some issue with that intrinsic ... or perhaps something else is going on.

You can skip that entire block by not allowing BT_ALLOW_SSE4 to be defined, in LinearMath/btScalar.h

Yes! I had been doing some research (actually looking at the file) and came to the conclusion that the only conditional for having _xgetbv() called was the define BT_ALLOW_SSE4
It seems odd that the only conditional seems to be the version of the compiler used, and that it was enabled by default.

I have removed the define BT_ALLOW_SSE4 when compiling bullet in debug mode and the program no longer crashes when using the lib, I assume the only downside is that SSE4 instructions are not used when running bullet(?). Hopefully it does not cause any other issues in other parts of bullet, for example when it expects functionality from the missing code blocks.

(Basically I am not saying that this is a fix for the issue, it could cause more issues, but it may be a viable solution to the problem)

But thank you so much for your response, I would not have really known where to even begin without the feedback