Sometimes while trying to view a memory through Lauterbach, I get the error "No more arguments expected" and I am unable to view memory. Why this happens and what is the resolution?
d 0x83000000 /sl
no more arguments expected
You get the error message "no more arguments expected" when you use more augments with a command than the command actually accepts. E.g.:
Data.dump 0x83000000 /SpotLight 5
Data.dump 0x83000000 0x42
d 0x83000000 sl
However d 0x83000000 /sl seems not to contain a superfluous argument.
So either there is an invisible character - which can happen if you send the command via the remote API or you copy and paste the command from some editor - or there is a glitch in your version of TRACE32, in which you should contact the Lauterbach support.
Related
I have a huge application (made in PowerBuilder) that crashes every once in a while so it is hard to reproduce this error. We have it set up so that when a crash like this occurs, we recieve a .dmp file.
I used WinDbg to analyze my .dmp file with the command !analyze -v. From this I can deduct that the error that occured was an Access Violation C0000005. Based on the [0] and [1] parameters, it attempted to dereference a null pointer.
WinDbg also showed me STACK_TEXT consisting of around 30 lines, but I am not sure how to read it. From what I have seen I need to use some sort of symbols.
First line of my STACK_TEXT is this:
00000000`00efca10 00000000`75d7fa46 : 00000000`10df1ae0 00000000`0dd62828 00000000`04970000 00000000`10e00388 : pbvm!ob_get_runtime_class+0xad
From this, my goal is to analyze this file to figure out where exactly in the program this error happened or which function it was in. Is this something I will be able to find after further analyzing the stack trace?
How can I pinpoint where in the program a crash happened using .dmp and WinDbg so I can fix my code?
If you analyze a crash dump with !analyze -v, the lines after STACK TEXT is the stack trace. The output is equivalent to kb, given you set the correct thread and context.
The output of kb is
Child EBP
Return address
First 4 values on the stack
Symbol
The backticks ` tell you that you are running in 64 bit and they split the 64 bit values in the middle.
On 32 bit, the first 4 parameters on the stack were often equivalent to the first 4 parameters to the function, depending on the calling convention.
On 64 bit, the stack is not so relevant any more, because with the 64 bit calling convention, parameters are passed via registers. Therefore you can probably ignore those values.
The interesting part is the symbol like pbvm!ob_get_runtime_class+0xad.
In front of ! is the module name, typically a DLL or EXE name. Look for something that you built. After the ! and before the + is a method name. After the + is the offset in bytes from the beginning of the function.
As long as you don't have functions with thousands of lines of code, that number should be small, like < 0x200. If the number is larger than that, it typically means that you don't have correct symbols. In that case, the method name is no longer reliable, since it's probably just the last known (the last exported) method name and a faaaar way from there, so don't trust it.
In case of pbvm!ob_get_runtime_class+0xad, pbvm is the DLL name, ob_get_runtime_class is the method name and +0xad is the offset within the method where the instruction pointer is.
To me (not knowing anything about PowerBuilder) PBVM sounds like the PowerBuilder DLL implementation for Virtual Memory. So that's not your code, it's the code compiled by Sybase. You'd need to look further down the call stack to find the culprit code in your DLL.
After reading Wikipedia, it seems that PowerBuilder does not necessarily compile to native code, but to intermediate P-Code instead. In this case you're probably out of luck, since your code is never really on the call stack and you need a special debugger or a WinDbg extension (which might not exist, like for Java). Run it with the -pbdebug command line switch or compile it to native code and let it crash again.
I'm using the LLDB extension for VSCode, and my variables typed as i8 are printed as characters. Both in the VSCode debugging panel, and when using print in the debugger console.
The variable is defined in the following way:
for y in 0..self.height
self.height being an i8.
I found How do I make the Xcode debugger show uint8_t values as numbers?, but even trying to add a fromat: type format add -f decimal int8_t, print y still outputs (signed char) $5 = '\a' instead of (let me consult the C escape sequences and the ascii chart...) 7.
If anybody else runs into this, this might be of use:
frame variable --format d y
The variable will be printed as "decimal" indicated by the d. A list of all formats can (AFAIK) be found here: https://lldb.llvm.org/use/variable.html#id1.
After further trail and error, I figured out how to format all "signed char" in decimals, at least for the current session:
type format add --format d 'signed char'
This will work both when printing the variable in the debug console, and it will also update the values in the debug panel of VSCode immediately.
If anybody knows how to get this persistent, or even better, tell LLDB that the type is in fact not a char but an integer, please let me know.
I know the thread is a few months old, but i encountered the same issue. I managed to fix it by going to the extension settings for CodeLLDB through the UI, and adding the command under Pre Run Commands. For some reason it doesn't work through the launch.json for me either.
For my use case I just added:
type format add --format u 'unsigned char'
I've been looking around.
storeEval does not exist anymore.
Commands 'runScript' & 'executeScript' seem to replace it.
However, the syntax proposed in many posts javascript{script here} is not accepted: it refuses the first {. Same for the variables with the storeVars['foo'] which seems to be replaced by ${foo}.
Trying any javascript expression (even very simple) with both commands gets me a message 'Failed: missing ) after argument list'.
For instance: | run Script | "aString" + ${previouslyStoredVar} | outputVar |
(note: the syntax of the command seems to be 'runScript', but appears as 'run script' in the IDE window).
I tried adding a return(expression), putting brackets around the expression, enclosing ${previouslyStoredVar} in double quotes, trying with an even simpler expression, and everything I could think of, but with always the same error message.
What is it I am doing wrong? It must be obvious but I can't figure it out!
Many thanks,
E.
My bad: just tried with 'return ${price_string}.substr(0, 5)' and it works. Have to find out why the other commands were not working. I'll dig and report!
OK, the pb remain but is quite different from my exepectation. The exact same expression and the same context works in a second test, but fails in the first test (with the missing parenthesis message). Seems to be a bug in the IDE then, or a corruption of some sort of the Selenium script...
Consider a simple F# console application that echoes the command line arguments passed to it, one command per line:
[<EntryPoint>]
let main argv =
argv |> Array.iter (printfn "%s")
0
If I pass this program a directory path with a trailing slash, it treats the slash as an escape character producing unexpected results:
> app.exe "c:\some path\" "c:\another path"
c:\some path" c:\another
path
How can I retrieve the command line arguments without interpreting a slash as an escape character?
System.Environment.CommandLine gives you access to the complete unescaped command line, and you are free to process that however you like.
But unless you plan to implement a full-blown parser in your app, this is not going to be a reliable approach, and it's unlikely you will be able to reliably handle all of the byzantine escaping rules implemented by all of the various shells your app might have been invoked in. e.g. cmd.exe escapes things differently from powershell.exe, which is in turn different from Cygwin, etc etc.
A better choice is to simply take argv as-is, validate it as you see fit (e.g. File.Exists(argv.[0]) or whatever), and bail out with a helpful error message if the user messed something up.
I am using NtQueryInformationProcess() to retrieve the command line of another process (via the RTL_USER_PROCESS_PARAMETERS in the PEB returned by NtQueryInformationProcess()) on Windows 7.
This generally works fine, but when multiple instances of the same executable are started the command line string is the same for all instances: it always is the command line of the first instance that was started. GetCommandLine() returns the correct command line for each process though.
Can someone confirm or falsify this?
What you are probably missing is that each pointer in PEB is only relevant in address space of the PEB's process rather than the process that called NtQueryInformationProcess and retrieved the PEB. You have to use ReadProcessMemory to derference pointers. Otherwise, since processes are likely to be laid out similarly, you end up reading the command line of the NtQueryInformationProcess caller and not that of the PEB's process.
I can confirm that Using NtQueryInformationProcess and ReadProcessMemory for each level of pointer indirection you can get command lines of all processes correctly. See https://stackoverflow.com/a/13408150/1236546 for source code example.