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.
Related
So, I've been working on a project in AS3 and I've come across yet another peculiar bit of behavior.
Background: It's a turned based game. I've been optimizing it for the past week and now it runs like butter (consistently!);
Issue: However, when I try to continue playing from a saved game, it runs less consistently. Specifically, it will run the first few turns normally, then it will begin to degrade in performance dramatically until it freezes my computer. Please note, this only happens during battle, not during the menus or during any other time.
Is there something regarding Actionscript that I'm missing? I'm saving the game with cookies using the built in SharedObject class. The code I'm using to save and load the data is below (I also use the byte array class).
public static function saveGame():void
{
/// save the game using byte array
registerClassAlias("Mob", Mob);
registerClassAlias("Skill", Skill);
var ba:ByteArray = new ByteArray();
var savedData:* = Main.glblPlayer.setSaveObject();
ba.writeObject(savedData);
ba.position = 0;
so.data.game5 = ba;
so.flush();
}
public static function loadGame():Boolean
{
if (so.data.hasOwnProperty("game5"))
{
var ba:ByteArray = new ByteArray();
ba = so.data.game5;
ba.position = 0;
var loadedData:Object = ba.readObject();
glblPlayer.loadSaveObject( loadedData );
return true;
}
else
{
so.data.game = new Object();
return false;
}
}
I just double checked the above code and tested it a bit more with some variation. If it's loaded 1-3 times, it's fine, but after that the performance degrades during battle with each turn. I have no idea how the technical stuff of ActionScript works or how it saves resources aside from that it's cookies and it's in the cache.
Can anyone shed some light on this by maybe going a bit more into how saving/loading with flash games are done in AS3? Or is "use sharedObject" all there is?
Use a profiler (like Adobe scout) to see what causes the problem.
If I had to guess, it's because your (de-)serialisation routines do not work properly and have a memory leak. But again arguing about this or looking at the code wondering what might be the problem is a pointless endeavour. Use a profiler to see exactly what the problem is.
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.
private function rewriteQueue():void
{
try{
var file:File = File.applicationStorageDirectory.resolvePath( DATA_FILE_NAME );
file.deleteFile();
while (users.length) {
var aUser:Object = users.shift();
writeUser(aUser);
}
}catch (e:Error) {
}
}
In the above the while loop doesn't appear to execute. When I call the function in testing I have one item in the users array and it should be written to the file just deleted within the while, by calling writeUser(). However, once this is finished and I try and read the user from the file I can't - it's empty.
By placing the while outside the try/catch block it works fine.
I'm just wanting to know why.
EDIT: OK, I figured it out. The problem occurred when the file that was trying to be deleted didn't exist. That caused an error in deleteFile() - causing the while to not execute. Yeesh.
I know you already figured it out but for the sake of the community, please give the solution as an accepted answer in future so anyone browsing the site can tell if it's answered or not (this helps both experts and learners). The practice of answering your own questions is actually promoted quite strongly in the FAQ's.
The problem occurred when the file that was trying to be deleted
didn't exist. That caused an error in deleteFile() - causing the
while to not execute.
Also, the comment by LDMS is very valid. You shouldn't rely on Flash Professional's debug to tell you what's going on, using trace() can help a whole lot more.
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..