I'm trying to learn how to write a Firefox plugin.
I downloaded the npruntime example from Mozilla compiled it and ran it.
Getting properties from the plugin worked well but when I tried to
call a method, Firefox freezed.
I thought maybe something is wrong with the example, so I wrote my own basic scriptable plugin that has one property and one method which returns a string.
The property worked well, but calling the method caused Firefox to freeze, again.
Am I missing something?
I tried debugging the plugin and everything seems fine. All the right
functions are called and the value is returned properly.If I try to stop the process while Firefox hangs, I get stopped at a Windows DLL, not in my code and not in Firefox code.
If anyone can point me to the right direction...
Thanks.
I hope that you've got it solved. If this is not the case, I've just discovered that the example (I assume that was the damned "npruntime sample") was flawed.
In returning a string, the example used the function strdup to allocate a string passed with a NP_something method.
Fact is that NPAPI takes care of the allocated string from that point on and, when tries to destroy it, it cannot since strdup uses malloc and not NPN_MemAlloc.
The solution is to NEVER use malloc or new for objects that we pass to NPAPI functions.
In the npruntime sample the error is at line 452:
STRINGZ_TO_NPVARIANT(strdup("foo return val"), *result);
and line 466:
STRINGZ_TO_NPVARIANT(strdup("default method return val"), *result);
I've corrected it with this code:
char* src = "foo return val";
char* out = (char *)NPN_MemAlloc(strlen(src) + 1);
strcpy(out, src);
STRINGZ_TO_NPVARIANT(out, *result);
and it worked.
But one would think that such a flaw in a sample should be corrected by mozilla SDK maintainers.
I developed npruntime for every browser.
It worked well in every browser, but firefox got freezing only in Windows 7.
I solved the problem editing the firefox config "dom.ipc.plugins.enabled" to false.
I don't know it will work, but it deserves to try.
Related
I'm currently (trying) to develop an app with Worklight Studio 5.0.6 and Dojo (Mobile) 1.8.3. I have a really hard time to to find a proper method for debugging. After waiting 5-10 minutes for the build an deploy-process on the server, an error usually looks like this in the Chrome debugger:
How am I supposed to track down this error in MY source? The whole stack trace consists entirely of Dojo code which generates an absolutely useless error message after 20 abstraction layers.
Seriously, how do you guys handle this in real life? What methods do you use for debugging Dojo-driven apps in the browser?
spyro
For dojo.parse errors, I find it useful to pause the Chrome debugger on all exceptions (the purple icon on your screenshot, should be blue). You usally get more details about the cause of the error, the name of the DOM node being parsed, etc. in the first exception being raised.
Rémi.
Debugging dojo based application should be the same as debugging any javascript application.
Usually I will follow these steps:
add console.log() somewhere in code: this is fast and most of time this is enough.
set breakpoint in debugger: if step 1 is not enough, you can base on error information to set breakpoint before error line, then step in or step out.
comment out recently changes: for some error which is hard to find the error line, for example, parse error in your case, the good way is comment out your recently changes one by one till back to your last working version. Or, return to your last working version, then add code back one by one.
Create a simple application to reproduce the error : if your application is very complicate and it is hard for you to follow above methods, you can try to create a new application which mimics your current application but with simple logics and try to reproduce the error.
Based on experience : Some errors, for example, extra ',' in the end of array which works at chrome and firefox, will report a nonsense error information at IE. Debug these kinds of errors is very difficult, you can base on your experience or do a google search.
Did you provide isDebug: true in your dojoConfig? Also, try to see if the same occurs in other browsers.
Update: I recently discovered that there are issues with Google Chrome and Dojo debugging and I think it has to do with the asynchronous loading of files. As you can see in the provided screenshot of #spyro, the ReferenceError object is blank (which you can notice because of the empty brackets {}). If you want to solve that, reopen the console of Google Chrome, (for example by tapping F12 twice). After reopening the ReferenceError should not be empty anymore and now you can expand that object by using the arrow next to it and get a more detailed message about what failed.
Usually what I do in situations like that is to place a breakpoint inside the error callback (line 3398 in your case) and then look into the error variable ("e").
I am not sure how familiar you are with the Web Inspector, but once you hit the breakpoint open the Web Inspector 'console' and check for the error properties "e.message" and "e.stack" (just type in "e.message " in the console).
Also, during development it is better to avoid Dojo optimization / minification, which greatly improve your debug-ability.
Bottom line is to try to place the breakpoint before the error is thrown.
I've tried to run my tests with Selenium 2 and Firefox 19. One of this tests causes an error "ERROR: Command execution failure. The error message is: can't access dead object".
I'm reading about it, it seems like a bug in newest Firefox's versions. Lot of people have the same issue, but I've not found anything really clear.
Any heroe can help us? Maybe we just need to change something in "about:config"?
Regards
I was desperate about the same Problem and didn't find any solution although many people seemed to have the same problem.
I solved it by calling
webDriver.switchTo().defaultContent();
before calling any findElement method
(using Java)
This error generally comes when you do no switch back from frame and trying to access web elements directly.
Use driver.switchTo().defaultContent(); and then try to access the elements
I finally made a "cheat" to the browser.
I got the fail when Selenium clicked on a link and try to open the new page. What I've made is just simulate the click, doing a selenium.open("URL") which replace selenium.click("link=ButtonWhichOpenTheURL").
It seems to work by the moment
I am facing the same error on Firefox 23 while reopening a pop up browser window. The only workaround I did is closing the current selenium session and relaunching it again. It worked fine for me.
When trying to restore a version of a document in my document based application, I get an error:
kCGErrorFailure: CGSDisplayID: App trying to enumerate [0 to CGSGetNumberOfDisplays()] instead of using CGSGetDisplayList(). Compensating...
kCGErrorFailure: Set a breakpoint # CGErrorBreakpoint() to catch errors as they are logged.
and the document remains unchanged. Also, when this happens, I get a message as soon as I start editing the document telling me:
The document [...] could not be autosaved. The file has been changed by another application.
I think these two problems may be related.
I don't know what to do or "check" because versions just works without any implementation needed; I'm actually confused, because Apple says that I just need to enable autosave in order to restore/revert using versions. Does anyone know what can be causing that error?
Thanks.
I've ran into all of your issues, causing me much pain.
I've gotten that error message regarding kCGErrorFailure... before as well when browsing versions. I've just ignored it mostly as it seems harmless to me. TextEdit seems to spit out this message as well. (Looks like an Apple bug)
For the "document remains unchanged", check here: Restoring from versions browser on OSX lion not working... ideas? (in short, your code for updating your document's UI is probably not being called for the document that is being reverted) (Looks undocumented to me)
For autosaving issues, check here: http://www.cocoabuilder.com/archive/cocoa/306217-how-to-implement-autosaving-browsing-versions-reverting-to-last-saved-in-lion.html (in short, use the file wrapper methods instead for reading and writing). (Looks like an Apple bug)
As well as returning YES to autosavesInPlace: your document needs to at least call updateChangeCount: passing NSChangeDone whenever it changes, so that it "knows" that there are changes to be autosaved.
Since I upgraded from Xcode 3.2.3 to 3.2.4 and iOS 4.0.1 to iOS 4.1 SDK, when I set a breakpoint in my code and single-step over instructions, at each step, the debugger will spit one or more of that line:
Assertion failed: (cls), function getName, file /SourceCache/objc4_Sim/objc4-427.1.1/runtime/objc-runtime-new.m, line 3939
It doesn't happen on a specific line or for a specific instructions. I have a few breakpoints in my code and each time I hit one of those, the debugger starts spewing those messages. It doesn't seem to have any detrimental effect as the program works correctly. It's just very annoying to retrieve the information in the console when there are tens of those lines. I'm sure they're not displayed for nothing but I haven't found what the problem might be and what instruction might cause it. If I don't hit a breakpoint, then I don't see any of those lines. I did clean and rebuild my project multiple times to no avail.
Does anybody have any idea what this is?
I ran into this - and here's the reason mine happened: I had used
+localizedStringFromDate:dateStyle:timeStyle: in my code. Worked fine on the iPhone, but it's not available pre-4.0 SDK, so it coughed on the iPad. See if you're calling some routine that's either no longer available in the SDK, or available only in later versions. Frankly, I can't wait for 4.1 on the iPad!
-Owen
I'm also having this problem, in an iPad app originally written in Xcode 3.2.4 using the iOS 3.2 SDK, now being debugged in Xcode 3.2.5 using the 4.2 SDK, but only when I set the simulator to the 3.2 iOS Deployment Target (so I can run in the 3.2 simulator). Every stop at a breakpoint in the debugger, I get this assert repeated eight times. Single-stepping over a line gets two more.
What I can't understand is I haven't added any code to the project since I last run it in Xcode 3.2.4 and iOS SDK 3.2, so I can't have added any calls that were not present in that SDK or else it wouldn't have compiled.
Until someone finds an answer to this, I think the only workaround (so I can continue debugging my code in a 3.2 environment) is to reinstall Xcode 3.2.4 and use the 3.2 SDK and simulator.
I had this problem when I was running on simulator "iPad 3.2 simulator". This problem disappeared when I switched the simulator to "iPad 4.3 simulator"
I have exactly the same issue. I know it's not the complete answer but here's what I could find.
The relevant function getName looks like this:
/***********************************************************************
* getName
* fixme
* Locking: runtimeLock must be held by the caller
**********************************************************************/
static const char *
getName(struct class_t *cls)
{
// fixme hack rwlock_assert_writing(&runtimeLock);
assert(cls);
if (isRealized(cls)) {
return cls->data->ro->name;
} else {
return ((const struct class_ro_t *)cls->data)->name;
}
}
So gdb is complaining that the assertion assert(cls) is failing. Which means that getName somehow gets a NULL pointer as an argument.
Which is kinda funny, where could we be asking for the name of a NULL class?
Hope this helps...
I also have the same problem; I don't have a solution but I'm able to work around it. In short, I suggest you add more breakpoints...
I noticed in the call stack that it's actually the debugger that is misbehaving. The function gdb_class_getClass calls getName, presumedly this is passing NULL instead of (say) MyClass. The code that I'm trying to debug is a method of MyClass. So, thinking that the debugger has a problem with MyClass, I set a breakpoint at a line outside of any code of MyClass (ie the line that calls the method on MyClass) and hit continue when the program breaks. This seems to resolve the problem in my case. (Note that auto-continue doesn't work.)
To be clear:
//Set breakpoint here
[myClassInstance buggyMethod];
My buggyMethod is actually in another file:
...
-(void)buggyMethod {
//This is where I set my 'real' breakpoint
Hope that helps.
I'm having a similar problem, but mine is with creating a custom view with Core Text in it. As soon as my view's drawRect calls the line
CTFontRef titleFont = CTFontCreateWithName(CFSTR("Baskerville"), 40.0f, NULL);
It hangs the app, whether in the simulator or on the device. Bizarrely, I can rectify this by alloc-initing another UIKit text component in the View Controller's viewDidLoad method... I don't even have to add it as a subview. It's like it needs some common text elements loaded before Core Text can load in fonts.
- (void)viewDidLoad
{
[super viewDidLoad];
UILabel *l = [[UILabel alloc] initWithFrame:CGRectMake(0, 0, 0, 0)];
}
Weird.
I cannot open a new window in QT. I new in QT so I think I am missing something. I only write the code below and settings windows just shows itself and closes. I have commented out destructor but still problem persists.
SettingsWindow s;
s.show();
What do I do wrong ? By the way I cannot either debug it, debuger does not stop when it reaches to the first line for example.
Thanks
This can't possibly be the only code you wrote.
However, judging from your description the first thing that comes to mind is probably a missing call to QApplication::exec(). Somewhere in the code you haven't shown here there's an instance of QApplication, probably named app. After calling show on your window, make sure there's a call to exec.
Since you are using a non-pointer var, your window is destroy when it go our of scope (at the end of the function). If you use a pointer when exiting the function the memory is not deleted so you Windows will still be shown. But you will not be able to clean memory when closing the window if you can't anymore access to your pointer.
Maybe you need to create your window as member of the calling class in order to be able to destroy the window AND clean memory once you don't need anymore to display it (for example in the calling class destructor).