I am using Visual studio 2013 always encountered a break point when compiling my code in debug mode.
Before this post I gone through this and this.
I went through [DEBUG-> Windows-> Breakpoints] there is no break point available to delete any.
Below screenshot for how my exe triggering breakpoint at time of compilation. Yes, my project contains numerous libraries and this break point triggering only to library files. Could anyone help me to fix it, i googled a lot but can't?
Here is my Call stack copy:
ntdll.dll!770cfe2c() Unknown
[Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]
[External Code]
DemoProj.exe!CryptoPP::MessageQueue::TransferTo2(CryptoPP::BufferedTransformation & target, unsigned __int64 & transferBytes, const std::basic_string<char,std::char_traits<char>,std::allocator<char> > & channel, bool blocking) Line 27 C++
DemoProj.exe!CryptoPP::BufferedTransformation::Get(unsigned char * outString, unsigned int getMax) Line 420 C++
When i debugging my code getting a error i.g "UMEngx86.dll'. Cannot find or open the PDB file."
'DemoProj.exe' (Win32): Loaded 'C:\Windows\SysWOW64\KernelBase.dll'. Symbols loaded.
'DemoProj.exe' (Win32): Loaded 'C:\Windows\SysWOW64\sysfer.dll'. Cannot find or open the PDB file.
'DemoProj.exe' (Win32): Loaded 'C:\ProgramData\Symantec\Symantec Endpoint Protection\12.1.4112.4156.105\Data\Definitions\BASHDefs\20160125.011\UMEngx86.dll'. Cannot find or open the PDB file.
'DemoProj.exe' (Win32): Loaded 'C:\~…\release\log4cplus.dll'. Module was built without symbols.
I also read this document about this issue. Still need help from export.
Finally, i able to solve my won problem.
What was the problem?
A: It was a heap memory corruption, so Heap manager thrown a exception by triggering a automatic break point.
Where you did mistake?
Ans: I am explaining my mistake with simple example;
#include "stdafx.h"
#include <iostream>
using namespace std;
int _tmain(int argc, _TCHAR* argv[])
{
char *buffer = "Simple Heap Error Demo";
int len = strlen(buffer);
char *plaintext = new char[len]; //Here i mistaken
/*It should be char *plaintext = new char[len + 1]; because i need one more memory cell for NULL character, that i forgotten and later i am trying to delete [] palintext. */
memcpy(plaintext, buffer, len);
plaintext[len] = '\0';
cout << "\nplaintext: " << plaintext;
if (plaintext != NULL);
delete[] plaintext; //Exception thrown here
system("pause");
//cout << "\nplaintext: " << plaintext;
return 0;
}
How you solved your problem?
Ans: First i neatly debug my project using WinDbg found where exactly heap corruption exception happening. Then i wrote a simple separate program related to same scenario and able to fix my problem.
A special thanks to Steve who helped me to resolve my issue.
Related
I have a piece of code in C++ that lists files in a folder and then gets attributes for each of them through Windows API. I am puzzled by the performance of this code when the folder is an SMB mount on a remote server (mounted as a disk).
#include <string>
#include <iostream>
#include <windows.h>
#include <vector>
//#include <chrono>
//#include <thread>
int main(int argc, char *argv[]) {
WIN32_FIND_DATA ffd;
HANDLE hFile;
std::string pathStr = argv[1];
std::vector<std::string> paths;
hFile = FindFirstFile((pathStr + "\\*").c_str(), &ffd);
if (hFile == INVALID_HANDLE_VALUE) {
std::cout << "FindFirstFile failed: " << GetLastError();
return 1;
} else {
do {
paths.push_back(pathStr + "\\" + ffd.cFileName);
} while (FindNextFile(hFile, &ffd) != 0);
int error = GetLastError();
if (error != ERROR_NO_MORE_FILES) {
std::cout << "FindNextFile failed: " << error;
FindClose(hFile);
return error;
}
FindClose(hFile);
}
std::cout << paths.size() << " files listed" << std::endl;
// std::this_thread::sleep_for(std::chrono::milliseconds(30000));
for (const std::string & p : paths) {
int a = GetFileAttributes(p.c_str());
bool isDir = (a & FILE_ATTRIBUTE_DIRECTORY);
bool isHidden = (a & FILE_ATTRIBUTE_HIDDEN);
std::cout << p << ": " << (isDir ? "D" : "f") << (isHidden ? "H" : "_") << std::endl;
}
}
Namely, if I have a folder with 250 files, it passes in about 1 second. When there are 500 files, it passes in about 1 minute, and even the first files take hundreds of milliseconds each (so, 1 second is enough for ~10 files).
Experimenting with it, I found that there is some limit below which processing speed is in hundreds files per second and above which the speed is ~10 files per second. I also noticed that this number differs with file name length. With names like file-001: between 510 and 520. With names like file-file-file-file-file-001: between 370 and 380.
I am interested in why this happens, in particular why the speed degrades from the very beginning when there are "too many" files/folders in the folder. Is there a way to investigate that? Optional: is there a way to overcome that while still using GetFileAttributes?
(The code is probably ugly as hell, I just stuck it together from samples found online. I compile it with MinGW, g++ -static files.cpp -o files.exe, run it files.exe "Z:\test_folder".
My original code is in Java, and I got from reading the source of the Hotspot JVM that it uses GetFileAttributes WinAPI method, so I created this snippet to see if it would behave the same as the Java code — and it does. I am also limited in the ways to solve this performance problem: I noticed that FindFirstFile/FindNextFile WinAPI calls perform consistently fast, but I did not find a way to use it from Java without JNI/JNA which would be too much fuss for me.)
Update: if I put a 30-second sleep between listing (files collected into a vector) and getting their attributes in a loop, behavior becomes consistent with any number of files in the folder — "slow" for any number of files. I also read some scattered info here and there that Windows SMB client applies caching, limited by time etc. I guess this is what I see here: listing the folder fills this cache with file attributes, and subsequent GetFileAttributes does not hit the remote system if ran immediately after the listing. I guess the other behavior is also cache related: when listing "too many" files, only the tail of the list remains in the cache. Then we start GetFileAttributes from the first file again, and every request hits the server. Still a mystery to me why listing is so fast and GetFileAttributes is slow...
Update 2: I thought to confirm that it has something to do with the cache, but I was not lucky so far. If it had something to do with eviction of the "first" file attributes, then getting attributes in the reverse order would hit the cache for many files — not the case: it's either all fast or all slow.
I tried fiddling with SMB client parameters according to this MS article, hoping that if I set sizes really high I won't notice the slow behavior any more — was not the case either, the behavior seems to be completely independent from these parameters. What I set was:
// HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters
DirectoryCacheEntriesMax = 4096
DirectoryCacheEntrySizeMax = 32768
FileInfoCacheEntriesMax = 8192
In addition, I noticed that when there are "too many files", listing returns paths in random order (not alphabetically sorted). Not sure if it has anything to do with the problem. This behavior is even when changing listing to use FindFirstFile/FindNextFile.
In addition, I studied more carefully the timeout that is needed to "invalidate" the "cache" (so, for a folder with few files to start behaving slowly), and it is around 30 seconds in my case. Sometimes setting a lower value shows the same behavior (slow attributes getting for a folder with few files), but then re-running the program is instantaneous again.
I updated the code above, originally used std::filesystem::directory_iterator from C++17.
Background:
I am writing a app using an open source library. This open source libarary comes with many plugin dlls. Some of which we are using in our project (NOT all of them).
While in developement, we just consumed the library as a whole and everything worked fine.
Now when we are trying to build a shippable binary package, seems like we need to sort things out and find only those plugin binaries (dlls) from the open source lib which are in use.
These library comes with 100 of plugin dlls. During runtime, we just using a primary lib plugin dlls, which in turn loads up other dlls (Curently when we run the App, it loads both essential or non-essential dlls). We need to find out a way how to only pack those dlls which we are using in the code. And since these are plugins only, if the primary dll don't finds the non-essential dlls, then it is completely fine (App won't crash). We just have to help it locate the essential ones (without that pur either won't work or will crash).
Approach:
In order to find only the essential dlls, what I have done is removed all the dlls from the path and started placing one dlls each time to check, until our App start working. The problem is that with this approach it is going to take a long time. Rather than randomly picking each dlls I trying to use WinDbg to find out which missing dlls has caused the failure.
Question:
Is there a way in Windbg to identify from a dump, to see which missing dll has caused failure?
Your Question As it Appears is Ambiguous.
Most of commenters have provided you hints For a live Debugging Session Like.
Ldr Snaps
ProcMon
Etw Traces
you seem to have asked For looking at it in a dump
Question: Is there a way in Windbg to identify from a dump, to see which missing dll has caused failure?
a plugin by its nature will be allowed to fail gracefully By its Parent Binary and as such it will Create an Unload Event
This Will Be reflected in the dump by lm Command
the Unloaded Modules will be listed at the end of Module List
:\>cdb -c "lm;q" -z c:\odbgdmp.dmp |awk "/Unloaded/,/quit/"
Unloaded modules:
66940000 66957000 OllyDumpEx_Imm17.dll
quit:
ntdll maintains an array 0x40 last unloaded dlls windbg Retrieves this from the same place as the below code does.
#include <stdio.h>
#include <windows.h>
typedef struct _RTL_UNLOAD_EVENT_TRACE {
PVOID BaseAddress;SIZE_T SizeOfImage;ULONG Sequence;ULONG TimeDateStamp;
ULONG CheckSum;WCHAR ImageName[32];
} RTL_UNLOAD_EVENT_TRACE, *PRTL_UNLOAD_EVENT_TRACE;
typedef VOID (WINAPI* RtlGetUnloadEventTraceEx) (
_Out_ PULONG *ElementSize,_Out_ PULONG *ElementCount,_Out_ PVOID *EventTrace
);
RtlGetUnloadEventTraceEx evt;
int main(void) {
//ollydbg plugin wont load in curproc will create an unloaded mod event
LoadLibraryA("OllyDumpEx_Od20.dll");
HMODULE nt=LoadLibraryA("ntdll.dll");
if(nt != NULL){
evt=(RtlGetUnloadEventTraceEx)GetProcAddress(nt,
"RtlGetUnloadEventTraceEx");
PULONG elsiz = NULL, elcnt = NULL;PVOID evarr = NULL;
evt(&elsiz,&elcnt,&evarr);
printf("%p %p %p\n" , elsiz,elcnt,evarr);
printf("%x %x %x\n" , *elsiz,*elcnt,*(int*)evarr);
PRTL_UNLOAD_EVENT_TRACE u1=((PRTL_UNLOAD_EVENT_TRACE)(*(int*)evarr));
printf("bas\t%p\nsiz\t%x\nSeq\t%x\nstamp\t%x\nCsum\t%x\nname\t%S\n",
u1->BaseAddress,u1->SizeOfImage,u1->Sequence,u1->TimeDateStamp,
u1->CheckSum,u1->ImageName);
}
return 0;
}
on executing
:\>UnloadModList.exe
7706CDA0 7706CD9C 77067144
5c 40 1fafd8
base 676F0000
size 19000
Seq 0
stamp 55953f77
Chksum 12b14
imgname OllyDumpEx_Od20.dll
corroboration of dll details which failed to load
:\>dumpbin /headers OllyDumpEx_Od20.dll | grep -iE "CheckSum|Stamp|size of image|image base"
55953F77 time date stamp Thu Jul 2 19:11:11 2015
6A680000 image base (6A680000 to 6A698FFF)
19000 size of image
12B14 checksum
#include <windows.h>
long __stdcall callback(_EXCEPTION_POINTERS* excp)
{
MessageBox(0, "Error", "error", MB_OK);
return EXCEPTION_EXECUTE_HANDLER;
}
int main(int argc, char* argv[])
{
SetUnhandledExceptionFilter(callback);
int * p;
free(p); //to crash
return 0;
}
When I use SetUnhandledExceptionFilter to catch the error,it does not work.My IDE is vs 2013 , x64 system and program. I tried both debug and release ,all failed.
If it was abandoned,how I can get crash dump in the program?
In order to trigger the callback, all of the following conditions must be met:
It must be a debug build, because the invalid free() doesn't cause an exception in a release build. (It might or might not indirectly cause an exception in a larger program, but in the code as posted it does not.)
You must be running the executable without the debugger, because unhandled exception filters are ignored if a debugger is present.
You must select the "Ignore" option when presented with the Debug Error window warning you that p is being used without being initialized.
I'm not sure what it is that you're actually trying to achieve here, but this is probably not the right way to go about it.
I am totally a beginner on opencl, I searched around the internet and found some "helloworld" demos for opencl project. Usually in such sort of minimal project, there is a *.cl file contains some sort of opencl kernels and a *.c file contains the main function. Then the question is how do I compile this kind of project use a command line. I know I should use some sort of -lOpenCL flag on linux and -framework OpenCL on mac. But I have no idea to link the *.cl kernel to my main source file. Thank you for any comments or useful links.
In OpenCL, the .cl files that contain device kernel codes are usually being compiled and built at run-time. It means somewhere in your host OpenCL program, you'll have to compile and build your device program to be able to use it. This feature enables maximum portability.
Let's consider an example I collected from two books. Below is a very simple OpenCL kernel adding two numbers from two global arrays and saving them in another global array. I save this code in a file named vector_add_kernel.cl.
kernel void vecadd( global int* A, global int* B, global int* C ) {
const int idx = get_global_id(0);
C[idx] = A[idx] + B[idx];
}
Below is the host code written in C++ that exploits OpenCL C++ API. I save it in a file named ocl_vector_addition.cpp beside where I saved my .cl file.
#include <iostream>
#include <fstream>
#include <string>
#include <memory>
#include <stdlib.h>
#define __CL_ENABLE_EXCEPTIONS
#if defined(__APPLE__) || defined(__MACOSX)
#include <OpenCL/cl.cpp>
#else
#include <CL/cl.hpp>
#endif
int main( int argc, char** argv ) {
const int N_ELEMENTS=1024*1024;
unsigned int platform_id=0, device_id=0;
try{
std::unique_ptr<int[]> A(new int[N_ELEMENTS]); // Or you can use simple dynamic arrays like: int* A = new int[N_ELEMENTS];
std::unique_ptr<int[]> B(new int[N_ELEMENTS]);
std::unique_ptr<int[]> C(new int[N_ELEMENTS]);
for( int i = 0; i < N_ELEMENTS; ++i ) {
A[i] = i;
B[i] = i;
}
// Query for platforms
std::vector<cl::Platform> platforms;
cl::Platform::get(&platforms);
// Get a list of devices on this platform
std::vector<cl::Device> devices;
platforms[platform_id].getDevices(CL_DEVICE_TYPE_GPU|CL_DEVICE_TYPE_CPU, &devices); // Select the platform.
// Create a context
cl::Context context(devices);
// Create a command queue
cl::CommandQueue queue = cl::CommandQueue( context, devices[device_id] ); // Select the device.
// Create the memory buffers
cl::Buffer bufferA=cl::Buffer(context, CL_MEM_READ_ONLY, N_ELEMENTS * sizeof(int));
cl::Buffer bufferB=cl::Buffer(context, CL_MEM_READ_ONLY, N_ELEMENTS * sizeof(int));
cl::Buffer bufferC=cl::Buffer(context, CL_MEM_WRITE_ONLY, N_ELEMENTS * sizeof(int));
// Copy the input data to the input buffers using the command queue.
queue.enqueueWriteBuffer( bufferA, CL_FALSE, 0, N_ELEMENTS * sizeof(int), A.get() );
queue.enqueueWriteBuffer( bufferB, CL_FALSE, 0, N_ELEMENTS * sizeof(int), B.get() );
// Read the program source
std::ifstream sourceFile("vector_add_kernel.cl");
std::string sourceCode( std::istreambuf_iterator<char>(sourceFile), (std::istreambuf_iterator<char>()));
cl::Program::Sources source(1, std::make_pair(sourceCode.c_str(), sourceCode.length()));
// Make program from the source code
cl::Program program=cl::Program(context, source);
// Build the program for the devices
program.build(devices);
// Make kernel
cl::Kernel vecadd_kernel(program, "vecadd");
// Set the kernel arguments
vecadd_kernel.setArg( 0, bufferA );
vecadd_kernel.setArg( 1, bufferB );
vecadd_kernel.setArg( 2, bufferC );
// Execute the kernel
cl::NDRange global( N_ELEMENTS );
cl::NDRange local( 256 );
queue.enqueueNDRangeKernel( vecadd_kernel, cl::NullRange, global, local );
// Copy the output data back to the host
queue.enqueueReadBuffer( bufferC, CL_TRUE, 0, N_ELEMENTS * sizeof(int), C.get() );
// Verify the result
bool result=true;
for (int i=0; i<N_ELEMENTS; i ++)
if (C[i] !=A[i]+B[i]) {
result=false;
break;
}
if (result)
std::cout<< "Success!\n";
else
std::cout<< "Failed!\n";
}
catch(cl::Error err) {
std::cout << "Error: " << err.what() << "(" << err.err() << ")" << std::endl;
return( EXIT_FAILURE );
}
std::cout << "Done.\n";
return( EXIT_SUCCESS );
}
I compile this code on a machine with Ubuntu 12.04 like this:
g++ ocl_vector_addition.cpp -lOpenCL -std=c++11 -o ocl_vector_addition.o
It produces a ocl_vector_addition.o, which when I run, shows successful output. If you look at the compilation command, you see we have not passed anything about our .cl file. We only have used -lOpenCL flag to enable OpenCL library for our program. Also, don't get distracted by -std=c++11 command. Because I used std::unique_ptr in the host code, I had to use this flag for a successful compile.
So where is this .cl file being used? If you look at the host code, you'll find four parts that I repeat in below numbered:
// 1. Read the program source
std::ifstream sourceFile("vector_add_kernel.cl");
std::string sourceCode( std::istreambuf_iterator<char>(sourceFile), (std::istreambuf_iterator<char>()));
cl::Program::Sources source(1, std::make_pair(sourceCode.c_str(), sourceCode.length()));
// 2. Make program from the source code
cl::Program program=cl::Program(context, source);
// 3. Build the program for the devices
program.build(devices);
// 4. Make kernel
cl::Kernel vecadd_kernel(program, "vecadd");
In the 1st step, we read the content of the file that holds our device code and put it into a std::string named sourceCode. Then we make a pair of the string and its length and save it to source which has the type cl::Program::Sources. After we prepared the code, we make a cl::program object named program for the context and load the source code into the program object. The 3rd step is the one in which the OpenCL code gets compiled (and linked) for the device. Since the device code is built in the 3rd step, we can create a kernel object named vecadd_kernel and associate the kernel named vecadd inside it with our cl::kernel object. This was pretty much the set of steps involved in compiling a .cl file in a program.
The program I showed and explained about creates the device program from the kernel source code. Another option is to use binaries instead. Using binary program enhances application loading time and allows binary distribution of the program but limits portability since binaries that work fine on one device may not work on another device. Creating program using source code and binary are also called offline and online compilation respectively (more information here). I skip it here since the answer is already too long.
My answer comes four years late. Nevertheless, I have something to add that complements #Farzad's answer, as follows.
Confusingly, in OpenCL practice, the verb to compile is used to mean two different, incompatible things:
In one usage, to compile means what you already think that it means. It means to build at build-time, as from *.c sources to produce *.o objects for build-time linking.
However, in another usage—and this other usage may be unfamiliar to you—to compile means to interpret at run time, as from *.cl sources, producing GPU machine code.
One happens at build-time. The other happens at run-time.
It might have been less confusing had two different verbs been introduced, but that is not how the terminology has evolved. Conventionally, the verb to compile is used for both.
If unsure, then try this experiment: rename your *.cl file so that your other source files cannot find it, then build.
See? It builds fine, doesn't it?
This is because the *.cl file is not consulted at build time. Only later, when you try to execute the binary executable, does the program fail.
If it helps, you can think of the *.cl file as though it were a data file or a configuration file or even a script. It isn't literally a data file, a configuration file or a script, perhaps, for it does eventually get compiled to a kind of machine code, but the machine code is GPU code and it is not made from the *.cl program text until run-time. Moreover, at run-time, your C compiler as such is not involved. Rather, it is your OpenCL library that does the building.
It took me a fairly long time to straighten these concepts in my mind, mostly because—like you—I had long been familiar with the stages of the C/C++ build cycle; and, therefore, I had thought that I knew what words like to compile meant. Once your mind has the words and concepts straight, the various OpenCL documentation begins to make sense, and you can start work.
I have a rather interesting problem for which I'm unable to find a resolution. I'm using Setup API to list drives in the system. I have no trouble using the code listed below when setting the enumerator to "IDE". My angst comes when the enumerator value is set to "SCSI". Code which reproduces this problem is below:
#include <iostream>
#include <Windows.h>
#include <SetupAPI.h>
#include <cfgmgr32.h>
#include <devguid.h>
int main() {
std::cout << "Looking for only SCSI disks" << std::endl;
HDEVINFO hDevs(SetupDiGetClassDevs(&GUID_DEVCLASS_DISKDRIVE, "SCSI", NULL, DIGCF_PRESENT));
if(INVALID_HANDLE_VALUE == hDevs) {
DWORD error(GetLastError());
std::cout << "Handle returned is invalid. Error code: " << error << std::endl;
return 1;
}
SP_DEVINFO_DATA sp = {sizeof(SP_DEVINFO_DATA)};
char buff[256];
memset(buff, 0, 256);
DWORD index(0);
std::cout << "The handle is valid, listing drives now" << std::endl;
while(SetupDiEnumDeviceInfo(hDevs, index++, &sp)) {
CM_Get_Device_ID(sp.DevInst, buff, 256, 0);
std::cout << buff << std::endl;
memset(buff, 0, 256);
}
SetupDiDestroyDeviceInfoList(hDevs);
return 0;
}
As you can see, there is nothing remarkable about this code. The problem is, on certain laptops, this code errors at SetupDiGetClassDevs(). Checking GetLastError() reveals that it failed for ERROR_INVALID_DATA (0xd). What I don't understand is why. This exact same program, run on my development box both as my user (with administrator rights) and as an unprivileged user, works just fine whether or not SCSI drives are present.
I know that the GUID in use is correct. It's defined in devguid.h. "SCSI" is a valid PnP enumerator as is referenced on this MSDN page and also from examining the "Enumerator" property in the Device Manager. The third argument may be NULL and the fourth is a valid defined flag for this function. I know this because, except for these laptops, this works on all systems I've ever tried it on (which, in my organization, is quite a few). I'm hoping that someone here may know about what would cause SetupDiGetClassDevs() to fail for this error with these conditions, or could at least point me in the right direction. I'm not a Windows expert and I could be missing something on system configuration or permissions (although not implied from the error).
As I hope is clear, I've run this code on the one laptop I can test it on as both a user with Administrator privileges and as the Administrator user: both with the same result. The laptop is an HP EliteBook 8460p running Windows 7 64-bit Service Pack 1. Compiling this code in 32 or 64 bits makes no difference.
I'm going to post the answer I got from a fellow on the MSDN support forums to help someone who may be confounded by this same issue. Apparently, this is expected behavior for Windows 7. If the system has never seen hardware with the enumerator specified to SetupDiGetClassDevs(), then a failure occurs and this error code is expected.
For reference, the thread where I asked this question is linked here.