I am developing a concurrent BLE and Shockburst application on the nRF51 DK. First I tried to run Shockbust alone. It compiled and it was no problam to load it on the board. But when I run it, it doesn't work. I think I found the mistake, but I don't know how to solve it:
The nrf_esb_init() function doesn't return. I surrounded the function with LEDs for testing. LED_1 lights on, so the function is called, but LED_2 never flash:
void esb_wake(void) {
nrf_gpio_pin_toggle(LED_1); // flash
nrf_esb_init(NRF_ESB_MODE_PTX);
nrf_gpio_pin_toggle(LED_2); //does not flash
nrf_esb_set_base_address_0(addr0);
nrf_esb_set_base_address_1(addr1);
nrf_esb_set_channel(rf_channel);
uint32_t err_code = timeslot_sd_init();
APP_ERROR_CHECK(err_code);
nrf_esb_enable();
nrf_esb_set_max_number_of_tx_attempts(1);
}
I use the SDK 10.0 and Softdevice s310.
Anybody an idea how to solve my problem?
I was able to solve the problem by my own:
As I said I use a softdevice and that is the evil. The softdevice is "the master of the board". ShockBurst is not part of the softdevice. So I had to tell the softdevice when I use some external code. The solution is to call nrf_esb_init() not before a timeslot starts. So I moved the function into my timeslot event handler in the NRF_RADIO_CALLBACK_SIGNAL_TYPE_START case.
Related
when I reverse the binary with IDA gui, all the functions get decompiled without a problem.
but when I am running an automatic script on ida without gui, there is always the same function, that refuses to be decompiled. (when I am openning the same IDB that the automation script worked on, the function get decompiled without a problem)
I am using bip. and using BipFunc.can_decompile to check if a function can get decompiled.
EDIT:
according to an answer bellow, I have tried to add the following:
if not func.can_decompile:
print(f"can't decompile function 0x{func.ea:04x}, trying again")
decomp_all()
if not func.can_decompile:
print(f"can't decompile function 0x{func.ea:04x}, trying again")
decomp_all_twice_cacheclear()
if not func.can_decompile:
print(f"can't decompile function 0x{func.ea:04x}, skipping...")
return
sadly it did not work, I get all 3 prints every time, even on different binaries
it seems to be fixed on IDA Pro 7.6
There is several reason you can get an error on the decompilation from IDA. If it works on some case and other it does not it is probably because of the call analysis. When decompiling a function IDA will try to gather information on the function called by this one and in some case fail to get those information which will make the decompilation fail. But once that function has been decompiled, the information fetched by IDA will be updated, and so the decompilation of the caller function might now work. So basically it means you have to decompile the function in an order, which is a pain, for fixing that the simplest way is to just decompile everything twice, but it can take quite some time if you do it on "big" binaries.
I though I put that in the Bip repository somewhere but I can't find it, so here is a small plugin/code which should allows to do that:
from bip import *
class DecompileAll(BipPlugin):
"""
Plugin for decompiling all the function in the binary.
"""
#menu("Bip/DecompileAll/", "Invalidate hexrays caches")
def clear_hxcCache(self):
HxCFunc.invalidate_all_caches()
#menu("Bip/DecompileAll/", "Decompile all func")
def decomp_all(self):
count = 0
for f in HxCFunc.iter_all():
count += 1
print("0x{:X} functions decompiled".format(count))
#menu("Bip/DecompileAll/", "Decompile twice with cache clear")
def decomp_all_twice_cacheclear(self):
HxCFunc.invalidate_all_caches()
self.decomp_all()
self.decomp_all()
Just for information the basic reason for decompilation error, is that it is not able to make a correct translation of some piece of code because it does not understand the assembly, this is typically true if there is a problem during the analysis and the code is not correctly detected (also happens a lot if you are dealing with obfuscation). You can typically view this case by an error telling you "failed analysis at ADDR" in the IDAPython console, and then look at the problem. Probably not your case but might still help.
Glad to hear you are using bip. So about the BipFunc.can_decompile function: like indicated in the documentation (https://synacktiv.github.io/bip/build/html/base/func.html#bip.base.BipFunction.can_decompile) it will just try to decompile the function and see if an error occurs. The code is pretty straight forward (https://github.com/synacktiv/bip/blob/master/bip/base/func.py#L372), this is mostly written for being done while using one-liner, its the same thing as catching the exception when trying to decompile.
I was working on my flash project, which compiled the whole time just fine.
Then I did some changes, then, when testing the project, the project compiles,
the flash player comes up, showing the first frame, but no code executes.
No single trace output. Nothing. No Errors, No Warnings, very strange!!!
Can anybody help me???
You might have stumbled over a BUG in the FlashIDE/Flex Compiler.
Try this snippet and wonder:
// ------ Put in first frame of a fresh flash file
trace ("why won't i execute");
var dummy=function(a:int){
a:int = 0;
}
Instead of catching your coding mistake:
a:int = 0; should eihter be var a:int = 0; or a=0;
the compiler chokes, and dies, without even having the time to let you know.
Beware!
This mistake can be deeply hidden in some, over many intermediate classes imported, class.
So, to answer your question, look at the things you have changed, you might have changed a local var to be given as a function argument, took away the local var but forgot to remove the :type part as well.
Why this works on flash professional's debugger, but brings null on the compiled SWF?
var firstParameter:SomeObject = new SomeObject();
someLoader = new Loader();
someLoader.contentLoaderInfo.addEventListener(
Event.COMPLETE
, function(evt) {
onLoaded(evt, firstParameter);
}
, false
);
function onLoaded (evt:Event, param:SomeObject):void {
mcOnSceneForTracing.text = param; // this is used for SWF debugging
}
For the record:
To make it work without any issues this can be "solved" by creating a separate scope. However, here I'm wondering why, then, this example even works on the debugger at least.
And, please, if you have a better way other than using two anonymous functions to pass parameters, variables, values, whatever through an Event, do tell! I'm not willing to extend the Event, tho. Too 2005.
mcOnSceneForTracing is what I'm using to "trace" outside the debugger. Suggestions are also accepted here for better (and simpler) ways to do it! I've heard Vizzy is good, but haven't tried it yet.
My guess would be: When loading your resource from the debugger player, the operation finishes instantly, and thus firstParameter is available when your anonymous listener function is called, but when running the swf elsewhere, the load operation takes longer, and then the reference to firstParameter is lost, since it is a local variable.
I'm really struggling to resolve a stack underflow that I'm getting. The traceback I get at runtime is:
VerifyError: Error #1024: Stack underflow occurred.
at flash.events::EventDispatcher/dispatchEventFunction()
at flash.events::EventDispatcher/dispatchEvent()
at flash.net::URLLoader/onComplete()
This is particularly difficult to debug because when I run in debug mode it does not happen at all. It only happens when compiled as a release.
Does anyone have any tips on how to debug a Stack Underflow? Are have a clean explanation of what that means for Flash?
In case it helps, this error is occurring when I click a button whose handler makes an RPC call, which uses a URLLoader, an AsyncToken, and then invokes the set of AsyncResponder instances associated with the AsyncToken. With some server-side logging as well as some logging hacked into the swf, I know that the UrlLoader is successfully doing and GET'ing a crossdomain.xml file, is correctly processing it (ie: if I wreck it, I get a security error), and is also successfully completing the "load" request (the server sends the data). The underflow seems to be happening in the Event.COMPLETE listening/handling process (as is, of course, implied by the traceback as well).
mxmlc used = from flex_sdk_4.5.0.20967
Example player (I've tried a few) = 10.2.153.1
UPDATE: My specific problem is solved... but I'm leaving the question as-is since I would like to know how to generally debug such a problem, rather than just getting my specific solution.
In my code I had the following Application definition:
<s:Application height="100%" width="100%"
xmlns:fx="http://ns.adobe.com/mxml/2009"
xmlns:s="library://ns.adobe.com/flex/spark"
xmlns:mx="library://ns.adobe.com/flex/mx"
initialize="InitData();">
Note that the code is/was attached to the initialize event.
InitData() and relevant defintions are/were:
import classes.RpcServerProxy;
public var SP:RpcServerProxy;
public function InitData():void {
SP = new RpcServerProxy("http://192.168.1.102:1234");
}
When I switched the InitData() call to be on the onCompletion event instead of initialize (thanks J_A_X!), the problem goes away entirely. What seems to have been happening was that the Event.COMPLETE event handler (onComplete in the stack trace) was using the global SP object. Something about the release (vs debug) compilation must have been affecting the startup timing of the SP variable initialization. Moving the handler later to the onCompletion event resolved all issues.
As said above, I would still like to know what tricks/tools are available for debugging initialization issues like this.
UPDATE 2:
applicationComplete seems to be an even better event than creationComplete to put application initialization code. See this blog entry for some explanation, and and this video (around 4:25) by an Adobe Tech Evangelist for an example of simple "start of application" data initialization.
I got rid of this error by adding compiler argument:
-omit-trace-statements=false
Stack underflow basically means the compiler messed up.
You can use SWFWire Inspector to look at the bytecode of the event handler, if you want to know exactly how it messed up. You can also use SWFWire Debugger to see which methods were called, but in this case, you already knew where it was happening.
If you post the broken swf, I can give you more info.
Sean is right that to debug it you can look at the byte code, but that didn't sound appealing to me.
Based on my experience and research, it is often due to the presence of a trace statement that incorrectly gets compiled out in release mode, and generates invalid byte code. So, I would say to "debug" it, "Look for places where you are using trace. Try commenting them all out in the offending function and see if the issue goes away."
In my case, it was a trace statement as the first line of a catch block:
catch (e:TypeError) {
trace(e.getStackTrace()); //This line is the problem
throw new Error("Unexpected type encountered");
}
I found someone else with this exact issue here.
This code also leads to stack underflow only in release mode (flag -debug=false):
true && trace('123');
mxlmc flex sdk version 4.5.0.20967, flashplayer version 10.3.181.14 (linux).
Check your code for similar expressions.
This code caused me issues when I compiled a release candidate from flash builder 4.5
public function set configVO( value:PopupConfigVO ):void
{trace("CHANGING")
Resolved by inserting a space between the the trace and curly brace
public function set configVO( value:PopupConfigVO ):void
{ trace("CHANGING")
Hope this helps.
For people looking for the same problem, I just got this caused by a trace statement in the 'default' case of a switch statement. Commented out the trace, stack underflow resolved.
Interesting... I was getting this error with a SWF that I'd pulled off the web, an Away3D based graphics demo. At the time I was running this on the Tamarin VM rather than the actual Flash/AIR runtimes, so could stick a breakpoint on the "verifyFailed(kStackUnderflowError)" line and see what was happening.
The -Dverbose flag also helped find the culprit:
typecheck MethodInfo-1480()
outer-scope = [global]
[Object~ Object] {} ()
0:pop
VERIFY FAILED: Error #1024: Stack underflow occurred.
And looking at the ABC using SWFInvestigator, I found this:
var function(Object):void /* disp_id=0 method_id=1480 nameIndex = 0 */
{
// local_count=2 max_scope=0 max_stack=0 code_len=2
// method position=52968 code position=155063
0 pop
1 returnvoid
}
So there is an obvious issue where the 'trace' has been removed but the compiler has put a 'pop' in there: I wouldn't have thought this was needed as a trace call should presumably have been made via 'callpropvoid'?
Quite why this doesn't fail on AIR/Flash I don't know..
Anyway: looks to me like an ASC compiler problem i.e perhaps one of the ActionScript3 compilers had a fault with this - hence the workarounds that have been mentioned so far.
It's quite simple, and it doesn't have anything to do with spaces before or after brackets, trace commands or whatever else: it's just 1 really simple thingy:
DO NOT LOOP EMPTY!
Meaning, while developing, we all //comment some lines sometimes, and when that results in
for (...) {
// skip for now
}
the compiler gets :
for(...){}
and that my good friends, is something the compiler doesn't like!
so, NO empty loops, and you're on your way again...
Happy hunting,
P.
I had the exact same problem, but in my case the cause of the problem was a trace statement in a place where the compiler didn't expect it to find it, right after a package declaration at the beginning of the class:
package utils
{
trace ("trace something here");
And that's why compiling in debug mode removed the problem.
I have a (rather large) application that I have written in C++ and until recently it has been running fine outside of visual studio from the release build. However, now, whenever I run it it says "Unhandled exception at 0x77cf205b in myprog.exe: 0xC0000005: Access violation writing location 0x45000200.", and leads me to "crtexe.c" at line 582 ("mainret = main(argc, argv, envp);") if I attempt to debug it. Note that this problem never shows if I run my debug executable outside of visual studio, or if I run my debug or release build within visual studio. It only happens when running the release build outside of visual studio.
I have been through and put plenty of printfs and a couple of while(1)s in it to see when it actually crashed, and found that the access violation occurs at exactly the point that the value is returned from the function (I'm returning a pointer to an object). I don't fully understand why I would get an access violation at the point it returns, and it doesn't seem to matter what I'm returning as it still occurs when I return 0.
The point it started crashing was when I added a function which does a lot of reading from a file using ifstream. I am opening the stream every time I attempt to read a new file and close it when I finish reading it.
If I keep attempting to run it, it will run once in about 20 tries. It seems a lot more reliable if I run it off my pen drive (it seems to crash the first 3 or 4 times then run fine after that - maybe it's due to its slower read speed).
Thanks for your help, and if I've missed anything let me know.
EDIT: New info
Well I removed the entirity of the function and replaced it with:
IndexedMesh * loadObj(char * objName)
{
ifstream fp_in;
fp_in.open("lol.bmp", ios::in);
fp_in.clear();
fp_in.close();
IndexedMesh * mesh = new IndexedMesh();
printf("finished");
return mesh;
}
I also tried it with "return 0" and "return new IndexedMesh()". It's all fine until you put the ifstream stuff in. I do have 2 other ifstreams open in different functions (accessing completely different files). Could this be the problem?
It actually errors on the return mesh line, (I got the debugger working with the separate release file). It completely nulls the mesh object when it attempts to return it.
The point it started crashing was when I added a function which does a lot of reading from a file using ifstream. I am opening the stream every time I attempt to read a new file and close it when I finish reading it.
Given your description of the code only failing in release mode outside the debugger I'd examine this function for any unset variables. Compiling debug sets variables (or at least it used to) as did running release code in the debugger.
You are probably running over something stored deep in the stack.
I'll bet that if you were to put this at near the top of your code:
int my_main(int argc, char * argv[], char * envp[]);
int main(int argc, char * argv[], char * envp) {
char ** a;
char ** e;
a = malloc(argc+1); // note: you should test the results for NULL
e = malloc(1+count(envp) ) ;// I'm not writing code to count it, but it's easy
int i = 0;
while (argv[i++]) {
a[i] = strdup(argv[i]);
}
a[i] = argv[i]; // argv[i] is NULL and already in a register
// do the same thing for envp
return my_main(argc, a, e);
}
#define main my_main
then whatever it is that is smashing your stack would instead end up smashing this duplicated environment. It's not garenteed, and it is no fix for your problem, but not that difficult.
Thanks very much for your help, I haven't exactly solved the problem but I have managed to evade it. Basically, if I even mentioned an ifsteam (in that function and that function only), the program crashed.
I actually went as far as altering the function to simply declare an ifstream then return 0. I "fixed" it by declaring the ifstreams as pointers and new-ing them. If I deleted the pointer it crashed out again so I had to set it to 0 (leeeeak).
If anyone could enlighten me as to why this occurs, that would be great. While I'm just happy it works now, I'd rather know why..