In the header stat.h on osx 10.7 I found a define in fileflag UF_TRACKED. I googled that define but didn't find anything about the flag. Can you describe to me what this flag means? I encountered it when I tried to apply attributes to the file which placed on the mounted folder. That folder is HFS+ folder on the remoted osx 10.7.3.
Maybe I can ignore it? And what can happen in that case?
The UF_TRACKED is a flag which tells HFS to send an event to a tracked file handler in user mode on any change to the file's dentry (i.e. rename or delete, and changes in metadata, but not file modification). You can see that both in the header file:
#define UF_TRACKED 0x00000040 /* file renames and deletes are tracked */
The code to handle this is in the kernel, bsd/hfs/hfs_vfsutils.c:
int
check_for_tracked_file(struct vnode *vp, time_t ctime, uint64_t op_type, void *arg)
{
int tracked_error = 0, snapshot_error = 0;
if (vp == NULL) {
return 0;
}
if (VTOC(vp)->c_bsdflags & UF_TRACKED) {
...
And is called all over the place, primarily from hfs_vnops.c
Related
I am trying to use
wchar_t wFilename[MAX_PATH];
mbstowcs(wFilename, szFileNAme, MAX_PATH);
D3DCompileFromFile(wFilename, NULL, D3D_COMPILE_STANDARD_FILE_INCLUDE, szEntryPoint, szShaderModel, dwShaderFlags, 0, ppBlobOut, &pErrorBlob);
to compile my shaders for DirectX 11 and I keep getting a file not found error on the shader file. It is in the same directory as the file that is making the above call.
What could I be missing?
Edit: I've tried adding the shader file to my project which required another shader file which I added as well. Doing this causes an error: 'main':entrypoint not found for file "FXC"
Is that your entire code? As is, you aren't checking the return value of mbstowcs. It could be invalid due to an error and the destination array could be ill-formed. Hence, the "file not found" error.
If you are compiling the shader in-code then you need to tell Visual Studio to not compile the shader as part of the build process. You can do this by excluding it via right-clicking on the file in the solution explorer then Properties > General > Exclude from build: Yes
You are getting the error because the main entry point of your function is not named main and that's the default that FXC looks for. You can change it in the same properties pane as before: Properties > HLSL Compiler > General > Entrypoint name.
But, since you are compiling in-code with custom entry points, you should disable build-step compiling, so changing the entrypoint name will have no effect.
First you have to make sure that visual studio is copying the file into the build directory (that the executable is being executed from).
The DXSample.h header uses this code to find the executables directory path at runtime
inline void GetAssetsPath(_Out_writes_(pathSize) WCHAR* path, UINT pathSize)
{
if (path == nullptr)
{
throw std::exception();
}
DWORD size = GetModuleFileName(nullptr, path, pathSize);
if (size == 0 || size == pathSize)
{
// Method failed or path was truncated.
throw std::exception();
}
WCHAR* lastSlash = wcsrchr(path, L'\\');
if (lastSlash)
{
*(lastSlash + 1) = L'\0';
}
}
Here are some fragments of it being use
std::wstring m_assetsPath;
WCHAR assetsPath[512];
GetAssetsPath(assetsPath, _countof(assetsPath));
m_assetsPath = assetsPath;
std::wstring DeviceResources::GetAssetFullPath(LPCWSTR assetName)
{
return m_assetsPath + assetName;
}
deviceResources.GetAssetFullPath(L"compute_shader.cso").c_str(),
'main':entrypoint not found for file "FXC"
You probably have not specified what kind of shader it is in visual studio properly.
I have a Visula C++ console application in MS VS 2013 where I'm checking the existence of folder on a hard drive. I use GetFileAttributes() function for it in the following way:
int _tmain(int argc, _TCHAR* argv[])
{
string folderPath = argv[1];
if (GetFileAttributes(folderPath.c_str()) == FILE_ATTRIBUTE_DIRECTORY)
{
// Do something here
}
else
{
// Also do something here
}
return 0;
}
But the result of GetFileAttributes() is equal to FILE_ATTRIBUTE_DIRECTORY (0x10) only if I set (in command line arguments) a fully qualified path to folder. For example: "M:\MS_VS2013_Projects\WordsCounter\Debug\TextFiles_to_Test" where "M" is a hard drive name.
But if I try to set (in command line arguments) a relative path for example: "TextFiles_to_Test" or "M:TextFiles_to_Test" or "\TextFiles_to_Test" or ".\TextFiles_to_Test" then GetFileAttributes() returns the wrong result == 4294967295. How can I achieve the correct resuli (0x10) in case of relative path to folder? I'll be very thankful for your help.
This is not specific to Windows XP. I made some tests on Windows 7. It doesn't work with relative paths, and also doesn't work with "reparse points". For instance, if you use localized versions of a folder, it won't work.
Ex: on a French Windows OS, only the 1st of the following calls will succeed.
DWORD dwAttr1 = ::GetFileAttributesW(L"C:\\Program Files");
DWORD dwAttr2 = ::GetFileAttributesW(L"Program Files"); //relative folder
DWORD dwAttr3 = ::GetFileAttributesW(L"C:\\Programmes"); //NTFS Junction point
DWORD dwAttr4 = ::GetFileAttributesW(L"Programmes");
In Windows environments (XP and Win 7):
What is the best way to automatically have a crash dump generated when processes crash on the system?
Can an installer (MSI) package do this?
One of the best way to have an automatic dump for any/specific process on Windows is to configure a set of entries in the registry. I tried the below on Windows 7 64 bit.
Open notepad.exe, paste the below entry and save it as "EnableDump.reg". You can give any name you wish.
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps]
"DumpFolder"=hex(2):44,00,3a,00,5c,00,64,00,75,00,6d,00,70,00,00,00
"DumpCount"=dword:00000010
"DumpType"=dword:00000002
"CustomDumpFlags"=dword:00000000
Double click the "EnableDump.reg" and select 'Yes'. I have given the dump folder as 'd:\dump'. You can change it to whatever folder you wish.
Try to execute a crashing application, Windows will display the error dialog. Choose 'Close the Program' option. After that you will see the dump in the configured folder. The name of the dump file will be .exe..dmp.
For more details, you can refer the below link.
http://msdn.microsoft.com/en-us/library/bb787181(VS.85).aspx
Below explanation is based on another answer, but the logic is mine (without attribution need, as said on my profile);
Having your own dump generation framework which automatically creates a process dump when any Unhandled exception is encountered, would avoid clients having to install WinDbg.
At the application start up use SetUnhandledExceptionFilter(...) Win32 API to register a callback (i.e. application level exception-handler).
Now the registered callback function is called whenever there is any exception which is not handled. You may then create the process dump using MiniDumpWriteDump(...) API from DbgHelp.dll.
C++ Sample (unicode-enabled)
header-file
#ifndef CRASH_REPORTER_H
#define CRASH_REPORTER_H
//Exclude rarely used content from the Windows headers.
#ifndef WIN32_LEAN_AND_MEAN
# define WIN32_LEAN_AND_MEAN
# include <windows.h>
# undef WIN32_LEAN_AND_MEAN
#else
# include <windows.h>
#endif
#include <tchar.h>
#include <DbgHelp.h>
class CrashReporter {
public:
inline CrashReporter() { Register(); }
inline ~CrashReporter() { Unregister(); }
inline static void Register() {
if(m_lastExceptionFilter != NULL) {
fprintf(stdout, "CrashReporter: is already registered\n");
fflush(stdout);
}
SetErrorMode(SEM_FAILCRITICALERRORS);
//ensures UnHandledExceptionFilter is called before App dies.
m_lastExceptionFilter = SetUnhandledExceptionFilter(UnHandledExceptionFilter);
}
inline static void Unregister() {
SetUnhandledExceptionFilter(m_lastExceptionFilter);
}
private:
static LPTOP_LEVEL_EXCEPTION_FILTER m_lastExceptionFilter;
static LONG WINAPI UnHandledExceptionFilter(_EXCEPTION_POINTERS *);
};
#endif // CRASH_REPORTER_H
source-file
#include "crash-report.h"
#include <stdio.h>
LPTOP_LEVEL_EXCEPTION_FILTER CrashReporter::m_lastExceptionFilter = NULL;
typedef BOOL (WINAPI *MiniDumpWriteDumpFunc)(HANDLE hProcess, DWORD ProcessId
, HANDLE hFile
, MINIDUMP_TYPE DumpType
, const MINIDUMP_EXCEPTION_INFORMATION *ExceptionInfo
, const MINIDUMP_USER_STREAM_INFORMATION *UserStreamInfo
, const MINIDUMP_CALLBACK_INFORMATION *Callback
);
LONG WINAPI CrashReporter::UnHandledExceptionFilter(struct _EXCEPTION_POINTERS *exceptionPtr)
{
//we load DbgHelp.dll dynamically, to support Windows 2000
HMODULE hModule = ::LoadLibraryA("DbgHelp.dll");
if (hModule) {
MiniDumpWriteDumpFunc dumpFunc = reinterpret_cast<MiniDumpWriteDumpFunc>(
::GetProcAddress(hModule, "MiniDumpWriteDump")
);
if (dumpFunc) {
//fetch system time for dump-file name
SYSTEMTIME SystemTime;
::GetLocalTime(&SystemTime);
//choose proper path for dump-file
wchar_t dumpFilePath[MAX_PATH] = {0};
_snwprintf_s(dumpFilePath, MAX_PATH, L"crash_%04d-%d-%02d_%d-%02d-%02d.dmp"
, SystemTime.wYear, SystemTime.wMonth, SystemTime.wDay
, SystemTime.wHour, SystemTime.wMinute, SystemTime.wSecond
);
//create and open the dump-file
HANDLE hFile = ::CreateFileW( dumpFilePath, GENERIC_WRITE
, FILE_SHARE_WRITE
, NULL
, CREATE_ALWAYS
, FILE_ATTRIBUTE_NORMAL | FILE_ATTRIBUTE_HIDDEN
, NULL
);
if (hFile != INVALID_HANDLE_VALUE) {
_MINIDUMP_EXCEPTION_INFORMATION exceptionInfo;
exceptionInfo.ThreadId = GetCurrentThreadId();
exceptionInfo.ExceptionPointers = exceptionPtr;
exceptionInfo.ClientPointers = NULL;
//at last write crash-dump to file
bool ok = dumpFunc(::GetCurrentProcess(), ::GetCurrentProcessId()
, hFile, MiniDumpNormal
, &exceptionInfo, NULL, NULL
);
//dump-data is written, and we can close the file
CloseHandle(hFile);
if (ok) {
//Return from UnhandledExceptionFilter and execute the associated exception handler.
// This usually results in process termination.
return EXCEPTION_EXECUTE_HANDLER;
}
}
}
}
//Proceed with normal execution of UnhandledExceptionFilter.
// That means obeying the SetErrorMode flags,
// or invoking the Application Error pop-up message box.
return EXCEPTION_CONTINUE_SEARCH;
}
usage
#include "3rdParty/crash-report.h"
int main(int argc, char *argv[])
{
CrashReporter crashReporter;
(void)crashReporter; //prevents unused warnings
// [application main loop should be here]
return 0;
}
Windows XP:
The following steps enable automatic crash dumps:
1) Open a command prompt, running as administrator
2) Run drwtsn32 -i. This will install Doctor Watson as the default debugger when something crashes
3) Click Ok
4) From the command prompt, run drwtsn32
5) Set the Crash Dump path to your favorite directory, or leave the default.
6) Set the Crash Dump Type to mini. Note that under some circumstances, we may ask you for a full crash dump.
7) Make sure the Dump All Thread Contexts and Create Crash Dump File options are selected.
8) Click Ok
9) If a user.dmp file already exists in the Crash Dump path, delete it.
Windows 7: Location is:
C:\Users[Current User when app crashed]\AppData\Local\Microsoft\Windows\WER\ReportArchive
I'm trying to view the filename via kgdb, so I cannot call functions and macros to get it programatically. I need to find it by manually inspecting data structures.
Like if I had a breakpoint here in gdb, how could I look around with gdb and find the filename?
I've tried looking around in filp.f_path, filp.f_inode, etc. I cannot see the filename anywhere.
ssize_t do_sync_write(struct file *filp, const char __user *buf, size_t len, loff_t *ppos)
{
struct iovec iov = { .iov_base = (void __user *)buf, .iov_len = len };
struct kiocb kiocb;
ssize_t ret;
init_sync_kiocb(&kiocb, filp);
kiocb.ki_pos = *ppos;
kiocb.ki_left = len;
kiocb.ki_nbytes = len;
ret = filp->f_op->aio_write(&kiocb, &iov, 1, kiocb.ki_pos);
if (-EIOCBQUEUED == ret)
ret = wait_on_sync_kiocb(&kiocb);
*ppos = kiocb.ki_pos;
return ret;
}
You can get the filename from struct file *filp with filp->f_path.dentry->d_iname.
To get the full path call dentry_path_raw(filp->f_path.dentry,buf,buflen).
In the Linux kernel, the file structure is essentially how the kernel "sees" the file. The kernel is not interested in the file name, just the inode of the open file. This means that all of the other information which is important to the user is lost.
EDIT: This answer is wrong. You can get the dentry using filp->f_path.dentry. From there you can get the name of the dentry or the full path using the relevant FS flags.
The path is stored in the file->f_path structure as it's name implies. Just not in a plain-text form, but parsed into objects that are more useful for kernel operation, namely a chain of dentry structures, and the vfsmount structure pointing to the root of the current subtree.
You can use the d_path function to regenerate a human-readable path name for a struct path like file->f_path. Note that however this is not a cheap operation and it may slow down your workload significantly.
The above mentioned issues about open but unlinked files, multiple hardlinks and similar are valid for mapping from and inode to a pathname, and open file always has a path associated with it. If the file has been unlinked d_path will prepend a " (deleted)" to the name, and if the filename it has been opened with has been changed to something else using rename since it was opened d_path will not print the original name, but the current name of the entry that was used for opening it.
filp->f_path.dentry->d_name.name
This worked for me
I need to change reference of a function in a Mac OS process at runtime to a custom function defined in my own custom dylib. I kept the new function signature same as the original.
For example I need to change "open" function to "myopen" function.
I tried processing __LINKEDIT segment to get the dynamic symbol table and string table.
I used following pointers,
1. the VMAddrress from __LINKEDIT segment,
2. mach_header and vmaddr_slide from the "_dyld_register_func_for_add_image" callback,
3. symoff and stroff from symtab_command.
But I am unable to get the symbol table and string table mentioned in the __LINKEDIT segment.
Can someone throw some light on this?
Thanks in advance.
If the function in question is a library function, and not statically compiled into the executable, you don't need to do any of that - you can use function interposing, instead. Specifically, add this to your library:
// The attribute creates a Mach-O Section in your library - q.v. libgmalloc.dylib for
// a nice example
static const interpose_t interposing_functions[] \
__attribute__ ((section("__DATA, __interpose"))) = {
{ (void *)my_open, (void *)open },
{ (void *)my_close, (void *)close }, // .. etc
};
int my_open(const char *path, int flags, mode_t mode)
{
int rc;
// Prolog - do something before open
rc = open(path, flags, mode); // call real open
// Epilog - record rc, etc..
return rc;
}
There are several excellent books on OS X internals which can provide you with samples, though apparently according to S.O site policies we can't link you to them. That said, the above code snippet should work. Bear in mind, that this won't work on calls to open performed by other dylibs (though there are more complicated ways to get that, as well)