In one of my tests, written in ECL with RCPTT, I need to check the value of a register. To do so I check the value shown in the registers view
The problem is that the register I'm looking for is far in the list. And the debugger load the value dynamically, when scrolling the list.
57-data-list-register-values --thread 1 --frame 0 x 15
57^done,register-values=[{number="15",value="0x0"}]
(gdb)
58-data-list-register-values --thread 1 --frame 0 N 15
58^done,register-values=[{number="15",value="0"}]
So in order to check the value of my register, I need to force a scrolling to force the debugger to load the value. So here's my question : how can I make the test scroll the view ?
If I don't do this, the execution fail when I try to select the register using this:
get-view Registers | get-tree | get-item "General Registers/MY_REGISTER"
It throws me:
Failed to set selection: [[General Registers, MY_REGISTER]].
I've tried to use expand-all to force the discovery but it didn't worked.
Related
During testing my iOS app, (it's a workout app), the app crashed (EXC_BREAKPOINT) as it was trying to save the workout data.
The crash was an index out of range issue whereby the array count is 1 lesser than the workout seconds. (I should have started the seconds counter from 1 instead of 0)
for i in 0...seconds {
let data = "\(i),\(dataArray.powerGenY[i-1]),\(dataArray.powerGenYAlt[i-1])\n"
do {
try data.appendToURL(fileURL: fileURL)
}
catch {
print("Could not write data to file")
}
}
anyways, the error dropped me to LLDB. Is there any way I an Use LLDB to bypass this error and continue execution?
Having worked out for a hour, I wasn't prepared to have this crash take my data along with it. Since the crashed dropped me into LLDB, I wanted to see if there's any way to salvage the data by stepping over / bypassing / changing the value of i so that the program execution can continue.
Initially I tried
(lldb) po i = 3327
error: <EXPR>:3:1: error: cannot assign to value: 'i' is immutable
i = 3327
^
but it won't let me change the value (I is immutable)
Then I tried thread jump -l 1 but it spewed some error about not the code execution outside of current function.
(lldb) th j -l 29
error: CSVExport.swift:29 is outside the current function.
Finally, going thru this site https://www.inovex.de/blog/lldb-patch-your-code-with-breakpoints/ and trying a few things. The one that helped was thread jump
thread return
The mentioned disadvantage of thread jump can be avoided by using a
different technique to change control flow behaviour. Instead of
manipulating the affected lines of code directly the idea is to
manipulate other parts of the program which in turn results in the
desired behaviour. For the given example this means changing the
return value of can_pass() from 0 to 1. Which, of course, can be done
through LLDB. The command to use is thread just like before, but this
time with the subcommand return to prematurely return from a stack
frame, thereby short-circuiting its execution.
Executing thread return 1 did the trick. This returned true (1) to the index out of range issue and then continued the execution to the next line of code.
I call gtk_window_is_active(wnd) and always receive 0, even when I know for sure that wnd is active and receiving keyboard input. What is the cause and where is the remedy for this?
In fact, I run gtk_window_list_toplevels() and iterate over the list - and gtk_window_is_active() returns 0 for each of them!
When you create a GtkWindow it is still in the 'unrealized' state. You have to call show() on it and let the main loop run, then the window gets realized. So if you call gtk_window_is_active after creating the windows, but before the main loop has chances to run, you will get false.
Thanks to Emmanuele Bassi, Gnome Foundation staff, I figured it out: the problem is that my focus-in-event handler returned 1 (TRUE), and thus prevented the default GTK behaviour. It turned out (something not obvious) that keeping track of the active window is part of that default behavior that i unknowingly overrode.
So, I changed focus-in-event handler of my windows to return FALSE (0), and ever since gtk_window_is_active() works like a clock.
I came to realize an unhelpful (to my task) detail: gtk_window_is_active() only works AFTER all focus-in-event handlers have completed working. Well, I have a mouse click handler that activates some other window, and then needs to check if a certain window is active (these things belong to different objects and different modules, yet are executed within one click hadler invocation). In my case gtk_window_is_active() is useless: it returs FALSE for the active window until after my click handler has finished and the focus-in-handlers (mine and the default) have finished, too.
I'm working on project on STM32L152RCT6, where i have to build a mechanism to self update the code from the newly gated file(HEX file).
For that i have implemented such mechanism like boot loader where it checks for the new firmware if there it it has to cross verify and if found valid it has to store on "Application location".
I'm taking following steps.
Boot loader address = 0x08000000
Application address = 0x08008000
Somewhere on specified location it has to check for new file through Boot loader program.
If found valid it has to be copy all the HEX on location(as per the guide).
Than running the application code through jump on that location.
Now problem comes from step 5, all the above steps I've done even storing of data has been done properly(verify in STM32 utility), but when i'm jump to the application code it won't work.
Is there i have to cross check or something i'm missing?
Unlike other ARM controllers that directly jump to address 0 at reset, the Cortex-M series takes the start address from a vector table. If the program is loaded directly (without a bootloader), the vector table is at the start of the binary (loaded or mapped to address 0). First entry at offset 0 is the initial value of the stack pointer, second entry at address 4 is called the reset vector, it contains the address of the first instruction to be executed.
Programs loaded with a bootloader usually preserve this arrangement, and put the vector table at the start of the binary, 0x08008000 in your case. Then the reset vector would be at 0x08008004. But it's your application, you should check where did you put your vector table. Hint: look at the .map file generated by the linker to be sure. If it's indeed at 0x08008000, then you can transfer control to the application reset vector so:
void (*app)(void); // declare a pointer to a function
app = *(void (**)(void))0x08008004; // see below
app(); // invoke the function through the pointer
The complicated cast in the second line converts the physical address to a pointer to a pointer to a function, takes the value pointed to it, which is now a pointer to a function, and assigns it to app.
Then you should manage the switchover to the application vector table. You can do it either in the bootloader or in the application, or divide the steps between them.
Disable all interrupts and stop SysTick. Note that SysTick is not an interrupt, don't call NVIC_DisableIRQ() on it. I'd do this step in the bootloader, so it gets responsible to disable whatever it has enabled.
Assign the new vector table address to SCB->VTOR. Beware that the boilerplate SystemInit() function in system_stm32l1xx.c unconditionally changes SCB->VTOR back to the start of the flash, i.e. to 0x08000000, you should edit it to use the proper offset.
You can load the stack pointer value from the vector table too, but it's tricky to do it properly, and not really necessary, the application can just continue to use the stack that was set up in the bootloader. Just check it to make sure it's reasonable.
Have you changed the application according to the new falsh position?
For example the Vector Table has to be set correctl via
SCB->VTOR = ...
When your bootloader starts the app it has to configure everything back to the reset state as the application may relay on the default reset values. Espessially you need to:
Return values of all hardware registers to its reset values
Switch off all peripheral clocks (do not forget about the SysTick)
Disable all enabled interrupts
Return all clock domains to its reset values.
Set the vector table address
Load the stack pointer from the beginning of the APP vector table.
Call the APP entry point.(vertor table start + 4)
Your app has to be compiled and linked using the custom linker script where the FLASH start point is 0x8008000
for example:
FLASH (rx) : ORIGIN = 0x8000000 + 32K, LENGTH = 512K - 32K
SCB->VTOR = FLASH_BASE | VECT_TAB_OFFSET;
where FLASH_BASE's value must be equal to the address of your IROM's value in KEIL
example:
#define FLASH_BASE 0x08004000
Keil configuration
When I create a new quote from Epicor I would like to add an item from the parts form automatically.
I am trying to do this using the following ABL code which runs when 'GetNewQuoteHed' is called:
run Update.
run GetNewQuoteDtl.
run ChangePartNumMaster("Rod Tube").
ttQuoteDtl.OrderQty = 5.
run Update.
I am getting the error:
Index -1 is either negative or above rows count.
This error occurs for each line in my ABL code.
What am I doing wrong?
That's not the proper format for a 4GL error message (nor is it at all familiar) so I'd say it is an Epicor application message. Epicor support is probably your best bet. However... Just guessing but it sounds like you might need to somehow initialize the thing that you're updating.
Agree with #Tom, but i would also say try and isolate the error and see where the error is raised as soon as you find the point the error is actually raised it is normally much easier to figure out exactly what is going wrong and how to solve it.
Working between a 0 based and a 1 based system there can be issues with the 1st or last entry depending on which way you moving. As the index for 0 based systems starts at 0 and ends at n-1 where 1 based systems start at 1 and end at n.
I'm trying to track down who is making an allocation of a certain size, and I tried using the user mode stack trace db (gflags +ust), but due to FPO I can't see the entire stack. So instead I wanted to set a breakpoint on RtlAllocateHeap when it makes the allocation size I'm looking for. The only problem is I can't seem to find out a way to get this to work.
I initially tried using #esi since it looked like the third parameter was being passed using this register, but it doesn't appear that's always the case. So then I tried #ebp-c to give me the third parameter, but that doesn't appear to always work, so I tried #esp+14 and that didn't work either.
No matter what I do I can't seem to find a way to get this to actually fire when I want it to. It seems like this should work, but I'm guessing it is using leaf function optimizations in certain cases which is preventing me from being able to do this.
Anyone have any ideas on how to get this to work.
Heap stack trace:
0:013> !heap -p -a 0c060710
address 0c060710 found in
_HEAP # 1420000
HEAP_ENTRY Size Prev Flags UserPtr UserSize - state
0c0606f8 09c3 0000 [00] 0c060710 04e00 - (busy)
77abb234 ntdll!RtlAllocateHeap+0x00000274
75ee404b ole32!CRetailMalloc_Alloc+0x00000016
76454557 OLEAUT32!APP_DATA::AllocCachedMem+0x00000060
7645476a OLEAUT32!SysAllocStringByteLen+0x0000003d
764547bf OLEAUT32!ErrStringCopyNoNull+0x00000016
764547e3 OLEAUT32!VariantCopy+0x0000007f
Break points tried:
bp ntdll!RtlAllocateHeap "j #esi == 0x4e00 ''; 'gc'"
bp ntdll!RtlAllocateHeap "j poi(#ebp-c) == 0x4e00 ''; 'gc'"
bp ntdll!RtlAllocateHeap "j poi(#esp+14) == 0x4e00 ''; 'gc'"
I think I have tested this:
Break on allocation size == 1303
bp ntdll!RtlAllocateHeap "j(poi(#esp+c) = 0x1303) 'k';'gc'"
Use poi(#esp+c)
At the first instruction of the function, you do not have EBP. So the structure on the stack for cdecl and stdcall is
<return address>
<First arg>
<second arg>
etc.