Win32 API stack walk with MinGW/MSYS? - c++

i've to develop a stack trace walk to our win32 API plattform support to catch any exception with a behaviour of a JAVA stacktrace. Actually we got a full functional implementation for Linux plattforms.
First i've tried to implement a stackwalk using the win32 CaptureStackBackTrace API
mechanism. But this method is not integrated in the actually winbase header of mingw (using MSYS/MinGW 5.1.x) ...
So i decided tried use the dbgheader mechanism follwoing the instructions of this link :
http://sites.google.com/site/kenscode/prime-programs/boinc-with-mingw-on-win32
But i fail again and run into linker failures i could not solve. I think MinGW could not resolve the dbgheader library ....
DrMinGW is not an option for me, while it is a JIT Debugger, i've to implement a stack trace mechansim, for any exception occuring on runtime with a customizable log file tracebility like we know from JAVA ...
Has anyone get MSYS/MinGW runable with the win32 API in handshake? I will not change the compiler to the ugly MVC compiler instead of using MSYS/MinGW...
Thanks for any hint.
Best regards,
Christian

Check Mr. Edd's stack trace library at the following link. It will produce a nice stack frame listing and has specific code to support MinGW.
http://www.mr-edd.co.uk/code/stack_trace
His library uses dbghelp.dll, however, so you may get into some problems trying to compile it. As far as I know, MinGW doesn't include an import library for this DLL (see a old feature request here). I had success, however, creating one import library myself. You can do the same just using a .def file from the Wine project (check the previous link's attached files for one) and running the MingW utility dlltool:
dlltool -k -d dbghelp.def -l dbghelp.a
You can then include the resulting dbghelp.a file in your project. You won't probably like to have dependencies towards dbghelp.dll in your release builds, as the DLL itself is surely not redistributable.

Here is a method to walk the call stack using the Win32 API which you can call from MinGW.
http://www.codeproject.com/KB/threads/StackWalker.aspx

I got stack traces working in MingGW with Edd's dbg library, which is a successor to his minimal stack_trace library:
With msys2, this should get you a stack trace:
$ pacman -S mingw-w64-x86_64-edd-dbg
// main.cpp
#include <dbg/frames.hpp>
#include <dbg/symbols.hpp>
#include <iostream>
int main()
{
dbg::symdb db;
dbg::call_stack<64> traceback;
traceback.collect(0);
traceback.log(db, std::cout);
return 0;
}
$ g++ -ggdb main.cpp -ldbg
$ ./a.exe
0x0000000000402ee9: dbg::call_stack<64u>::collect(unsigned int) in C:\msys64\home\phil\stacktrace-example\a.exe
0x00000000004015f2: main in C:\msys64\home\phil\stacktrace-example\a.exe
0x00000000004013f8: __tmainCRTStartup in C:\msys64\home\phil\stacktrace-example\a.exe
0x000000000040151b: mainCRTStartup in C:\msys64\home\phil\stacktrace-example\a.exe
0x00007ffbb0838102: BaseThreadInitThunk in C:\WINDOWS\system32\KERNEL32.DLL
0x00007ffbb27cc5b4: RtlUserThreadStart in C:\WINDOWS\SYSTEM32\ntdll.dll
More about dbg can be found in the Wiki. The code is available here: https://bitbucket.org/edd/dbg/src

Related

`cabal repl` causes GHC panic on simple project with C++ files

I've uploaded the project as a zip file so you can try it out.
https://dl.dropboxusercontent.com/u/35032740/ShareX/2015/11/Buggy.zip
I wanted to write a wrapper around the clipper library. The code compiles fine with cabal build, runs with cabal run but cabal repl produces this error:
Preprocessing executable 'Buggy' for Buggy-0.1.0.0...
GHCi, version 7.10.2: http://www.haskell.org/ghc/ :? for help
GHC runtime linker: fatal error: I found a duplicate definition for symbol
_ZNSt6vectorIN10ClipperLib8IntPointESaIS1_EE13_M_insert_auxEN9__gnu_cxx17__normal_iteratorIPS1_S3_EERKS1_
whilst processing object file
dist\build\Buggy\Buggy-tmp\wrapper.o
This could be caused by:
* Loading two different object files which export the same symbol
* Specifying the same object file twice on the GHCi command line
* An incorrect `package.conf' entry, causing some object to be
loaded twice.
ghc.exe: panic! (the 'impossible' happened)
(GHC version 7.10.2 for x86_64-unknown-mingw32):
loadObj "dist\\build\\Buggy\\Buggy-tmp\\wrapper.o": failed
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
For reference, here's the cabal file
-- Initial Buggy.cabal generated by cabal init. For further documentation,
-- see http://haskell.org/cabal/users-guide/
name: Buggy
version: 0.1.0.0
-- synopsis:
-- description:
-- license:
license-file: LICENSE
author: Luka Horvat
maintainer: lukahorvat9#gmail.com
-- copyright:
-- category:
build-type: Simple
-- extra-source-files:
cabal-version: >=1.10
executable Buggy
main-is: Main.hs
c-sources: clipper.cpp
, wrapper.cpp
-- other-modules:
-- other-extensions:
build-depends: base >=4.8 && <4.9
-- hs-source-dirs:
default-language: Haskell2010
extra-libraries: stdc++
Any ideas what the cause might be here?
I'm running Windows 10, 64bit.
I don't know the details of object file formats on Windows, so I'm guessing a bit.
Probably clipper.o and wrapper.o both define a weak symbol named _ZNSt6vectorIN10ClipperLib8IntPointESaIS1_EE13_M_insert_auxEN9__gnu_cxx17__normal_iteratorIPS1_S3_EERKS1_. (I see the same on Linux.) This probably came from a template instantiation (of vector). Weak symbols instruct the system linker to just pick any copy of the symbol if it encounters duplicates.
GHCi on Windows doesn't use the system linker, it has its own runtime linker that can load object files into itself while it runs. As a result it is generally not feature compatible with the system linker. Probably the runtime linker does not understand weak symbols, at least on Windows (https://ghc.haskell.org/trac/ghc/ticket/3333). From the error you got, we can assume that it treats them as regular symbols, and two regular symbols are not allowed to have the same name.
As a workaround, you may be able to build your C++ files with -fno-weak as described in https://stackoverflow.com/a/26454930/190376.
If that doesn't work, an alternative is to build your C++ files into a DLL, which you can have GHCi load using the system dynamic loader, avoiding this whole issue. On Linux this would look like
g++ wrapper.cpp clipper.cpp -shared -fPIC -o libclipper.so
ghci -L. -lclipper
though I imagine the details are different on Windows.
The specific error isn't what I'm used to seeing, but those backslashes say you're on Windows, and this otherwise looks like GHC bug #3242 which has been causing pain for years now. Good news: the cause was finally isolated two weeks ago. Bad news: the fix didn't make the deadline for 7.10.3, though at least the 8.0.1 milestone seems secure at this point.
Probably still worth posting your error text to that bug's thread; mine is only an educated guess, someone there will know for sure.

Unable to run Woden Physics Example in Pharo

I am trying to run the Woden Physics Example inside Pharo which involves getting Bullet properly compiled and the smalltalk bindings properly installed in Pharo.
I am using Linux Mint 17 x64.
But NativeBoost seems unable to load the compiled libraries. I have been using the sources provided here:
https://github.com/ronsaldo/bullet-pharo
https://github.com/ronsaldo/swig
I built the modified version of swig as well as the bullet libraries and bindings with the provided build scripts.
I also have doublechecked that the bullet libraries are 32 bit.
Opening up the Woden physics example returns this error:
failed to get a symbol address:
PharoNB_new_BTDefaultCollisionConfiguration__SWIG_1
When examining the call stack in the debugger, it turns out that the module handle is 0.
I verified this by executing the same message as
BulletCInterface nbLibraryNameOrHandle
executes:
NativeBoost forCurrentPlatform loadModule: 'BulletPharo'
This message returns 0. I tried to specify the full path to libPharoBullet.so in the workspace, like:
NativeBoost forCurrentPlatform loadModule:
'/home/martin/.local/share/Pharo/bullet-pharo/libBulletPharo.so'
with the same result. I also verified it with a 32 bit system library of mine (liblzma) and there NativeBoost was able to load it, as it returned a non-zero handle.
So i suspect something during compilation went wrong...
I also did
readelf -h libPharoBullet.so
and its ABI was "UNIX - GNU" while the ABI of pharo-vm is "UNIX - System V"
Could this be the problem here ?
How can i force the ABI to be System V when compiling ? I use gcc 4.8.2
Or what steps could i otherwise perform ?

No such file or directory "ruby/config.h" when trying to compile C++ into Ruby using SWIG

I'm trying to get a basic example running using SWIG to convert a C++ file into Ruby. I have Ruby 2.0.0p451 (64 bit version) installed and I've also installed the 64-bit DevKit. I'm running Windows 7 and trying to use swigwin-2.0.12. Finally, I am using the GCC C++ compiler supplied by Mingw-builds for the 64-bit version of Windows.
I have the basic C++ hello world program as shown below.
#include <iostream>
#include <cstdlib>
using namespace std;
main()
{
cout << "Hello World!";
system("pause");
return 0;
}
At the command prompt, I use the command:
swig -module -c++ -ruby hello_world.cpp
This completes fine and produces a file titled hello_world_wrap.cxx. However, when I receive an error when I try to compile the .cxx file using the command:
g++ -fPIC -c hello_world_wrap.cxx -IC:\Ruby200-x64\include\ruby-2.0.0
The error I am receiving is:
All the research I've done has pointed me to an installation of the incorrect DevKit, but I don't think this is my issue. I've made sure to download the 64-bit version of Ruby and the DevKit. I've checked the folder specified in the error, and there is no config.h file. I'm not sure why the config.h file does not exist or why ruby.h is trying to load it.
Any thoughts?
Check that C:\Ruby200-x64\include\ruby-2.0.0\ruby\config.h exists. If not, find it and fix the path.
Update:
Check if there is a ruby.h in the same folder. If there is then just use -IC:\Ruby200-x64\include\ruby-2.0.0\ruby\x64-mingw instead. Otherwise try adding a second -I, for this extra path. I agree with you this is a little strange (not so much the former, but definitely if you have to have two -I). The script at https://groups.google.com/forum/m/#!topic/comp.lang.ruby/RpjuvXpFI30 suggests that this might be normal, I.e. you need one -I for platform-independent headers and one for platform-dependent.

What is a 'shebang' line?

Currently I'm trying to start programming on my new Mac. I installed TextWrangler, and chose C++ as my language of choice; since I have some prior knowledge of it, from when I used Windows.
So, I wrote the ever so common "Hello World" program. Although, when I tried to run it, I got an error:
"This file doesn’t appear to contain a valid ‘shebang’ line (application error code: 13304)"
I tried searching the error code to find out how to fix this, but I couldn't find anything.. I have no idea what a 'shebang' line is... Can someone help me out?
You need to compile it with a compiler first. I assume you tried to run the source file like ./source but C++ doesn't work this way.
With some compilers however, you can provide a shebang-line as the first line of the source file (the #! is known as shebang or crunchbang, hence the name), like so:
#!/path/to/compiler
So that the shell knows what application is used to run that sort of file, and when you attempt to run the source file by itself, the compiler will compile and run it for you. That's a compiler-dependent feature though, so I recommend just plain compiling with G++ or whatever Macs use to get an executable, then run that.
While I wouldn't recommend it for regular C++ development, I'm using a simple shell script wrapper for small C++ utilities. Here is a Hello World example:
#if 0 // -- build and run wrapper script for C++ ------------------------------
TMP=$(mktemp -d)
c++ -o ${TMP}/a.out ${0} && ${TMP}/a.out ${#:1} ; RV=${?}
rm -rf ${TMP}
exit ${RV}
#endif // ----------------------------------------------------------------------
#include <iostream>
int main(int argc, char *argv[])
{
std::cout << "Hello world" << std::endl;
return 0;
}
It does appear that you are trying to run the source file directly, however you will need to compile using a C++ compiler, such as that included in the gcc (GNU Compiler Collection) which contains the C++ compiler g++ for the Mac. It is not included with the Mac, you have to download it first:
from http://www.tech-recipes.com/rx/726/mac-os-x-install-gcc-compiler/ : "To install the gcc compiler, download the xcode package from http://connect.apple.com/. You’ll need to register for an Apple Developer Connection account. Once you’ve registered, login and click Download Software and then Developer Tools. Find the Download link next to Xcode Tools (version) – CD Image and click it!"
Once it's installed, if you are going for a quick Hello World, then, from a terminal window in the directory of your source file, you can execute the command g++ HelloWorld.cpp -o HelloWorld. Then you should be able to run it as ./HelloWorld.
Also, if you're coming from a Visual Studio world, you might want to give Mono and MonoDevelop a try. Mono is a free implementation of C# (and other languages), and MonoDevelop is an IDE which is very similar to Visual Studio. MonoDevelop supports C# and other .NET languages, including Visual Basic .NET, as well as C/C++ development. I have not used it extensively, but it does seem to be very similar to VS, so you won't have to learn new everything all in a day. I also have used KDevelop, which I liked a lot while I was using it, although that's been a while now. It has a lot of support for GNU-style development in C/C++, and was very powerful as I recall.
Good luck with your endeavors!
Links:
Mono: http://mono-project.com/Main_Page
MonoDevelop: http://monodevelop.com/
KDevelop: http://kdevelop.org/
shebang is http://en.wikipedia.org/wiki/Shebang_%28Unix%29.
not sure why your program is not running. you will need to compile and link to make an executable.
What I find confusing (/interesting) is C++ program giving "Shebang line" error. Shebang line is a way for the Unix like operating system to specify which program should be used to interpret the rest of the file. The shebang line usually points to the path of the interpreter. C++ is a compiled language and does not have interpreter for it.
To get the real technical details of how shebang lines work, do a man execve and get that man page online here - man execve.
If you're on a mac then doing something like this on the commandline:
g++ -o program program.cpp
Will compile and link your program into an executable called program. Then you can run it like:
./program
The reason you got the 'shebang' error is probably because you tried to run the cpp file like:
./program.cpp
And the shell tries to find an interpreter to run the code in the file. Because this is C++ there is no relevant interpreter but if your file contains Python or Bash then having a line like this
#!/usr/bin/python
at the 1st line in your source file will tell the shell to use the python interpreter
The lines that start with a pattern like this: #!/.../.../.. is called a shebang line. In other words, a shebang is the character sequence consisting of the characters number sign and exclamation mark (#!).In Unix-like operating systems, when a text file with a shebang is used as if it is an executable, the program loader mechanism parses the rest of the file's initial line as an interpreter directive. The loader executes the specified interpreter program, passing to it as an argument the path that was initially used when attempting to run the script, so that the program may use the file as input data.

Profiling C++ with Google Perf tools and Dynamic Libraries

I'm trying to profile a C++ application, that I did not write, to get a sense for where the major computation points are. I'm not a C++ expert and even less so C++ debugging/profiling expert. I believe I am running into a (common?) problem with dynamic libraries.
I compile link to Google CPU Profiler using (OS X, G++):
env LIBS=-lprofiler ./configure
make
make install
I then run profile the installed application (jags) with:
env CPUPROFILE=./jags.prof /usr/local/bin/jags regression.cmd
pprof /usr/local/bin/jags jags.prof
Unfortunately, I get the error:
pprof /usr/local/bin/jags jags.prof Can't exec "objdump":
No such file or directory at /usr/local/bin/pprof line 2833.
objdump /System/Library/Frameworks/Accelerate.framework/Versions/A/
Frameworks/vecLib.framework/Versions/A/libLAPACK.dylib: No such file or directory
The program dynamically links to libLAPACK.dylib. So prof does not seem to understand it (?). I thought about trying to statically link, but the documents associated with the program say that it is impossible to statically link in LAPACK or BLAS (two required libraries).
Is there a way to have the profiler ignore libLAPACK? I'm okay if it doesn't sample within libLAPACK. Or how might I get profiling to work?
This error was caused by jags being a shell script, that subsequently called profilable code.
pprof /usr/local/bin/REAL_EXEC jags.prof
fixes the problem.
I don't see a clean way to do it, but maybe there's a hacky workaround -- what happens if you hack the pprof perl script (or better a copy thereof;-), line 2834, so that instead of calling error it emits the message and then does return undef;?
If you're profiling on OSX, the Shark tool is really great as well. It's very simple to use, and has worked out of the box for me when I've tried it.