Initially, I wanted to install the updated MinGW packages using the MinGW-get GUI, but it crashes when I choose "Mark All Upgrades" from the 'Installation' drop-down menu (whether I update the catalogue or not).
Now, I want to figure out why guimain.exe is crashing.
How can I diagnose and debug this persistent problem? I am vaguely familiar with GDB, but I've never used it. I am not committed to using the Visual Studio debugger.
I assume I need to use some ancillary binaries or debug libraries in the latest MinGW installer branch here: https://sourceforge.net/projects/mingw/files/Installer/mingw-get/mingw-get-0.6.2-beta-20131004-1/
Can anyone please guide me? Any assistance or suggested reading is appreciated.
For those who are experiencing the crash on attempting to upgrade packages.. try running it in recursive mode..
mingw-get upgrade --recursive
that appeared to force an upgrade for me..
I happen to have the same issue. The GDB way to debug this:
gdb mingw-get.exe
r upgrade (run with argument upgrade)
GDB will automatically stop at a SIGSEGV (Segmentation fault) signal, that's what happens for me.
bt (get a backtrace)
For me this resulted in a huge backtrace, filled with calls to:
#5013 0x6f9cdda4 in mingw-get-0!_ZN14pkgXmlDocument19ResolveDependenciesEP10pkgXmlNodeP13pkgActionItem () from c:\MinGW\libexec\mingw-get\mingw-get-0.dll
It looks like a recursion problem that quickly filled up the call stack.
Note that function name is mangled, and we don't know the line number. This is the best you can do without debugging symbols. If you have the debugging symbols, GDBs output becomes more useful. For most Linux-style packages, you can get the debugging symbols in a -dbg package named similiarly to the stripped binary package. However I don't see a debug package for mingw32-mingw-get in the listing.
Related
I have an executable that makes use of /usr/lib/libcrypto.0.9.8.dylib. I've (more or less) figured out some breakpoints within that library that I'd like to understand better.
However, I do not remember if this is the stock openssl on the system, or if I later installed it (don't think so, pretty sure that homebrew would have put it elsewhere).
This is for macOS Mojave (10.14). If the debug symbols have been stripped in libcrypto, I'm not sure I even know how to check that (nm?). I have, however, downloaded and extracted the source (matching the version).
Is there any way to configure lldb such that it can show me the source code instead of assembly language? If the debugging symbols have been stripped (without even checking, I'd assume so) can you even do this?
I'm trying to do my own research for this, but I'm not even sure I know what keywords to search with yet.
The tools on Darwin don't store debug information in the binaries, but rather in a separate standalone bundle (a dSYM). So if you don't have a dSYM for your libcrypto then you don't have debug information for it, and there's no way to reconstruct the code->source map.
Some distributions have debug packages as well as release ones that include the dSYM's. lldb matches dSYM to binary using a common UUID computed by the linker. You can print the UUID with the command dwarfdump --uuid <PATH TO BINARY> and then see if wherever you got the library from kept that dSYM.
But if you can't find the dSYM, you aren't going to be able to do any source level debugging.
I setup a breakpoint in my Go code with runtime.Breakpoint(), save the file (my editor, Atom with go-plus installed, runs go install . on save). Then I run Delve in terminal with dlv debug, and type continue after it starts.
When the breakpoint kicks in, I want to test a couple of things (basically to print reader's data via a bytes.Buffer). But, I get the following error
buf := new(bytes.Buffer): "1:5: expected 'EOF', found ':='"
and in general cannot do much more than print values.
Is it really not possible to do this sort of thing? I am used to Python's pdb where setting variables or calling functions is not a problem and I would expect Delve is capable of the same.
So, what am I doing wrong?
Not possible yet. Right now (2018-NOV) work is in progress on Delve, but unfinished.
Go runtime was changed recently to allow this kind of call. Delve have a Github issue tracking the progress of such feature, but is still experimental and incomplete.
I am using VS2010.I was changed my project and its dependent projects .Net Framework to 4.0 from 3.5.Now I could not attach the process,due to this I am not able to debug the code.
I have cleaned all the bin folders and rebuild the projects ,but still I am having following error.
Please help me to resolve this..
I'm not sure what the question is here. The error message clearly tells you that you need to
Turn off (disable) optimizations
Turn on (enable) debug info
Rebuild your project so those changes take effect.
Apparently you only did step #3.
Also see vs2010 debugging module was built without debugging information?, which may provide more information.
I also received this error, and did all the right things as described above - those have been my settings all along anyway. I even went so far as deleting the assembly from the long C:\Users... path in the error message - it still didn't cause that message to go away.
Then I tried putting a breakpoint in the source, which should not be allowed if the module really WAS built without debug information. And then ran the program and it stopped at the break point and I could do all the usual debugging.
So right now I'm just ignoring the message. I could do as suggested and disable the 'Warn if no user code on launch' option as suggested in the message, but I'm not doing that until I can spend some time working out why the message comes up at all.
Uncheck this option in Visual Studio 2012.This would solve this issue
Ok, I went through great lengths but I finally got my integration to quickbooks working on my VB6 application. It works perfectly on my build machine. I actually installed the qbdsk11 on my build machine and worte and tested the code. The ONLY new reference in the project is the QBFC11.dll.
So, I added the QBFC11.dll to my innosetup, told it to do a regsvr on the dll, and hoped this was enough.
NOT.
First, during install, I get a failure to register the dll. Apparently, this DLL isnt meant to be registered?
But the .DLL was put in Windows System32, so I tried my program anyways...
NOPE. Doesnt work. I get a runtime 91, about an object variable not set. Which makes sense, if it cant create the object.
So, for grins, I moved a copy of the .DLL into the program folder, next to my executable.
Same thing. Runtime error 91.
So, i then grab the whole qbsdk11 installer and install it on this machine. I figure I can make it an additional download for people who want to use this extra functionality.
But no, even with the whole SDK installed, I still get the same runtime error.
I have not been able to find any CLEAR information on how to proceed. I'd prefer for this to be part of my base install. But apparently something still just isn't right.
What did I miss? How do I fix this? I don't even know what to try next.
If you're using QBFC11, you must install the QBFC11 redistributable components with your application. You can find instructions on how to do this in the QBSDK Programmer's Guide in the section titled Redistributing SDK Components With Your Application, subsection Using Installers and Merge Modules.
The most likely cause of the runtime error you're currently getting is the manipulation of the QBFC11.DLL that you did before you installed the SDK. I would start again with a clean OS image so that you can get the proper procedure down.
I use ndk-build to compile libpng source code in debug mode, then it shows “internal compiler error” in pngrtran.c. But when I compile in release mode, it can success. Is this a bug in libpng? How I can resolve this?
It's not a bug in libpng; anything a program describes as an "internal error" is a bug in the program (libpng does this, but then it shows "libpng: internal error"!) So it's a bug in the compiler.
You should report it to the ndk guys or you could go directly to the compiler vendor (probably GNU) because they would likely to be more responsive.
You can't resolve the problem - it needs a compiler fix (maybe only to output a message that doesn't claim it's an internal error, but at least that.) You can avoid the problem by simply not compiling libpng in debug mode. Since I assume this is for Android so you can (I believe) mix-and-match debug and now debug code (this does NOT work on Windows with at least one compiler!)
You can also try working out which compiler option reveals the problem; compare the options being passed to the compiler in both release and debug, then bisect the differences to see if you can narrow the issue down to one setting.
John Bowler jbowler 2 acm.org
The android team should know about the bug. As Its a resurface of an old one:
http://code.google.com/p/android/issues/detail?id=20862