I have changed in if (!sentMessage) sendMessage(wsm->getWsmData());
to if
(!sentMessage) sendMessage(wsm->getWsmeData());
(i.e "getWsmeData" which i added the WsmeDat in the waveshortmessage) on
"void TraCIDemo11p::onData(WaveShortMessage* wsm)". When I run the program on node [3] i get this error. I wanted to simulate for sending changed message. the error is:
Error in module (TraCIDemo11p) net.node[3].appl (id=26) at event #329, t=26.303493715545: TraCI server reported error executing command 0x23bfe8 (",²X").. Where should i check in order to correct this error.
Thank you.
The large, seemingly random value looks like a problem with overwritten memory. My recommendation would be to use a memory debugger like valgrind.
Related
So i've been trying to write a pintool that monitors call/ret instructions but i've noticed that threre was a significant inconsistency between the two. For example ret instructions without previous call.
I've run the tool in a console application from which i got the following logs showing this inconsistency (this is an example, there are more inconsistencies like the one listed below in the other call/ret instructions):
1. Call from ntdll!LdrpCallInitRoutine+0x69, expected to return to 7ff88f00502a
2. RETURN to 7ff88f00502a
//call from ntdll!LdrpInitializeNode+0x1ac which is supposed to return at 7ff88f049385 is missing (the previous instruction)
3. RETURN to 7ff88f049385 (ntdll!LdrpInitializeNode+0x1b1)
The above are the first 3 log entries for the call/ret instructions. As one can see, the monitoring started a bit late, at the call found at ntdll!LdrpCallInitRoutine+0x69, it returned to the expected address but then returned to 7ff88f049385 without first tracking the call found in the previous instruction.
Any ideas of what could be the fault?
The program is traced with INS_AddInstrumentFunction with a callback that more or less does:
if INS_IsCall(ins) INS_InsertCall(ins,...
if INS_IsRet(ins) INS_InsertCall(ins,...
I've tried the same program on Linux which worked as expected, without any mismatch.
Any ideas of the reason behind this behavior?
When a syscall fails, it returns an error code. Generally the man page is well written and careful reading already provide good hints to fix the error.
Sometimes however, the error is trickier and I want to find the line sending the error in the kernel, ideally, with the relevant stack trace.
When a program is stuck, I know I can get the kernel side stacktrace with:
cat /proc/[PID OR TID OF INTEREST]/stacktrace
However, when it is running and returning an error with no hangs, this is of little help.
Is there a way to get a stacktrace when an unknown function returns a specific error in a given syscall ?
Below is a code snippet where I deliberately cause 2 NullPointerException. The first one is handled. Whereas the second one goes unhandled. I want to create a crash dump on the second exception when a crash would occur.
int* nullPtr = NULL;
try{
x = *nullPtr;
}
catch(...) {
QLOG_WARNING0(QTEXT("catching 1st null ptr exception."));
}
y = *nullPtr;
This does crash the process but the dump is not generated using -e option only.
What options should I use to get the dump?
Or is there a way I could achieve this with debugDiag tool? If so, how?
This is only a sample code. The actual use case I am debugging has a process crashing but I am unable to take dumps for the crash. There are valid handled exceptions where the dump is getting triggerred in case I use the first chance option( - e 1). This is causing procdump to exit before the actual crash occurs.
“No I am open to any other tool.”
Per your comment, there are other ways to trap a dump file. In my answer to Getting detailed crash dumps from a hooked exe,
you’ll see that you can set some registry key settings to trap the dump from an unhandled exception. The settings assume you have Windows Error Reporting enabled. I’ve gone so far as to incorporate those settings into a small utility program that my company uses when debugging difficult customer crashes.
I am using PREFast to check some driver code build for Windows7. The following line of code
stackDeviceObject = IoAttachDeviceToDeviceStack(deviceObject, PhysicalDeviceObject);
Gives the warning:
warning 28107: The Memory 'deviceObject' must be held when calling 'IoAttachDeviceToDeviceStack'.
deviceObject is obtained with an earlier call to IoCreateDevice. Does anyone know what this warning means and how to get rid of it?
The PREfast help says "A resource that the program must acquire before calling the function was not acquired when the function was called. As a result, the function call will fail."
The example that the help page provides surrounds a pair of calls to ExAcquireResourceLite and ExReleaseResourceLite (which gives this warning) between calls to KaEnterCriticalRegion and KaLeaveCriticalRegion, which then supposedly gets rid of the warning, but I don't know how to apply this info to my call to IoAttachDeviceToDeviceStack.
Any advice would be appreciated.
I believe I have an answer to my own question. The call to IoCreateDevice was in a separate function which was called from this one. I think this was stopping PREfast from seeing that this function was being called and deviceObject was being correctly initialised before the call to IoAttachDeviceToDeviceStack was called.
I have moved the IoCreateDevice call into the same function as IoAttachDeviceToDeviceStack and the warning went away.
Thanks to anyone that spent time reading this and trying to find an answer.
I am trying to run the sample C program that came with my NI USB-6008 DAQ card. I am trying to run the "ContGen-ExtClk.c" example. I get the following error when I build the program:
DAQmx Error: Requested value is not a supported value for this property. The property value may be invalide because it conflicts with another property.
Property: DAQmx_SampTimingType
Requested Valeu: DAQmx_Val_SampClk
You Can Select: DAQmx_Val_OnDemand
Task Name: _unnamedTask<0>
Status Code: -200077
End of program, press Enter key to quit
If anyone is familiar with the USB-6008, I would appreciate the help. Thanks!
Turns out it is a hardware issue with how many samples can be sent over the analog out channel... dunce move.