IRC Log Viewer » #firebreath » 2010-12-10

IRC Nick Time (GMT-7) Message
jshanab 05:12 Morning everyone
jshanab 07:12 I am having a browser crash (all browsers) on windows when I stop or for example press the home button that goes to another page. I know it is my code as the initial JSAPI functions are fine, it is only after I start playing video that even if i stop, crashes the browser. I need to know the shutdown order for firebreath so I can figure out where it is dieing, it traces the destrucor fine
neilg_ 07:12 Using threads in your plugin?
Because those symptoms suggest threads still running while it tries to shutdown
jshanab 07:12 Yup thereads
Were should I kill them
neilg_ 07:12 Then I'd suggest you make sure they stop running before you unload your plugin
Are they members of your plugin class? Probably in the destructor makes sense - otherwise StaticDeinitialize
jshanab 07:12 OK, That is what i am trying to do, the static one is fun, you can't call non static member funcs :-(
neilg_ 07:12 Right, because static means it doesn't have the "this" pointer
jshanab 07:12 But will i have the destructor called for each instance then the static de-init?
neilg_ 07:12 That's how it should work, yes
jshanab 07:12 I watch the thread panel as I step and All the named threads dissapear as i step thru the destruction process. On the last line of the destructor, it goes to 'scaler deleting destructor'
It is not an error yet, just "No Source Code Avail"
If I "Continue" from that point it crashes with the wait for single object error
neilg_ 07:12 Right, because you still have threads running (that probably try and use data from the plugin?)
jshanab 07:12 There are a lot of unnamed "Worker Threads" and one RPC Thread, but they are always there it seems
neilg_ 07:12 They'll be from the browser most likely
jshanab 07:12 So I would expect all the threads I started to be named in VisualStudio, Could the RPC or Workers be threads I need to handle shutdown on?
lloks like it is the RPC thread? VS highlights that one as it greys everything out then provides the error with an unreadable path (too many ...'s)
neilg_ 07:12 So, your plugin. Does your plugin itself create threads? If so, do they stop running before your plugin finishes destructing?
jshanab 07:12 I am stopping them in the destructor
neilg_ 07:12 You shouldn't worry about any other threads
But are they actually stopping?
jshanab 07:12 They dissapear from the thread panel in visual studio. the only ones left that do not say Worker Thread are the thread on the destructor and the RPC thread
Ther is a join, so it should block until the thread actualy exits.
"other" == Worker and RPC ?
neilg_ 07:12 Well, with the symptoms you described the obvious problem would be threads. But if you're seeing all the ones you create going away before the plugin destructs then the other likely problem is memory trampling
That you're writing over memory you don't own
jshanab 07:12 Quite possible :-) I was wondering if the JSAPI thread needs to be shutdown by me in the plugin
neilg_ 07:12 No... But that's another possible problem too - does your JSAPI object try and call into your plugin object (or into those threads?) because that's another likely problem
jshanab 07:12 Yes, it manages the video player and holds the pointer to it
neilg_ 08:12 So what creates (and destroys) the video player?
jshanab 08:12 boost thread stuff
I inherited the code
neilg_ 08:12 Okay. But where in your code is the boost thread code that creates (and destroys) the video player? And how does your JSAPI object get access to the threads?
jshanab 08:12 yeah, I gotta figure this out. There is a threadfunction and the "start" api call creates them and the stop "destroys" them. I need to read up on it a bit, uses swap and bind
But like I said, they disappear fromt the thread list in debug :-)
neilg_ 08:12 Yes, but now you have two different objects that could be interacting with them at the same time
Obviously I don't see your code so there's only so much help I can give
jshanab 08:12 Thanks for the help you have givin!!! this list is full of great people
dicroce 09:12 Has anyone tried to make a detection JS for firebreath plugins?
As usual, I'm having some trouble getting it to work in IE...
It looks like every other browser supports detection by mime type... But not IE....
neilg_ 09:12 What do you mean by detection JS?
You mean trying to see if the plugin is loaded on the page?
dicroce 09:12 A bit of javascript that can detect whether a particular plugin is installed in the browser...
So, you can say "Download here"... or whatever if they haven't installed it...
neilg_ 09:12 Installed in the browser, no, but on the page, yes. That's the only cross-browser way I know that works in any case
We do that already
It's as simple as trying to put the plugin on the page then checking a property (or calling a method) on your plugin using a try...catch block in JavaScript. If you catch an error then the plugin isn't installed
dicroce 09:12 ahh... ok...
neilg_ 09:12 That works in every browser I've tested it on
dicroce 09:12 Do I just check for a property I've added? Or is there a firebreath defined one?
neilg_ 09:12 It's also useful for version checking too - if you have a property or method that returns a version then you can also ask people to download a newer version of your plugin
dicroce 09:12 cool....
neilg_ 09:12 I believe there's already a property you can use in your JSAPI class
As long as you haven't removed it from your constructor!
taxilian 09:12 You can always use valid
It should always return true
dicroce 09:12 I'll probably look at adding a method to return the version number... if it throws, its not installed...
neilg_ 09:12 Right, that's what we did - it's useful for checking whether the plugin is installed or whether the user needs to update
kylehuff 09:12 using trunk from github, I can't seem to build my project on Win32 - it complains about not being able to find 'uint64_t' in variant.h (VS2008) did I miss a step?
taxilian 09:12 I may have forgotten to push
Will check in 10
Driving now
kylehuff 09:12 it's all good, when time allows..
taxilian 09:12 Try include boost/cstdint.h
In variant
kylehuff 09:12 "Cannot open include file: 'boost/cstdint.h': no such file or directory
taxilian 09:12 Meh. There is a file named similarly...
kylehuff 09:12 there is this: ./src/3rdParty/boost/boost/cstdint.hpp
jshanab 09:12 is it normal to put most functionality in the plugin and put a stub in the API that calls the plugin?
The examples show adding a functiona as something that lives entirely inside the JSAPI
scJohn 09:12 What is the best way to pass 50 values from the plugin back to JavaScript using InvokeAsync?
taxilian 09:12 I would probably put them in an array, myself
scJohn 09:12 They are current in an object, can that be passed back to javascript?
taxilian 09:12 kylehuff: yep, that's the one
what kind of object?
scJohn 09:12 class
taxilian 09:12 only certain types can be automatically converted
kylehuff 09:12 taxilian: that was already in variant.h
taxilian 09:12 kylehuff: and it still gave you the error? hmm
guess I did push, then
kylehuff 09:12 taxilian: yes...
taxilian 09:12 why would it not be able to find it? that's really odd
you are not the first to complain of that error, but I can't reproduce it
scJohn: the easiest way would be to either pass a FB::VariantList (which is just a vector<variant>) or a FB::VariantMap (which is a map<string,variant>)
scJohn 09:12 k, thanks, i will look into that.
taxilian 09:12 some day we will complete our master plan to make it possible to register conversion routines for different types to javascript objects
that day has not yet arrived
kylehuff 09:12 it doesn't complain about not being able to find the .hpp file at all, it just complains about that missing definition (unint64_t).
taxilian 09:12 wait… unint64_t?
jshanab 09:12 Is the main functionality of a plugin suppose to line in the class that inherits from JSAPI? or in the class that inherits from pluginCore?
taxilian 09:12 not uint64_t?
jshanab: it depends; pluginCore is the most direct "plugin class"
but the API is the object that interacts with javascript
I usually put the main functionality in the plugin object
jshanab 09:12 Thanks.
taxilian 09:12 others have done it differently
jshanab 09:12 I think my thread issue is caused by my incorrect factoring.
taxilian 09:12 just make sure that if you need to call back into the plugin from the API object that you're using a weak_ptr (which the autogenerated getPlugin() function does)
it's important to understand that under normal circumstances, the API object outlives the plugin object
jshanab 09:12 I was starting to use "getPlugin()->...." Is that a good idea?
taxilian 09:12 yes
that will throw a script_error if the plugin has already gone away
jshanab 09:12 ah hA! that is what my issues was, i was trying to acces something after it had been destroyed.
kylehuff 09:12 taxilian: "int64_t" and "uint64_t" - not sure where I got the "unint64_t" - stray n
taxilian 09:12 ok… hmm
jshanab: that would do it.using the shared_ptr and weak_ptr classes properly should prevent that from happening
if you use getPlugin(), it shouldn't ever crash, it'll just throw a javascript error
kylehuff: what version of visual studio are you on?
kylehuff 10:12 taxilian: VS 2008 pro
(on windows XP pro, 32bit)
taxilian 10:12 try adding #include <stdint.h> to the top of variant.h
kylehuff 10:12 taxilian: "Cannot open include file: 'stdint.h'"
taxilian 10:12 was afraid of that…
so there are kinda two problems here;
lemme think about it a bit
I'm betting the stdint.h file was added to vs2010
kylehuff 10:12 okay, no problem; I will try to find out why this thread return is crashing on mac in the meantime.
taxilian 10:12 one more quick thing
could you try adding "boost::" before the int64_t and uint64_t on lines 680 and 681?
kylehuff 10:12 sure
taxilian: that seems to have worked..
taxilian 10:12 cool
taxilian 10:12 kylehuff: I think I tracked down the vs express issue as well, so I'll commit both of those in a few minutes
scJohn: was it you that was using vs express?
scJohn 10:12 yes, i am using express
taxilian 10:12 so I did my #ifs wrong when I tried to fix it to check the ATL version instead of the compiler version in axutil.cpp/.h
can you verify for me what the value of _ATL_VER is? you should be able to see it by hovering over _ATL_VER in axutil.cpp
(This is why you shouldn't try to fix things that you can't personally test when you're stressed, worn out, and in a hurry :-P)
scJohn 10:12 #define _ATL_VER 0x0800 // Active Template Library version 8.00
defined in atldef.h
taxilian 10:12 excelent; that's what I expected
FB_GitHubBot 10:12 FireBreath: master Richard Bateman * 7601d0e (1 files in 1 dirs): Fixed issue where in some cases uint64_t can't be found in variant.h -
FireBreath: master Richard Bateman * d62fe20 (2 files in 1 dirs): Fixed ATL version detection in axutil.cpp -
FireBreath: firebreath-1.3 Richard Bateman * 725495e (1 files in 1 dirs): Fixed issue where in some cases uint64_t can't be found in variant.h (and added support for converting those types to string in FireBreath-1.3) ... -
taxilian 10:12 scJohn: when you have a second, could you try getting the latest FireBreath from github (either 1.3 branch or master, whichever you prefer to work on) and check to see if it can now be built in vs express with no modifications?
scJohn 10:12 sure
taxilian 10:12 awesome. if you could add your instructions for setting up the dirs in 2010 to the wiki that would be awesome as well =]
scJohn 10:12 did you review the instructions? wanted to make sure I did not have anything that was not correct in there.
taxilian 10:12 it looked right to me
scJohn 10:12 k
taxilian 10:12 I'll look it over again after you put it in
and sometime in the next couple of weeks I'll even try it =]
I'm seriously considering trying to add something to the cmake config to automatically detect if we're using the express edition and look for the ATL libs if so
(we probably dont' actually need the MFC ones, but if you're installing it you may as well do both, I figure)
just not certain how to tell if we're on express edition or not
scJohn 10:12 prep2010express
taxilian 10:12 but that would make the setup a lot easier; just install the WDK and it would work
well, that'd be an option, of course… I'm really trying to find ways to reduce the number of prep scripts, though =]
not make more
scJohn 10:12 that is why i was trying to put the includes in the cmake files. figured eventually you could automate it
taxilian 10:12 I think I probably can
just a question of figuring out how
I suspect it won't be too hard
scJohn 10:12 ok, wiki is updated.
taxilian 10:12 I've long suspected that this would be possible (building with vs express) and I thought that there was a free download from microsoft that had the files we needed; I just wasn't sure which one and didn't have the time to try to find it
awesome, thanks
scJohn 10:12 and latest from git is compiling now
taxilian 10:12 does anyone know of anything else significant that needs to be fixed or done before 1.3.2 is released?
looks perfect
As soon as I have time to go through and create the changelog I will be releasing 1.3.2, then
assuming that scJohn is able to build on vs express with no changes, that is =]
scJohn 10:12 still building.. i did a rebuild on the main project, i hope that recompiles everything, i also did a prep2010 prior
seems to work now.
ok, yep that 0900 seems to have fixed my m_hkey problem
taxilian 11:12 sweet
the problem was actually that I was checking < instead of > :-P but then I realized that it should have also been <= if it were 0800
(I may have that backwards, I forget)
FB_GitHubBot 11:12 FireBreath: cmake_patch Richard Bateman * d9516e8 (2 files in 2 dirs): Made changes to work with patched cmake. Hopefully this patch will be in cmake 2.8.4 -
taxilian 11:12 anyone want to volunteer to put up the changelog for 1.3.2?
paztulio 12:12 I have problems linking when using methods with FB:VariantList as argument
taxilian 12:12 is there a reason you want it to be a list of variants, instead of, for example, a list of strings?
paztulio 12:12 i actually want vector<char>, but that also does not work
taxilian 12:12 try std::vector<std::string>
also try making it non-const and/or non-pass by reference
(I'm not sure why that would be a problem, just suggesting things to try)
paztulio 12:12 i will check later. got to go now
taxilian 12:12 okay
if that doesn't work, try building FBTestPlugin
because there is an example of passing a vector there
paztulio 12:12 nevertheless, firebreath is really great! thanks.
taxilian 12:12 yeah, we know ;-)
we're glad it's helping you, though
please contribute back in whatever way you are able; one great way is to update the docs on the wiki when you find things that are unclear
paztulio 12:12 i may someday publish the plugin with source
taxilian 12:12 that would be cool =]
paztulio 12:12 it exposes iostream, getcwd(), stat() and some other file stuff to js
taxilian 12:12 lol. please be very very careful where you distribute that, then =]
oh, and be aware; changing the cwd in a browser is not usually a good idea
paztulio 12:12 it is never a good idea
taxilian 12:12 you may also want to consider using 1.4 and using JSAPISecure so you can put some access control on some of those functions to only be useable on certain domains =]
I'm glad you know that =]
paztulio 12:12 i will use it with a chrome extension
taxilian 12:12 I have actually seen plugins that changed cwd, though :-P
umm… that you plan to distribute?
paztulio 12:12 because chrome does not have a file api
yes, too
taxilian 12:12 you realize how big of a security risk that is?
paztulio 12:12 well, it allows writing files, thats what i need.
taxilian 12:12 make darn certain that your APIs can *only* be used in safe circumstances; otherwise someone could look at your extension, understand how the plugin works, and then inject your plugin into a website and anyone visiting with your extension installed could have their data vulnerable to javascript
there is a reason that Chrome doesn't support that natively
paztulio 12:12 the extension is jailed inside the extension's background page
it is also not in the system's plugin folder
taxilian 12:12 fantastic… except that the plugin can be used anywhere
paztulio 12:12 pages cant load it
taxilian 12:12 are you 100% certain?
I don't know of a way to do that
but I could be wrong
kylehuff 12:12 yeah, you can specify bundled plugins as accessible only to the extension jail.
paztulio 12:12 i havent checked but the docs say that.
taxilian 12:12 okay
paztulio 12:12 but i should check
taxilian 12:12 yeah, just be careful =]
paztulio 12:12 i will add an parameter
kylehuff 12:12 I have tested on win, mac and linux
taxilian 12:12 okay; that's good
paztulio 12:12 where you can specify a regexp for valid paths
taxilian 12:12 just be careful where you point that thing is all =]
kylehuff 12:12 also, any extensions which bundle NPAPI plugins are reviewed for security flaws by the google team before being accepted into the extension gallery, so if it fails that review, the audience is slightly less robust..
taxilian 12:12 good to know
paztulio 12:12 the extension is a comination of user pages ( inject and run js ) with integrated js editor and now i want to add downloads
it allows easy harvesting of pictures from for example
but you could also use it for tampering with javascript on (your) webpages for testing
kylehuff 12:12 taxilian: regarding the change-log for 1.3.2 - I might be able to do it, but probably not the best candidate as I don't know what exactly that entails.
taxilian 12:12 kylehuff: mainly it just entails looking at the git log for that branch and recording what changes there have been since 1.3.1
kylehuff 12:12 taxilian: okay, I will get started
taxilian 12:12 thanks
I can do the cleanup work, it's just that I have still one more programming project to finish for the semester
kylehuff 12:12 no problem - glad to help
taxilian 12:12 so with everything I've learned about cmake since I first started firebreath, now I really want to go through and completely redo the way cmake works with firebreath; however, that would be a set of changes that would *definitely* not be backwards compatible, so it might have to wait for a good long time...
jshanab 13:12 sooo. if I call getPlugin and it throws the exception, but the javascript has no try-catch block, what happens?
taxilian 13:12 javascript error
'course, that won't happen unless either your page is closing or you remove the plugin from the DOM
you could always catch the script_error yourself
kylehuff 13:12 taxilian: 1.3.2 release notes posted, though it may require some rework...
jshanab 13:12 ok. Not what is happening. I refactored and put Everything in the plugin and my exception on plugin destruct still exists.
taxilian 13:12 ok, this would just be a javascript exception
wouldn't cause a c++ exception
or a crash
kylehuff: thanks, I'll take a look
kylehuff 13:12 I don't think it is wise to thank me until you have looked at it... lol
jshanab 13:12 If I set the thread pointer to null after the threads shut down, the error changes to bitching about the pointer being null, so it is definitely a timeing issue where it is still trying to use the darn pointer
taxilian 13:12 kylehuff: I don't think FB_GUI_DISABLED went into 1.3; are you sure you were looking at just the 1.3 branch history?
kylehuff 13:12 taxilian: no, I wasn't.. thats what I get for having multiple tabs open
taxilian 13:12 lol
kylehuff 13:12 I'll go back through it
taxilian 13:12 go ahead and put the other things in a 1.4 (still under development) section
what OS are you running?
kylehuff 13:12 me? debian
taxilian 13:12 hmm. don't know a good git UI for that =]
kylehuff 13:12 I don't need a gui, I just need to leave multitasking to my wife...
anyway, I remove the stuff that wasnt actually for the 1.3 branch..
taxilian 13:12 lol
cool. The bit about the main improvement being that VS express should now work was accurate, btw
and this is perfect; I'll make a few tweaks later when I release, but mostly this is what I needed
not really hard, but every bit adds up
when I do a release, I have to update not just the firebreath site, but also the build server, ohloh, freshmeat, and google code
amackera 13:12 Man I really need to get windowless support in IE :( I haven't committed patches to FB in faarr too long
taxilian 13:12 Hmmm… do I agree with that emphatically and make you feel bad, or stay silent so that you know that I don't disagree? -[
amackera 13:12 hahah :D
taxilian 13:12 amackera: I'm hoping to release 1.4 at the end of the month… it would be *really awesome* if we could release full windowless support with it...
amackera 13:12 taxilian: I fully intend to have windowless for IE working before the end of the month
So that sould work out
taxilian 13:12 awesome! =]
maybe I'll get multiple mimetypes working by then as well
kylehuff 14:12 so, along those lines, is there a way to to compile only the NPAPI parts of the plugin and exclude the activex stuff? for some builds of my plugin, they will be packaged into an extension (which is browser specific) there is no chance of that binary every being used in IE.
taxilian 14:12 there isn't; currently, the ATL stuff is used to register the plugin
also for the main windows entrypoints
so it would be hypothetically possible to do something like that, but it would take a lot of refactoring
probably wouldn't be a bad idea, however
just something that would take some time
kylehuff 14:12 ah, okay. I see..
jshanab 16:12 Hey guys, I need some help. I have a class that, during debugging, goes all the way thru the destructor and into forefox code that "has no source" then when I continue it runs the destructor again with a flag set to tru that was not set by ANYONE and that causes an assertion. very weird
taxilian 16:12 you have either a stack or heap memory corruption issue
congratulations =]
jshanab 16:12 Amazingly consistant
exactly the same variable and function every time
taxilian 16:12 I've done that before =]
the easiest way to track such a thing down (IMO) is to take things out; verify the code runs correctly without the call, narrow down which call makes it break
then step into that call, take things out
put them back
find which call makes it break
things like that can happen when something isn't passed correctly; bad typecasts, mismatched function prototypes, accessing a pointer that isn't set correctly
and they can be very consistent, since the memory may be set up the same way each time; if the memory is set up in such a way that your weird typecast / assignment / whatever gets it set so that the vtable and the NPClass table get mixed, you could easily call a function and find yourself in browser code
anyway, that'd be my first guess
comment things out, process of elimination
jshanab 16:12 This is a sneaky one. This is code that runs when it is in it's own messy plugin build, something about porting it to firebreath has gotten me. I worry the most about a boost thread that is started that loops
taxilian 16:12 well, try commenting out parts of that thread; see if the problem goes away
taxilian 21:12 well, 1.3.2 is out.
g'night, all