Do minidump files contain the timestamp of the crash? - minidump

The MiscInfoStream in a minidump file contains the process create time. I'd like to find out how long the process has been running for before the crash. Does a minidump file contain the exception timestamp anywhere?
WinDbg on this dump file displays the following, which implies that it's in there somewhere...
Debug session time: Tue Dec 29 15:49:20.000 2009 (GMT+0)
System Uptime: not available
Process Uptime: 0 days 0:33:03.000
(DumpChk displays the same information, at the end of the list of streams)
Note that today's Mar 15, so this is almost certainly the timestamp of the crash. I'd like a programmatic way to retrieve that value and the "Process Uptime" value.
I found the MINIDUMP_MISC_INFO_3 structure, which contains some timezone information, but it doesn't seem to contain the exception time.
Some dump files appear to have a ThreadInfoListStream, which contains the timestamps for each thread in the process, but this isn't included in the minidumps that I've seen.

You can get the values for the crash time and the process up time using the dbgeng api. See the Windbg sdk directory for the dumpstk sample - you can modify it to get at this information.
My code below assumes you've added a new query interface for the system objects 2 interface into a new global g_SysObjects.
IDebugSystemObjects2* g_SysObjects;
and changed g_Control from IDebugControl to IDebugControl2.
#include <time.h>
void DumpUpTimeAndCrashTime()
{
ULONG upTime = 0;
g_SysObjects->GetCurrentProcessUpTime(&upTime);
int days = upTime / (60*60*24);
int hours = (upTime % (60*60*24)) / (60*60);
int minutes = (upTime % (60*60))/60;
int seconds = upTime % 60;
printf("Process uptime %d days %02d:%02d:%02d.000\n",
days, hours, minutes, seconds);
ULONG crashTime = 0;
g_Control->GetCurrentTimeDate(&crashTime);
time_t ct = crashTime;
printf( "Crash time and date: %s", _ctime64( &ct ) );
}

I don't think the time of the exception is stored anywhere in the minidump file. The exception structure certainly does not contain this info:
http://msdn.microsoft.com/en-us/library/ms680367%28VS.85%29.aspx
The misc info struct does contain the process start time, but not the exception time:
http://msdn.microsoft.com/en-us/library/ms680389%28VS.85%29.aspx
You can see all the possible contents of a minidump here:
http://msdn.microsoft.com/en-us/library/ms680394%28v=VS.85%29.aspx

Related

How to load 500MB data from txt file in QT

I am working on a big (~500Mb) RAW txt file.
There are about 20,000,000 lines in the file.
Each line includes one double and one int. For example:
45782.1234852 10
Below is my simple code:
QTextStream rdStream(&qFile_Input);
while (!rdStream.atEnd())
{
//QStringList qList_data=rdStream.readLine().split(" ",QString::SkipEmptyParts);
rdStream.readLine();
}
It takes about 30 seconds just to read line QTextStream::readLine();
If I add .split(" ",QString::SkipEmptyParts) into a Qstringlist, then the total time required jumps to 5 minutes. My question is three fold:
Where does the time gap comes from?
Is there a way to get a shorter processing time?
If my file is larger than the RAM of PC, will I encounter an
error? If so, what can I do?
Thanks in advance!
Well, it seems that the splitting part adds an enormous overhead time-wise. Instead of using the Qt class QTextStream, you could probably just use the methods from the c++ standard library. You should get better performance than the 5 minutes you are seeing now.
#include <fstream>
int main()
{
std::ifstream infile("thefile.txt");
double a;
int b;
while(infile >> a >> b)
{
//Do something with a and b here, they've been read
}
return 0;
}

Prefix Sum with global memory and an error with local memory

I have a Mali GPU which does not support local memory at all.
Everytime I run code consisting of local memory it gives me some errors from the device.
So, I want to transfer my codes to a version that only uses global memory.
I was thinking if it is possible to run a prefix sum/parallel reduction algorithm using global memory only on GPU.
EDITED : I was debugging the error and found a strange thing that one particular line is giving the erorr.
I have e line like this:
`#define LOG_LSIZE 8`
`#define LSIZE_SHIFT_VALUE 4`
`#define LOG_NUM_BANKS 2`
`#define GET_CONFLICT_OFFSET(lid) ((lid) >> LOG_NUM_BANKS)`
`#define LSIZE 32`
`__local int lm_sum[2][LSIZE + LOG_LSIZE]`
`**lm_sum[lid >> LSIZE_SHIFT_VALUE][bi] += lm_sum[lid >> LSIZE_SHIFT_VALUE][ai]**`
lid is local id and I used qork groups size 32. I found that the highlighted line is the cause of the error. I tried using fixed values and found that I cannot use lm_sum on the right side of a statement. If I do, that gives me an error. For example, this line also gives me error:
int temp= lm_sum[0][0]
Any idea on what is going on?
Error:
`In initial.cpp***[14100.684249] Mali<ERROR, BASE_MMU>: In file: /home/jbmaster/work/01.LPD_OpenCL_RFS/01.arm_work_3_0_31/SEC_All_EVT0_TX013-BU-00001-r2p0-00rel0/TX013-BU-00001-r2p0-00rel0/driver/product/kernel/drivers/gpu/arm/t6xx/kbase/src/common/mali_kbase_mmu.c line: 1240 function:kbase_mmu_report_fault_and_kill
[14100.709724] Unhandled Page fault in AS0 at VA 0x00000002000EC1A0
[14100.709728] raw fault status 0x500003C3
[14100.709730] decoded fault status: SLAVE FAULT
[14100.709733] exception type 0xC3: TRANSLATION_FAULT
[14100.709736] access type 0x3: WRITE
[14100.709738] source id 0x5000
[14100.734958]
[14100.736432] Mali<ERROR, BASE_JD>: In file: /home/jbmaster/work/01.LPD_OpenCL_RFS/01.arm_work_3_0_31/SEC_All_EVT0_TX013-BU-00001-r2p0-00rel0/TX013-BU-00001-r2p0-00rel0/driver/product/kernel/drivers/gpu/arm/t6xx/kbase/src/common/mali_kbase_jm.c line: 899 function:kbase_job_slot_hardstop
[14100.761458] Issueing GPU soft-reset instead of hard stopping job due to a hardware issue
[14100.769517] `
Since lm_sum[0][0] doesn't work, the memory for the array is not allocated. You said your GPU doesn't support local memory. Well, you are trying to use lm_sum which is declared to be in local memory (__local int lm_sum[2][LSIZE + LOG_LSIZE]).

ftruncate failed at the second time

I'm trying to exceed the shared memory object after shm_open and ftruncate successfully at fisrt. Here is the code,
char *uuid = GenerateUUID();
int fd = shm_open(uuid, O_RDWR|O_CREAT|O_EXCL, S_IRUSR|S_IWUSR);
if(fd == -1) perror("shm_open");
size_t shmSize = sizeof(container);
int ret = ftruncate(fd, shmSize);
perror("ftruncate first");
ret = ftruncate(fd, shmSize * 2);
perror("ftruncate second");
It could pass the first ftruncate, but for the second ftruncate, it exceeds failed with errno=22, "Invalid argument".
I also tried to ftruncate the memory object after mmap, refer to the ftruncate's man page, the shared memory should be formatted as zero to the new length.
Besides, I also tried to ftruncate the memory object in the child process (This is an IPC topic among two processes), the ftruncate returns "Invalid fd, no such file or directory" but I could shm_open and mmap successfully in child process.
Any ideas? Thanks!
I think this is a known "feature" of shm_open(), ftruncate(), mmap().
You have to ftruncate() the first time through to give the shared memory a length, but subsequent times ftruncate() gives that error number 22, which you can simply ignore.
The used implementation seems to conform to an older specification where returning an error is an allowed behavior for ftruncate(fd, length) when length exceeds the previous length:
If the file previously was smaller than this size, ftruncate() shall
either increase the size of the file or fail.

Qt QSharedMemory Segmentation Faults after Several Successful Writes

I'm using QSharedMemory to store some data and want to subsequently append data to what is contained there. So I call the following code several times with new data. The "audioBuffer" is new data given to this function. I can call this function about 4-7 times ( and it varies ) before it seg faults on the memcpy operation. The size of the QSharedMemory location is huge so in the few calls that I do before seg faulting, there is no issue of memcpy copying data beyond it's boundaries. Also, m_SharedAudioBuffer.errorString() gives no errors up to the memcpy operation. Currently, I only have one process using this QSharedMemory segment. I also tried to write continually without appending each time and that works fine, so something is happening when I try to append more data to the shared memory segment. Any ideas? Thanks!
// Get the buffer size for the current audio buffer in shared memory
int bufferAudioDataSizeBytes = readFromSharedAudioBufferSizeMemory(); // This in number of bytes
// Create a bytearray with our data currently in the shared buffer
char* bufferAudioData = readFromSharedAudioBufferMemory();
QByteArray currentAudioStream = QByteArray::fromRawData(bufferAudioData,bufferAudioDataSizeBytes);
QByteArray currentAudioStreamDeepCopy(currentAudioStream);
currentAudioStreamDeepCopy.append(audioBuffer);
dataSize = currentAudioStreamDeepCopy.size();
//#if DEBUG
qDebug() << "Inserting audio buffer, new size is: " << dataSize;
//#endif
writeToSharedAudioBufferSizeMemory( dataSize ); // Just the size of what we received
// Write into the shared memory
m_SharedAudioBuffer.lock();
// Clear the buffer and define the copy locations
memset(m_SharedAudioBuffer.data(), '\0', m_SharedAudioBuffer.size());
char *to = (char*)m_SharedAudioBuffer.data();
char *from = (char*)audioBuffer.data();
// Now perform the actual copy operation to store the buffer
memcpy( to, from, dataSize );
// Release the lock
m_SharedAudioBuffer.unlock();
EDIT: Perhaps, this is due to my target embedded device which is very small. The available RAM is large when I am trying to write to shared memory, but I notice that in the /tmp directory ( which is only given 4Mb ) I have the following entries - the size is not nearly consumed in /tmp though so I'm not sure why I couldn't allocate more memory, also the QSharedMemory::create method never fails for my maximum size of 960000:
# cd /tmp/
# ls
QtSettings
lib
qipc_sharedmemory_AudioBufferData2a7d5f1a29e3d27dac65b4f350d76a0dfd442222
qipc_sharedmemory_AudioBufferSizeData6b7acc119f94322a6794cbca37ed63df07b733ab
qipc_systemsem_AudioBufferData2a7d5f1a29e3d27dac65b4f350d76a0dfd442222
qipc_systemsem_AudioBufferSizeData6b7acc119f94322a6794cbca37ed63df07b733ab
qtembedded-0
run
The problem seemed to be that I was using QByteArray's ::fromRawData on the pointer returned by the shared memory segment. When I copied that data explicitly using memcpy on this pointer, and then constructed my QByteArray using the copied data, then the seg faults stopped.

How to get the current TimeStamp?

I'm trying to get the current time as TimeStamp without success.
I have this code:
QDateTime setTime = QDateTime::fromString (QString("1970-07-18T14:15:09"), Qt::ISODate);
QDateTime current = QDateTime::currentDateTime();
uint msecs = setTime.time().msecsTo(current.time());
return QString::number(msecs);
The output is
Sunday, January 25th 1970, 03:17:35 (GMT)
In Qt 4.7, there is the QDateTime::currentMSecsSinceEpoch() static function, which does exactly what you need, without any intermediary steps. Hence I'd recommend that for projects using Qt 4.7 or newer.
I think you are looking for this function:
http://doc.qt.io/qt-5/qdatetime.html#toTime_t
uint QDateTime::toTime_t () const
Returns the datetime as the number of seconds that have passed since 1970-01-01T00:00:00, > Coordinated Universal Time (Qt::UTC).
On systems that do not support time zones, this function will behave as if local time were Qt::UTC.
See also setTime_t().
Since Qt 5.8, we now have QDateTime::currentSecsSinceEpoch() to deliver the seconds directly, a.k.a. as real Unix timestamp. So, no need to divide the result by 1000 to get seconds anymore.
Credits: also posted as comment to this answer. However, I think it is easier to find if it is a separate answer.

Resources