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.
Related
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'm currently using Qt Creator 4.4.1 with Qt 5.9.2 and the MSVC 2015 32/64 Bit compilers to create a DLL on Windows 7.
In Qt Creator under
Projects -> Build & Run -> Desktop Qt 5.9.2 MSVC2015 xxbit -> Run -> Executable
I've specified the host application, that loads my DLL, so when I hit F5 this app gets executed and loads my DLL without a flaw.
However, on loading, the main app raises an exception which I have no hands-on, making Qt Creator showing up a message box with the following content:
The inferior stopped because it triggered an exception.
Stopped in thread 0 by: Exception at 0x60251637, code 0xc0000005: write access violation at: 0x1, flags=0x0 (first chance).
I now have to close the message box and hit F5 again to proceed.
Because I have to do this for every test run, again and again, it becomes really annoying. So, is there a simplest way to tell CDB from Qt Creator to ignore only that specific type of exception?
Look at the call stack, find the relevant code and see what it does. You should find a try ... catch ... around that line. See whether you can avoid the exception in some way, typically by introducing an if ... else ....
If you cannot avoid it, and you made sure it's really safe to ignore it, start CDB with command line argument -c "sxn c0000005" or the equivalent -c "sxn av", where AV is short for "access violation". You can use sx to see all exception settings.
I encountered the same problem, the problem may be caused by the variable is not initialized, for example:
QLable *lable;
If you forget to allocate memory for this variable, it will cause this error.
lable = new QLable(this);
I think you should check your variables.
I have an application that uses Qt, it works on some machines (Windows 7 64bits, Windows Server Standard 32bits), and on other machines (Windows Server 2012 R2 64bits, Windows 10 Pro 64bits) it gives an SEH exception. I've been trying to debug this for some time but I don't know how to find the root.
This exception is not caught by the try/catch, and I wasn't able to use __try/__except because it cannot be used together with the first, and also it says it can only be used in code that does not require unwinding (if I remember correctly).
Problem signature:
Problem Event Name: APPCRASH
Application Name: gpeh_parser.exe
Application Version: 0.0.0.0
Application Timestamp: 584051a0
Fault Module Name: Qt5Core.dll
Fault Module Version: 5.1.1.0
Fault Module Timestamp: 521a52ae
Exception Code: c0000005
Exception Offset: 00023087
OS Version: 6.3.9600.2.0.0.272.7
Locale ID: 11274
Additional Information 1: 5861
Additional Information 2: 5861822e1919d7c014bbb064c64908b2
Additional Information 3: 01d7
Additional Information 4: 01d7340064827245f2249cd1f1a7c264
I also tried to use windbg, but wasn't able to find the root of the problem (altough that might be due to my very little experience with it).
What else can I do to find what's happening?
I've found that enabling /EHa (Structured Exception Handling) on the compiler solves my problem, as I can then use my default exception handling code (try/catch).
Appending this to my .pro did it:
win* {
QMAKE_CXXFLAGS_EXCEPTIONS_ON = /EHa
QMAKE_CXXFLAGS_STL_ON = /EHa
}
I'm trying to build a game in sfml under windows 10.It shows successful at the time of building.whenever i debug the solution it shows the error message like:
Unhandled exception at 0x00007FFA622C21F9 (sfml-system-2.dll) in picpuz2.exe: 0xC0000005: Access violation reading location 0x0000000000000019.
Under call stack the program stopped at the code:
window.create(sf::VideoMode(300, 300, 32), "PICPUZ");
This is my code:
Please follow the tutorials closely. If you are doing a debug build, you should link with the dlls that end in -d for debug.
For example sfml-system-d-2.dll
Linking release and/or debug to the wrong configuration (release to debug or debug to release) will result in unpredictable crashes.
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).