I am working with GTKmm 3, MSYS2, MinGW (GCC 5.3.1) under Windows 7.
I made a Glade interface with a normal window and a Gtk::AboutDialog.
All is working OK, but when opening the About dialog and clicking on its URL link, then the next error occours and the program exits:
(GladeTest1.exe:3440): GLib-CRITICAL **: unquote_string_inplace: assertion 'err == NULL || *err == NULL' failed
This is the code:
Gtk::Window *window1;
Gtk::AboutDialog *aboutDialog1;
builder->get_widget("window1", window1);
builder->get_widget("aboutdialog1", aboutDialog1);
aboutDialog1->set_transient_for(*window1);
aboutDialog1->show();
Using Dr. Mingw debugger I got this traces:
GladeTest1.exe caused an Access Violation at location 000000000070255A in module libgtk-3-0.dll Reading from location 0000000000000008.
Loading symbols... done.
Registers:
eax=00000000 ebx=03d5c1a8 ecx=00000000 edx=00000001 esi=024d8020 edi=00000016
eip=0070255a esp=0028ea9c ebp=0028eb54 iopl=0 nv up ei pl nz ac po nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00210216
AddrPC Params
0070255A 02514D30 03B36FA0 0250FB00 libgtk-3-0.dll!gtk_search_entry_handle_event
0082845C 0257C900 0028EC84 00000002 libgtk-3-0.dll!gtk_main_do_event
63C45FD2 0028ED9C 0028ED00 0028EDBC libgobject-2.0-0.dll!g_closure_invoke
63C5F31A 025025A8 025297B0 00000000 libgobject-2.0-0.dll!g_signal_emit_valist
6883689B 025297B0 00000000 02514D30 libglib-2.0-0.dll!g_mutex_unlock
025025A8 00000000 02514D30 00000000
025297B0 02514D30 00000000 00000000
It seems like there is some problem with libgtk-3-0.dll or libglib DLL.
I am looking for an answer for 2 days without success.
Something important is missing?
Anybody has a clue?
Thanks
We had the same errors/crashes under WinXP64 and Win7/G4 with MSys2/MingW 6.2.0 using Gtk+ ( i.e. Gtk2).
However, when we compiled/build our own Gtk/Gdk libs via MingW, exactly the same Gtk_About dialog's Http link worked.
... this seems to point the finger at something in the MSys2 build. Indeed, when trying to build Gtk following the MSys2 "pkg build directions" also fails (at least for us).
... we haven't had too much "luck" communicating with the MSys2 people.
... Instead, we use the so-called "Ingar Build" approach found here (http://ingar.satgnu.net/devenv/mingw32/gtk.html). His instructions are for the entire build from the ground up, which is a few day's work, but it is very much worth it for us ... and provides massively more control and flexibility compared to MSys2.
P.S. You will need to make a few adjustments to Ingar's instructions for Gtk3. Also, if you build the packages with versions much later/newer compared to those on Ingar's site, additional packages will be required (due to the additional dependencies in newer versions).
Related
For some program LDSTORE I need to install llvm on my Mac (macOS 10.13). I do this using brew install llvm. This leads to a Segmentation fault: 11 message when running ldstore, or other (C++ based?) programs.
How can I fix this?
It clearly has to do with llvm, as doing brew uninstall llvm fixes the issue (obvious ldstore won't work in that case).
For what it's worth: I use the native python 2.7.10.
As per suggestion of Stanislav Pankevich I ran lldb ldstore_v11 followed by r, resulting in this:
lldb ldstore_v11
(lldb) target create "ldstore_v11"
Current executable set to 'ldstore_v11' (x86_64).
(lldb) r
Process 15841 launched: '/Users/swvanderlaan/bin/ldstore_v11' (x86_64)
dyld: Library not loaded: /usr/local/opt/libiomp/lib/libiomp5.dylib
Referenced from: /Users/swvanderlaan/bin/ldstore_v11
Reason: image not found
Process 15841 stopped
* thread #1, stop reason = signal SIGABRT
frame #0: 0x0000000100095216 dyld`__abort_with_payload + 10
dyld`__abort_with_payload:
-> 0x100095216 <+10>: jae 0x100095220 ; <+20>
0x100095218 <+12>: movq %rax, %rdi
0x10009521b <+15>: jmp 0x100094a74 ; cerror_nocancel
0x100095220 <+20>: retq
Target 0: (ldstore_v11) stopped.
It's odd that the library is not found, as I clearly added to my bash_profile the following line: export PATH="/usr/local/opt/llvm/bin:$PATH", as per suggestion of the installation messages.
Hope someone can help me debug this.
Thanks,
Sander
P.S. I hope it's clear, I'm not trying to develop anything, I'm just trying to use LDSTORE.
The problem is that this tool is dynamically linked against libiomp5.dylib, which must be present at /usr/local/opt/libiomp/lib/libiomp5.dylib for it to work.
As suggested by Stanislav, download the precompiled binaries from http://releases.llvm.org/5.0.0/clang+llvm-5.0.0-x86_64-apple-darwin.tar.xz. This contains the library you need: ./lib/libiomp5.dylib. You'll have to copy the library into /usr/local/opt/libiomp/lib, which probably won't exist yet.
Once you've done that, you'll be able to run ldstore.
I got the error when I tried to analyze my Dump Crash File using WinDbg. I corrected my source path and symbol path when I analyzed this issue. I don't know what is the error and why this error happens.
ExceptionAddress: 773e774d (ntdll!_LdrpInitialize+0x00059ba1)
ExceptionCode: c0000135
ExceptionFlags: 00000001
NumberParameters: 0
PROCESS_NAME: asckc.exe
EXCEPTION_CODE: (NTSTATUS) 0xc0000135 - The program can't start because %hs is missing from your computer. Try reinstalling the program to fix this problem.
NTGLOBALFLAG: 0
BUGCHECK_STR: LOADER_INIT_FAILURE_STATUS_DLL_NOT_FOUND
DEFAULT_BUCKET_ID: LOADER_INIT_FAILURE_STATUS_DLL_NOT_FOUND
STACK_TEXT:
00000000 00000000 asckc.exe!Unknown+0x0
STACK_COMMAND: dt ntdll!LdrpLastDllInitializer BaseDllName ; dt ntdll!LdrpFailureData ; ** Pseudo Context ** ; kb
BUCKET_ID: LOADER_INIT_FAILURE_STATUS_DLL_NOT_FOUND_asckc.exe!Unknown
PRIMARY_PROBLEM_CLASS: LOADER_INIT_FAILURE_STATUS_DLL_NOT_FOUND_asckc.exe!Unknown
FAILURE_PROBLEM_CLASS: LOADER_INIT_FAILURE_STATUS_DLL_NOT_FOUND
FAILURE_EXCEPTION_CODE: c0000135
FAILURE_BUCKET_ID: LOADER_INIT_FAILURE_STATUS_DLL_NOT_FOUND_c0000135_asckc.exe!Unknown
ANALYSIS_SOURCE: UM
FAILURE_ID_HASH_STRING: um:loader_init_failure_status_dll_not_found_c0000135_asckc.exe!unknown
Could you please help me ?
This error is telling you that there is a DLL that your program (or a DLL loaded by your program) needs to run, but Windows is unable to load it. This can be because something isn't installed right, or you haven't copied all of the DLLs your program needs into the folder you are running from. The error isn't listing the problem DLL so I can't help you any more than that.
You can look for a program called DEPENDS (by Microsoft) that can help track down these sorts of problems.
I have compiled a test dll for use with jni. It is actually completely empty except for #include<jni.h>. It compiles fine. I commented out everything else to try and get it working. I used gcc cygwin version and -shared and eclipse.
This is the class that loads the library:
static
{
final File f= new File(new File("res"), "mandc.dll");
System.out.println(f.exists());
System.load(f.getAbsolutePath());
System.out.println("Loaded!");
}
// public static native long mand(final double cx, final double cy,
// final double jx, final double jy, long iter);
public static native void mand();
true is the last thing that prints, proving that the error is between true and loaded!.
If I run from within eclipse, two error messages print, but the internet does not know what they are.
the messages:
2 [main] javaw <random number here> exception::handle: Exception: STATUS_STACK_OVERFLOW
667 [main] javaw <random number here> open_stackdumpfile: Dumping stack trace to javaw.exe.stackdump
the stack dump is uninformative.
Exception: STATUS_STACK_OVERFLOW at eip=61157C62
eax=0001C038 ebx=49E0834C ecx=49DE2ABC edx=49E27DB4 esi=49E07B2C edi=49E27B34
ebp=49E07ACC esp=49E07AB4 program=C:\Program Files\Java\jre7\bin\javaw.exe, pid 2688, thread main
cs=001B ds=0023 es=0023 fs=003B gs=0000 ss=0023
Stack trace:
Frame Function Args
49E07ACC 61157C62 (49E2D000, 49E27B3A, 49E27DB4, 00000008)
49E07AFC 6106C0B5 (49E27B3A, 49E27D78, 00000008, 49E27B2C)
49E27B4C 6106C6D1 (49E27B70, 00000C90, 00000000, 49E27DB4)
49E27DEC 6100584E (49E27EBC, 611FBAF0, 611FBAEC, 49E27E2C)
49E27E3C 61005D28 (49E27FC3, 611FBAF0, 611FBAEC, 00000001)
49E2801C 61006F07 (00000000, 49E28058, 61006990, 49E2B268)
End of stack trace
The experiment also fails when I run the example from the wikipedia page. And it fails the same way.
Problem fixed. I switched toolchains from the cygwin gcc to the mingw gcc. To support this, I had to install extra mingw packages from the cygwin install program.
I guess that cygwin is incompatible with java. A better error message would have been appreciated.
I developed a tiny MFC application that is going to run on the server 24 hours.
(Windows Server 2008 R2, x64)
I made the app crash on purpose to see if its minidump file is properly created and working, and it works with WinDbg.
Here how I did.
0:000> .symfix c:\symbols
0:000> .sympath+ C:\Projects\*********\x64\Release
0:000> .reload
0:000> !analyze -v
-> Works! I can see full call stack and the line where the error occured!
But, when I do the same thing on my local laptop(Windows XP, x86)
All I can see in call stack text is very basic information as below.
(It doesn't either show what line I should take a look at to debug.)
STACK_TEXT:
0012fd60 0040695c 00000004 dd0fbe7e 00d67d10 **************!CWnd::RunModalLoop+0xf7
0012fdac 004010e0 dd0fbcce 0056bae8 0056bae8 **************!CDialog::DoModal+0x130
0012ff1c 0050e492 00380032 00000000 7ffde000 **************!**************::InitInstance+0xa0
0012ff30 004f7bd7 00400000 00000000 00020934 **************!AfxWinMain+0x48
0012ffc0 7c7e7077 00380032 002d0033 7ffde000 **************!__tmainCRTStartup+0x11a
0012fff0 00000000 004f7c2a 00000000 00000000 kernel32!BaseProcessStart+0x23
-> Meaningless information in this case b/c the error occurs in OnBnClicked function.
I spent several hours googling, but feel lost looking for the answer to this.
Why doesn't it work ONLY on my laptop pc?
What should I check? What am I missing? Any idea would be very appreciated.
Thanks in advance.
You will need the same pdbs without private symbols removed accessible from your laptop in order to get sensible call stacks with correct source line information, also I notice you seem to have cached some symbols to c:\symbols are these the same and also resolve the windows symbols?
Check your visual c++ settings to make sure that you are not stripping private symbols from the pdbs, it will most likely warn you when you try to set breakpoints, search symbols or perform a crash analysis by stating that it was unable to verify the checksum or similar message.
I also notice you are running your app on a 64 bit server and then on a 32 bit laptop, are you running the correct version of WinDbg is my next question, there are 32 and 64 bit versions.
Also what version of windbg are you using? There are often bugs with various versions so you may want to check you are running the same version on your laptop as on your server.
I've got a kind of curious problem here, and to be quite honest I have no idea what's causing it. For whatever reason, when I debug my application from Qt Creator my application runs just fine without any exceptions, but when I only run the application, I get a write access violation exception (as follows)
(1f68.1ea8): Access violation - code c0000005 (first chance)
Exception at 0x77da2073, code: 0xc0000005: write access violation at: 0x1, flags=0x0 in ntdll!RtlpLowFragHeapFree
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=00720065 ebx=82130074 ecx=006f007f edx=0000006f esi=01fa5fb6 edi=82130000 eip=77da2073 esp=0012cc70 ebp=0012cca4 iopl=0 nv up ei pl nz na po nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010202
ntdll!RtlpLowFragHeapFree+0xc5:
77da2073 8930 mov dword ptr [eax],esi ds:0023:00720065=????????
Exception at 0x77da2073, code: 0xc0000005: write access violation at:
0x1, flags=0x0
NOTE: INFERIOR SPONTANEOUS STOP
State changed from InferiorRunOk(11) to InferiorStopOk(14).
When I comment out the line it breaks at (after running, then manually attaching the debugger) it just seems to bring me to a different line for the same issue. The tool chain I'm using is MSVCC, with the additional flags:
QMAKE_CFLAGS_RELEASE += -Zi
QMAKE_CXXFLAGS_RELEASE += -Zi -g
QMAKE_LFLAGS_RELEASE += /DEBUG /OPT:REF
To recount, here's what I've tried:
Debugging with debug configuration - ok
Running with debug configuration - ok
Debugging with release configuration - ok
Running with release configuration - exception
Are you double freeing something? A quick search brings up this article about double freeing.
I'm not sure what the MSVCC equivalent might be (the article mentions a tool called gflags.exe), but under Linux with GCC you can use a program called Valgrind with the memcheck tool to find this sort of problem.