How to fix permanent EXC_BAD_ACCESS exception in Xcode using SystemC? - xcode

I want to write SystemC code using the Xcode IDE. I have set it all up and the code I use for testing my Installation builds just fine, but it runs always into Thread 1: EXC_BAD_ACCESS exception, no matter what I do.
I tried to comment everything out, until only the systemc header include and the sc_main was left. When I tried normal c++ code in a different project, to see if it was a general Xcode problem, it work fine and ran into no exception.
I use this generic Hello World-code to test my Installation:
#include <systemc>
//Hello_world is module name
SC_MODULE (hello_world) {
SC_CTOR (hello_world) {
// Nothing in constructor
}
void say_hello() {
//Print "Hello World" to the console.
std::cout << "Hello World.\n";
}
};
// sc_main in top level function like in C++ main
int sc_main(int argc, char* argv[]) {
hello_world hello("HELLO");
//Print the hello world
hello.say_hello();
return(0);
}
After the code ran for a few seconds, it always crashes with: Thread 1: EXC_BAD_ACCESS (code=2, address=0x7ffeef3ffff8).
EDIT:
My Config:
- SystemC: v2.3.3
- Xcode: v10.2.1 (10E1001)
- Compiler: (I ran gcc --version)
- LLV: v10.0.1 (clang-1001.0.46.4)
- c++: v4.2.1
Im using std=gnu++98 (Compiler Default) as c++language Dialect, everything else ran into build errors.

EXC_BAD_ACCESS happens when system can not return from an execution block, such as infinite loop or recursion.
you should take a look at stack trace in the Debugger navigator and see which function is getting called and never returns OR which function(s) are calling over and over.
Don't forget to run project in DEBUG mode. (NOT release)

If you're using SystemC 2.3.2, you might be running into the following issue (on macOS 10.13 or later): http://forums.accellera.org/topic/6079-make-check-return-fail/. This issue is assumed to be fixed in SystemC 2.3.3.
You can avoid it by compiling SystemC 2.3.2 with ../configure --disable-async-updates ... or by moving to SystemC 2.3.3 and enabling C++11 (might be the default on a recent Xcode version, you can check the value of the SC_CPLUSPLUS macro in your model).

I did it! I built SystemC with Cmake following the steps provided in this answer: Setting up a SystemC project with CMake: undefined reference to sc_core
. In the CMakeLists.txt I set CMAKE_CXX_STANDARD explicitly to 11 and built the project via the command line and cmake.
Thanks for the help:)

Related

Which build of gcc should I use to correctly build rustlearn crate?

I'm trying to use rustlearn crate in my project. Added the dependency in Cargo.toml.
Since rustlearn requires gcc, I downloaded and installed MinGW64.
I tried the following gcc builds:
x86_64-8.1.0-posix-seh-rt_v6-rev0
x86_64-8.1.0-posix-sjlj-rt_v6-rev0
i686-8.1.0-posix-sjlj-rt_v6-rev0
each time setting a PATH environment variable to the appropriate g++.exe and restarting VSCode.
But everytime I tried to build my Rust package I got a such error:
= note: C:\Rust\PF\machinelearning\target\debug\deps\librustlearn-4ae611e3fd449ac0.rlib(svm.o): In function `ZN6KernelC2EiPKP8svm_nodeRK13svm_parameter':
C:\Git-local-repos\rustlearn/dependencies/libsvm/svm.cpp:256: undefined reference to `__gxx_personality_sj0'
C:\Git-local-repos\rustlearn/dependencies/libsvm/svm.cpp:256: undefined reference to `_Unwind_SjLj_Register'
C:\Git-local-repos\rustlearn/dependencies/libsvm/svm.cpp:258: undefined reference to `_Unwind_SjLj_Resume'
C:\Git-local-repos\rustlearn/dependencies/libsvm/svm.cpp:289: undefined reference to `_Unwind_SjLj_Unregister'
repeated many times.
I realize that the problem is somehow related to exception handling (seh/sjlj).
My system is Windows 7 x86-64, rust toolchain is stable-i686-pc-windows-gnu.
What am I doing wrong?
I found that the right build of MinGW is i686-7.1.0-posix-dwarf-rt_v5-rev2.
I did not run into these errors when I created a MWE.
To me, this looks like you are trying to use gcc to link a *.o that was compiled with g++.
I was unable to replicate your problem. Here's what I did--which resulted in a successfully built project:
I created a new project with cargo new and added the following to Cargo.toml:
rustlearn = "0.5.0"
I ran cargo check to download all the required dependencies.
I edited src/main.rs to include the logistic regression example from here, modified so that it was called in a main() function.
I ran cargo build, which successfully compiled crossbeam, libc, serde, rand, rustlearn, and rustlearn-test--the name of my test package. Several linting warnings were outputted; they were ignored.
I ran cargo run, which successfully ran the program.
FWIW, I'm using the WSL on Windows 10.

LLDB 3.9.0 Crashing (CLion)

here is a link to a C++ (CLion) project. I've distilled/simplified the issue down as much as I could.
The problem is that when debugging, LLDB (version 3.9.0) crashes.
Steps to reproduce crash:
Open project with CLion 2017.1 (use built in LLDB for debug)
Compile the Project
Place breakpoint in main.cpp line 14
Run in debug mode.
Once you're at line 14 breakpoint, then output the variable "an_integer" via the "print an_integer" command.
Crash
The Error/Crash Report:
Assertion failed: (D->getCachedLinkage() == LV.getLinkage()), function
getLVForDecl, file
/Applications/buildAgent/work/92515a49514b3993/lldb/llvm/tools/clang/lib/AST/Decl.cpp,
line 1360.
Note that this crash occurs with LLDB v3.9.0 on Mac v10.12.4. But it does not occur with LLDB 3.7.0 on Mac 10.12.4.
Ultimately, I'm wanting to know if I'm doing something dumb in my project code? If not, is this a bug with CLion or LLDB? Is there somewhere that I should post this to help get the bug (if it is that) resolved?
That doesn't look like your bug. For some reason lldb is having trouble ingesting the type information produced by the compiler.
I don't have clion so I can't try that, but if I just build your test project, either with a PCH or without, using clang from Xcode 8.3 I don't see this crash. Best thing to do is to build this project with CLion, then make a dSYM (if CLion doesn't do this for you.) You do that by running:
> dsymutil TestingLLDBBreaking
Check that you can reproduce the crash with the dSYM, and if so then file a bug with http://bugreporter.apple.com with the executable and the .dSYM.
So I had the same problem for a while.
just before almost formatting my mac I've re-cloned the project to a different directory and ran it from there. No issues. (i'm sure its a mac-os thing).
Good luck :)

Using libtorrent with MSVS 2013

I installed libtorrent (version 1.0.2) with the NuGet package manager in MSVS 2013. When I run this to see if I can use it:
#include <libtorrent\session.hpp>
using libtorrent::session;
int main()
{
// session ses;
return 0;
}
I get the error error C1021: invalid preprocessor command 'warning'.
This takes me to project_source\packages\libtorrent-src.1.0.2\lib\native\libtorrent\include\libtorrent\config.hpp to a line:
#warning unknown OS, assuming BSD
I'm not sure what that's about, I tried changing it to #error as per a post on cplusplus.com, but the same error came up. Probably foolishly, I commented that line out to see what happens, and now it's taking me to project_source\packages\libtorrent-src.1.0.2\lib\native\libtorrent\include\libtorrent\file.hpp saying that
error C1083: Cannot open include file: 'unistd.h': No such file or directory
Any ideas how to fix this? I tried not using NuGet, but I couldn't figure out how to use libtorrent from downloading source. The website wasn't much help to me.
looking in config.hpp, the assumption is that the WIN32 macro is defined on windows. In your case, that appears to not be the case.
Perhaps you could try to change it to test for _WIN32 instead.

QT Windows Desktop GUI program crashes in Release mode but does not crash in Debug mode

I have this strange problem where running the release version of my GUI app on Windows crashes at startup and prints out the following (abridged) output:
Starting C:........\build-WindowsUI-Desktop_Qt_5_4_0_MSVC2010_OpenGL_32bit-Release\release\WindowsUI.exe...
The program has unexpectedly finished.
C:.............\build-WindowsUI-Desktop_Qt_5_4_0_MSVC2010_OpenGL_32bit-Release\release\WindowsUI.exe crashed
There is no other information given. Compiler output seems normal and no crash detailed information is printed. When I run the debug version: everything is fine. The GUI runs normally and no problems encountered.
Has anyone else encountered something like this before? I'm stuck here.
Thank you Mailerdaimon!
I took at look at my QT project file. In my .pro file I tell the linker to use specific dlls for release and debug mode. Based on your idea, I tried commenting out the sections that specify the dlls based on which type of executable was being outputted:
#win32|win64:debug {
# need to link DLL versions of library for Debug
#LIBS += -L"../ThirdParty/thirdPartyDlls" \
#
# -lthirdPartyD
#
#}
#win32|win64:release {
# need to link DLL versions of library for release
LIBS += -L"../ThirdParty/thirdPartyDlls" \
-lthirdParty
#}
And now release mode works! I guess I used the wrong syntax in the .pro file or maybe it's a bug in Qt Creator. Either way I got it working now :). Thanks again!

MinGW on Windows 8

My OS is windows 8 and I am using MinGW version 4.6.1. When I compile using gcc it compiles well. But on running it throws the below error:
This version of C:\Users\danish\Documents\a.exe is not compatible with the versi
on of Windows you're running. Check your computer's system information and then
contact the software publisher.
Is there any stable version out there for Windows 8? or any other substitutes
Use mingw32-gcc.exe to compile your source code rather than gcc.exe. I don't know whether it works because I don't have a Windows 8, but you can try it anyway.
The earliest version of gcc I have available for testing is 4.6.3. It works just fine for me on 64-bit Windows 8.
// -*- compile-command: "gcc -o test.exe test.cpp"; -*-
#include <stdio.h>
int main ()
{
puts ("Hello, World!");
}
Output: "Hello, World!".
Perhaps you are using a gcc that targets 64-bit Windows, then running the program on 32-bit Windows. What does gcc -v 2>&1 | find "Target:" output? What does systeminfo | find "System Type" output?
#Jatin, I faced that same problem as yours. What I did was, I wrote a program in notepad++ and then saved it as a cpp file. Hence it was assigned a default extension of ".h". Now whenever I compiled it using g++, a 32 bit exe was created which threw the same error you mentioned above. What I did to overcome the above problem was, I manually changed the extension of the file to ".cpp" and then complied it. In this case, a 64 bit exe file was created which ran successfully thereby displaying the correct output.
I agree that this does not solve the issue, but it surely provides a work around. Hope this helps! :)

Resources