This is about a week I am trying to solve my problem and I really need help. I hope someone will find what is wrong with my setup.
(I am french so I apologize for any English mistakes)
CONTEXT
I have a Visual Studio Project which has been developed from OpenFace, a free open-source library, downloaded at that address:https://github.com/TadasBaltrusaitis/OpenFace . "Developed from" because the project just uses the code of OpenFace. I precise that the project was not made by me, I checked out from a private repository.
PROBLEM
My project build an executable but not run, stopped by an illegal instruction at the file exe_common.inl (don't know what this file is) at the line 223, before getting into in the entry point of my programm (cout << " " << endl at the very beggining of the main() function is not executed).
Here is the guilty line:
__scrt_current_native_startup_state = __scrt_native_startup_state::initialized;
Here the stack trace at that breakpoint:
CamFeaturesExtractor_Affich.exe!dlib::get_global_clock(void)
CamFeaturesExtractor_Affich.exe!00007ff63493114e()
ucrtbase.dll!_initterm()
CamFeaturesExtractor_Affich.exe!__scrt_common_main_seh() line 223
kernel32.dll!BaseThreadInitThunk()
ntdll.dll!RtlUserThreadStart()
Here the exact message exception:
Unhandled exception at 0x00007FF63499C5B7 in CamFeaturesExtractor_Affich.exe: 0xC000001D: Illegal Instruction.
WHAT I TRIED
Change VS 2017 to 2015
Build in Debug/Release in x64/x86
Change Enhanced Instruction Set in Configuration Properties > C/C++ > Code Generation to AVX, AVX2, SSE, SSE2, IA32, No Set...
Disable any optimization
That problem doesn't appear on some more recent computer (check below for my spec) so my first guess is to say that is a hardware problem. The exception is not triggered on Intel Cord Duo I5 (with same model of computer than mine). Here is my specs:
Edition : Windows 10 Professionel
Version : 1511
OS Version : 10586.679
Processor : Intel(R) Celeron(R) CPU 2950M # 2.00 GHz 2.00 GHz
RAM : 4G
System type : OS 64 bits, processeur x64
If the problem comes from my poor processor doesn't have the instruction, is there a workaround or I need to change my computer ?
Let me know if you need some informations I forgot to provide and thanks in advance if you try to help me...
EDIT
The part of disassembly where the code stop as requested:
00007FF6D635B5BD mov eax,0FFh
00007FF6D635B5C2 jmp __scrt_common_main_seh+167h (07FF6D635B6B3h)
_initterm(__xc_a, __xc_z);
00007FF6D635B5C7 lea rdx,[__xc_z (07FF6D639ED98h)]
00007FF6D635B5CE lea rcx,[__xc_a (07FF6D639EC10h)]
00007FF6D635B5D5 call _initterm (07FF6D635C4B0h)
__scrt_current_native_startup_state = __scrt_native_startup_state::initialized;
00007FF6D635B5DA mov dword ptr [__scrt_current_native_startup_state (07FF6D64162E0h)],2
}
else
00007FF6D635B5E4 jmp __scrt_common_main_seh+0A2h (07FF6D635B5EEh)
{
has_cctor = true;
00007FF6D635B5E6 mov sil,1
00007FF6D635B5E9 mov byte ptr [has_cctor],sil
}
__scrt_release_startup_lock(is_nested);
00007FF6D635B5EE mov cl,bl
00007FF6D635B5F0 call __scrt_release_startup_lock (07FF6D635B368h)
Note that exe_common.inl, as said in comment, is a Read-Only Visual Studio file located in C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\crt\src\vcruntime\exe_common.inl. I made a gist if you want to see it: https://gist.github.com/AlEmerich/281994ebbcde7d3bac88f21a85de96e2
LAST EDIT:
I don't know if it is the right way to do but I let know the audience that I give up on that problem by trying to change my computer. I have now a more recent hardware and it throws any errors. Thanks anyway for your help !
For me, remove _CRT_SECURE_NO_WARNINGS from Release Mode and try to build in Release Mode.
It should contain some errors, fix them and than it should be fine.
Related
This might be related to 38479787/c3859-virtual-memory-range-for-pch-exceeded.
A good read on PCH issues and recommendations can be found here.
After we've upgraded from VS2019 16.6 to VS2019 16.7.6, we're sometimes getting the infamous C3859 error when compiling our MSVC solutions.
We're using x64 msbuild from the command line.
/maxcpucount for MSBuild is fixed to '4'
/MP is passed, we're compiling on 8-core i7 machines.
The exact same source occasionally fails to compile with the errors
Compiler Error C3859 "virtual memory range for PCH exceeded"
System Code 1455 "The paging file is too small for this operation to complete."
Fatal error C1076 "compiler limit : internal heap limit reached"s
sample compilation output:
1342>c1xx : error C3859: Fehler beim Erstellen des virtuellen Speichers für PCH. [C:\REDACTED\REDACTED.vcxproj]
c1xx : message : Das System hat den Code 1455 zurückgegeben: Die Auslagerungsdatei ist zu klein, um diesen Vorgang durchzuführen. [C:\REDACTED\REDACTED.vcxproj]
c1xx : message : Weitere Informationen finden Sie unter https://aka.ms/pch-help. [C:\REDACTED\REDACTED.vcxproj]
1342>c1xx : fatal error C1076: Compilerlimit: Interne Heapgrenze erreicht. [C:\REDACTED\REDACTED.vcxproj]
1342>c1xx : fatal error C1076: Compilerlimit: Interne Heapgrenze erreicht. [C:\REDACTED\REDACTED.vcxproj]
The generated PCHs are up to 300MB in size.
Passing the '/Zm' switch (with values up 1000) didn't make a difference.
We've had issues with this years ago, using VS2010 - back then setting '/Zm200' solved the problem for us (note the error codes back then explicitly told us to increase to '/Zm150' or higher).
'reducing the complexity and size of our PCH files' really is not what we want to do - as we're intentionally sacrificing on memory in order to speed up our builds.
I'm wondering if there is a way to figure out what the actual underlying problem is that generates these sporadic occuring errors - and most important: how to fix it .
Actually, it is quite a headache issue for a couple of years. And the workaround which you found is the current solution and does help build your project successfully before VS2019 16.7 version. And upgrading VS to 16.7, the issue still sometimes happens with all the workarounds you have used. This does have a certain relationship with the VS IDE version and your project. This is a problem caused by two aspects.
Since you don’t want to change the PCH file, I have reported the issue on our DC Forum.
You can vote it and add any comments if I did not describe the issue in detail so that it will get more Microsoft's attention.
=======================================
If you are using VS Professional or Enterprise version and willing to accept the risk of reinstalling the previous version of VS, you can try this. And if you do not want it, you can just ignore it.
Refer to this document and uninstall the current VS version and install the related 16.6 version from that link.
Besides, you could share a minimal, reproducible sample with us if you like.
I am using a virtual machine (VPS), and the final solution for me was to increase my virtual memory pagefile size. It may be that it was only efficient due to the NVMe SSD drive, but it may work well enough for whoever is reading this, regardless.
(Credit for this guide: [MSFT]Ulzii Luvsanbat)
Open the Control Panel
Select System and Security
Select System
In the Advanced tab of the System Properties dialog, select the Performance “Settings” button
Select the Virtual Memory “Change” button on the Advanced tab
Turn off “Automatically manage paging file size for all drives” and set the Custom size. Note that you should set both the “initial size” and “maximum size” to the same value, and you should set them to be large enough to avoid the OS exhausting the page file limit.
I've got a strange behaviour on my workstation...
I'm experiencing a crash when launching debugger on a very simple program (basically the template windows application one...) and i got a exception
Exception thrown at 0x000000007719759E (ntdll.dll) in test2.exe:
0xC0000005: Access violation writing location 0x0000000000000000.
when I look in the stack trace in disassembly I am in RtlActivateActivationContextUnsafeFast (from ntdll.dll I guess)
0000000077197591 je RtlActivateActivationContextUnsafeFast+4Eh (07719755Eh)
0000000077197593 jmp string "Enabling heap debug options\n"+10B68h (0771E7B58h)
0000000077197598 cmp qword ptr [r8+8],rdx
000000007719759C je RtlActivateActivationContextUnsafeFast+6Ah (07719757Ah)
000000007719759E mov qword ptr [r9],rax
the exception occurs at the 000000007719759E
any idea on how to fix this? reinstalling VS2017 didn't help, and memory is fine (checked by memtest86)
thanks a lot
Full Stack trace of the buggy thread :
> ntdll.dll!RtlActivateActivationContextUnsafeFast() Unknown
ntdll.dll!LdrpProcessStaticImports() Unknown
ntdll.dll!LdrpLoadDll() Unknown
ntdll.dll!LdrLoadDll() Unknown
0000000000060124() Unknown
I had this similar issue with VS 2017 v15.9.11 for 64-bit exe.
If this is happening only with 64-bit version, this fix worked for me.
Go to Tools >> Options >> Debugging >>
Check this option - "Automatically close the console when debugging stops"
I've read several Q&As here regarding the fact that OpenSSL tries different instructions to test if cpu supports them, which causes SIGILL. But those answers usually state that OP was running the app under gdb, but I'm not. So my app on OpenWrt MIPS router actually crashes when using OpenSSL, whenever I make a call to OpenSSL library. The crash is illegal instruction. I actually don't have a backtrace, though my app is a debug build. It works fine on Ubuntu and MacOS.
I made sure that both my executable and ssl libs are of the same cpu architecture.
Result of cat /proc/cpuinfo:
system type : Atheros AR9330 rev 1
machine : 8devices Carambola2 board
processor : 0
cpu model : MIPS 24Kc V7.4
BogoMIPS : 265.42
wait instruction : yes
microsecond timers : yes
tlb_entries : 16
extra interrupt vector : yes
hardware watchpoint : yes, count: 4, address/irw mask: [0x0ffc, 0x0ffc, 0x0ffb, 0x0ffb]
isa : mips1 mips2 mips32r1 mips32r2
ASEs implemented : mips16
shadow register sets : 1
kscratch registers : 0
package : 0
core : 0
VCED exceptions : not available
VCEI exceptions : not available
What worries me is that toolchain toolchain-mips_34kc_gcc-5.2.0_musl-1.1.11 mentions 34kc in its name. I wonder if it's ok to build with this toolchain for 24 Kc cpu. Though everything else except for openssl works fine.
So could you please answer what are my options to fix it?
I don't know what the problem was, but the app didn't work with the openssl library provided in the toolchain and copied to target board. When libopenssl was installed via opkg from official carambola2 repos, the problem is gone. So it must have been some incompatibility.
I am Mac OS 10.11 (El Capitan) user. I used 4.6 and when I tried to build some simulation I always get "Simulation terminated with exit code: 139" and couldn’t do nothing at all with that. I thought that when I install 5.0 then everything will be fine, but now I get something like that:
Simulation terminated with exit code: 132
Working directory: /Users/JL_Data/omnetpp-5.0/samples/tictoc
Command line: tictoc -r 0 --debug-on-errors=false omnetpp.ini
Environment variables:
PATH=/Users/JL_Data/omnetpp-5.0/bin::/usr/bin:/bin:/usr/sbin:/sbin
DYLD_LIBRARY_PATH=/Users/JL_Data/omnetpp-5.0/lib::
OMNETPP_IMAGE_PATH=/Users/JL_Data/omnetpp-5.0/images
And when I tried open some simulation in terminal I get:
Illegal instruction: 4
Do you have some idea what can I do with that problem? I tried to find something on the internet, but after one day I do not get any idea.
If you need some more information, please let me know.
As it is right now, your question is not completely clear, since it requires one to be familiar with omnet++ and probably some experience installing and setting it up. However, let me make a couple guesses.
First, Illegal instruction. This usually occurs when the binary was built for an architecture different than the one it's being run on; e.g. when then SSE2 or AVX instructions are present in the binary code, but are missing on the CPU.
See, for example, this SO question:
Find which assembly instruction caused an Illegal Instruction error without debugging
There is also a question that discusses exactly your problem, namely, "Illegal instruction: 4" on OS X:
What is the "Illegal Instruction: 4" error and why does "-mmacosx-version-min=10.x" fix it?
Now, since omnet++ appears to be an open source project, I expect it to have a mailing list and / or an IRC channel. Indeed, here is the communications page on the official website that links to a Google Groups-based mailing list:
https://omnetpp.org/get-involved
https://groups.google.com/forum/#!forum/omnetpp
I advise you to get in touch with the developers with a thorough description of your problem, since the chances of them knowing the solution are significantly higher compared to the chances of there being a user on SO who has faced similar problems when installing an identical version of omnet++ on an identical version of Mac OS X.
I am getting a weird exception when I exit the program. This has started since today morning and I am ready to pull my hair out. As soon as I exit the program, visual studio gives an exception and stops at line 731 in the file crt0dat.c (see attached screenshot)
I know this is very little to go on. I have tried several different things:
un the program without doing anything, that is, not initializing Ogre Core at all. Does not result in a crash
Run the program with everything commented out except creating Ogre root (which is related to Ogre itself and has nothing to do with my code), results in the same crash
Run the following program which is as basic as it gets, still results in the crash. The crash happens after return 0, when my program has finished running
#include "windows.h"
#include "OgreRoot.h"
/// --------------------------------------------
INT WINAPI WinMain(HINSTANCE hInst, HINSTANCE, LPSTR strCmdLine, INT)
{
Ogre::Root* lRoot = new Ogre::Root();
delete lRoot;
lRoot = NULL;
return 0;
}
/// --------------------------------------------
Since I have everything on the SVN, I ran the same project on my laptop and it worked without any problems, as well as exited without any problems. This led me to believe that somewhere along the line my visual studio got corrupted. I uninstalled Visual studio, then re-installed it, but the problem persists (When VS installs it goes all over my system. No way to contain it. Does anyone know a surefire way to completely destroy Visual Studio installation?). I am running out of ideas, short of re-installing windows. I hope someone here can be of help.
Callstack:
048b0910()
ntdll.dll!775d9901()
[Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]
ntdll.dll!775edc30()
ntdll.dll!775edb7c()
kernel32.dll!76c67363()
> msvcr90d.dll!__crtExitProcess(int status=0) + 0x1b bytes C
msvcr90d.dll!doexit(int code=0, int quick=0, int retcaller=0) + 0x1d1 bytes C
msvcr90d.dll!exit(int code=0) + 0x12 bytes C
OgreFWGame.exe!__tmainCRTStartup() + 0x2a2 bytes C
OgreFWGame.exe!WinMainCRTStartup() + 0xf bytes C
kernel32.dll!76c63677()
ntdll.dll!775d9d42()
ntdll.dll!775d9d15()
Crash Screencapture:
link text
That is not how you are supposed to initialize and use Ogre. Most likely the missing initialization work is what causing your crash.
To get started with ogre I highly recommend following and learning from the tutorials
Edit:
visual studio project templates for ogre can be found here: http://code.google.com/p/ogreappwizards/updates/list to get started quickly.
Thanks for everybody's help on this problem. I ended up re-installing windows (I tried uninstalling Visual Studio and re-installing it, but something went wrong while uninstalling VS [I followed Microsoft's instructions to the letter] and it would refuse to install again [the setup would crash]). I wish they would make it easy to Uninstall Visual Studio.
I wasted about 3 days before I resorted to re-installing windows. My advice would be, if you have another computer to continue to do your work on, is to do the same if something like this happens rather than waste days. If you do find a way to fix the problem, please let me know :)
I recently set ogre up in Visual Studio 2010 and it refused to work right until I copied in the right DLLs - I had been using a set compiled from a slightly older version of ogre in Visual studio 2008. It sounds like the entire ogre compilation or the DLLs may have been copied over via the SVN which could cause strange problems.
Hope it helps, anyway.