IRC Log Viewer » #firebreath » 2010-11-18

IRC Nick Time (GMT-7) Message
DFUN 08:11 hmm... how can I access the stream (protected member) from a subclass of DefaultBrowserStreamHandler? The comment says not to use the member directly
but I want to be able to close a stream, so why not just call stream->close() from the subclass?
nitrogenycs 08:11 hmm
all your stream event handlers have the stream passed into them
and there's also evt->stream within the handlers
can you use one of these?
DFUN 08:11 if want to close the stream without an event.
nitrogenycs 08:11 hmm, maybe I should remove the stream member from the handler completely.
you are creating the stream somewhere, so you must already have a handle to it
DFUN 08:11 hm, let me see
nitrogenycs 08:11 hmm, or I add a getStream() accessor to the handler
although this seems a bit wrong
the handler should not be connected directly to a specific stream probably
you could attach the same handler to multiple streams although that's probably not too common
DFUN 08:11 ah, that's right. Currently I just pass the stream handler as a parameter for "createStream" and don
't use the returned stream
nitrogenycs 08:11 So you'd prefer the getStream() accessor?
DFUN 08:11 I create a stream handler and attach it to each stream created
nitrogenycs 08:11 ok
that's probably the most common use case
DFUN 08:11 I could pass the returned stream to the stream handler.
but that would be too pretty
nitrogenycs 08:11 :)
DFUN 08:11 wouldn't
nitrogenycs 08:11 I'll add the getStream() accessor
people wanting to attach the same handler to multiple streams will have to write their own class then
that class is also missing a virtual destructor
gonna fix that as well
DFUN 08:11 yes, they probably won't need an accessor
do you commit your changes right away?
so I can use the nightly build tomorrow with this improvement
tea time at work - brb =]
nitrogenycs 08:11 DFUN: committed to the default repository as there were no backwards-incompatible api changes
use handler->getStream() to get the stream
DFUN 08:11 fantastic.
DFUN 09:11 I will check the changes tomorrow. Good evening.
TomL 09:11 Hey, just stopping by to thank you guys again. Today I managed to integrate the C4 engine into a firebreath plugin. There are still some quirks, but I'm anyhow blown away by how easy firebreath made the whole process.
neilg|away 09:11 Awesome news! Glad to hear it!
neilg_ 09:11 I know taxilian will be pleased to hear it :)
DriesSt 09:11 Does anybody know if it's still possible to do any asynchronous call from the plugin to the browser without crashing the plugin (in 1.3 trunk)?
TomL 09:11 I wont promise you anything yet, but I might go about posting a tutorial on what needed to be done to make it work. But first I will have to complete my work, fix crashes etc.
until further notice.. :-)
taxilian 09:11 morning all
TomL 09:11 g'd evening to you, sir :P
and bye
taxilian 09:11 =] have a good one
glad FireBreath is working well for you
DriesSt 09:11 currently I'm doing this (not from the main thread): void ConnectionPeerImpl::setLocalCandidates(std::string localCandidates) { this->FireEvent("onlocalconfiguration", FB::variant_list_of(localCandidates)); }
taxilian 09:11 that should be possible, yes
are you having a rpoblem?
DriesSt 09:11 it basically crashes the plugin in every browser, except safari on OSX, there it crashes the entire browser
taxilian 09:11 awesome. what platform(s), and did it used to work? if so, when did it stop?
DriesSt 09:11 it never worked :(
i'm currently testing on OSX
events and callbacks work fine for me, but not asynchronously
i may give win7 a chance if you think that could make a difference
taxilian 09:11 meaning not from another thread? can you create a sample that reproduces the problem?
or give me a stack trace?
DriesSt 09:11 ok, let me figure out how to get a stack trace of the crash in xcode
taxilian 09:11 it is possible that something has changed to cause a cross-thread async call to crash, but I woulnd't expect so...
welcome =]
oka801 09:11 Hello
taxilian 09:11 how're it?
oka801 09:11 Firebreath is great (after I've tried to use "pure" NPAPI for a while). I have one short question so far: is it safe to call JSAPI::FireEvent from a thread other than main?
taxilian 09:11 yes
or at least it should be; someone is currently having trouble with it. If I can see an example where it isn't I can probably fix it in minutes
oka801 09:11 I have no troubles so far. I want to keep a background "computation" thread from which JSAPI object receives events and then propagates it to the JavaScipt objects with FireEvent.
taxilian 09:11 that should work just fine
oka801 09:11 And it could happend, that that "model" event is received when plugin is already destroyed.
taxilian 09:11 two things to keep in mind, there
DriesSt 09:11 safari crashes somewhere in safari code, so that won't be useful
i'll try to make a stack trace for firefox
taxilian 09:11 DriesSt: that could very possibly be the timer issue that physicsrob and I have been trying to track down
DriesSt 09:11 it's in safari's timer code
taxilian 09:11 oka801: the JSAPI object will not get released until the last thing holding the reference goes away
DriesSt 09:11 I'll paste the stack trace, ok?
taxilian 09:11 DriesSt: I already know what it looks like, then
DriesSt 09:11 #0 0x0059aa00 in ?? () #1 0x98b64e4e in std::__adjust_heap<WebCore::TimerHeapIterator, int, WebCore::TimerHeapElement> () #2 0x98b64d3d in WebCore::TimerBase::heapPopMin () #3 0x98aa6ade in WebCore::TimerBase::setNextFireTime () #4 0x98aa68fb in WebCore::TimerBase::stop () #5 0x96fff2b5 in -[WebNetscapePluginDocumentView stopTimers] () #6 0x96f913b7 in -[WebBaseNetscapePluginView restartTimers] () #7 0x9813d1c3 in _nsnote
hmm, it's messed up
taxilian 09:11 DriesSt: use pastebin
DriesSt 09:11
taxilian 09:11 oka801: ideally you want your threads to all shut down when the JSAPI object starts going away
DriesSt 09:11 could it be because I use non-boost threads?
taxilian 09:11 DriesSt: no, that wouldn't make a difference. This is actually a browser bug, as near as we can tell; we're going to have to write our own scheduling code. Georg started, but I'm not sure how far he has gotten. How well do you know cocoa?
DriesSt 09:11 I've never used cocoa :s
taxilian 09:11 ok
well, you're about where I am, then
this is a little bit of a tricky issue
DriesSt 09:11 so is there some explanation somewhere what is going on with the scheduling?
oka801 09:11 taxilian: thank you very much! I plan to keep boost::weak_ptr in a model to jsapi object, so that no event will reach object that is already destroyed. will see what wil happen when object receives event (and calls FireEvent) after plugin is destroyed, but before object is destroyed.
DriesSt 09:11 maybe a chat log or something?
taxilian 09:11 oka801: that doesn't ever happen; async events hold a shared_ptr until they fire
DriesSt: let me see if I can find it
the most comprehensive is here:
it's kinda a long read, though
oka801 09:11 taxilian: ok, thanks! I'll come back when I have more questions :), thank you for the great support!
taxilian 09:11 DriesSt: do you understand what NPN_PluginThreadAsyncCall is / should do?
DriesSt 09:11 I'll lookup NPN_PluginThreadAsyncCall and then do the long read :)
I'll be fine
taxilian 09:11 well, I need this done too
and soon
so I can explain it again
basically NPN_PluginThreadAsyncCall is supposed to take a function pointer and an opaque pointer and call it on the main thread
but on Mac OS X in some cases (particularly on Safari) NPN_PluginThreadAsyncCall either isn't provided or doesn't work reliably
so we need to create our own somehow
that's how all the async and cross-thread stuff works
DriesSt 09:11
taxilian 09:11 but one of many actual problems we've found
so in order to work around this, we started using NPN_ScheduleTimer
that is what is producing the crash dump you see =]
DriesSt 09:11 i can't run firefox in debug mode on OSX
firefox crashes immediately when it starts in debug mode :s
taxilian 09:11 it is possible to turn off the mozilla crash reported
and then you can get the full crash dump when the default OS X crash handler pops up
I don't remember how, though =]
DriesSt 09:11 firefox crashes before it even starts, before I've even loaded the html page that loads the plugin
taxilian 09:11 right; but you don't need a debugger connected if you can disable the mozilla crash reporter
DriesSt 09:11 ow, but without debugging only the plugin crashes
not the browser
taxilian 09:11 what version of firefox?
DriesSt 09:11 so i can't have a stack trace
taxilian 09:11 is it running OOPP?
DriesSt 09:11 4beta7
taxilian 09:11 yeah, that would do it
DriesSt 09:11 maybe i can attach the debugger afterwards
taxilian 09:11 that's what I usually do
make sure you get the right process
DriesSt 09:11 what's oopp?
now the event executed but firefox crashed afterwards
the behavior is extremely erratic :s
I'll try to figure out how firebreath does the async calls now
taxilian 10:11 Out Of Process Plugin == OOPP
DriesSt: So the main thing we need to figure out is how to schedule a call on the main thread using Cocoa
I can do it on Carbon
DriesSt: Georg / Cygmatic has been playing with it; here is what he came up with:
DriesSt: to disable the mozilla crash reporter, vi /Applications/ change the Enabled=1 to Enabled=0 under the Crash Reporter section.
DriesSt 10:11 ok, i've traced through the code how this is done in firebreath
so basically now the broken NPN function is called
taxilian 10:11 right
DriesSt 10:11 so where is the "nicest" place to override this behavior?
NpapiBrowserHost::ScheduleAsyncCall or CrossThreadCall::AsyncCall
taxilian 10:11 CrossThreadCall uses ScheduleAsyncCall
however, I have been doing it even earlier
I have been replacing the function pointer with my own
hang on
DriesSt 10:11 ok, meanwhile I'll read the Georg/Cygmatic code
taxilian 10:11 DriesSt: Here is where we decide if we should override it:
and here is the replacement:
DriesSt 10:11 so how far is this stuff from working?
taxilian 10:11 I actually don't know
I was thinking I might try pulling it in and find out
Georg started it and sent it to us, but I haven't had time to look at it and rob hasn't either
and Georg has been swamped and is hiding from us =]
DriesSt 10:11 you should probably fix this before you pull it in:
taxilian 10:11 lol. yeah, probably so =]
I would surmise that that was intended to help him check to see if it was working correctly =]
DriesSt 10:11 I think this stuff should work though
taxilian 10:11 it looks pretty good
my hope is that it will be almost just a drop-in
will have to put it in dev, though
DriesSt 10:11 Ok, then I'll switch to dev and play around with it
see how it does
taxilian 10:11 it's pretty solid
that's what I develop off of
DriesSt: isn't it, like, in the middle of the night there?
DriesSt 10:11 yeah :)
taxilian 10:11 hehe
DriesSt 10:11 my brain works better at night ;)
taxilian 10:11 =] well, I built it, and it isn't working so far...
:-P trying to get breakpoints working to figure out what is happening
DriesSt 10:11 ok, I'll clone it
amackera 10:11 hey all :D
taxilian 10:11 hey! Mr. Memory leak himself! ;-)
sorry, I have to give you crap about that
have you seen my commit last night?
DriesSt: Turns out it was something else; the performselector code seems to work great
amackera: I did see that you fixed the minor Point leak in Dev; the on you missed was calling CFRelease on the event you created
DriesSt 11:11 ok, I've tried it and got the following results:
chrome: plugin crashes on async callback
safari: the entire browser crashes
ffb7: the async callback works, but afterwards the entire browser just freezes
minefield (firefox4pre-beta8): plugin crashes on async callback
so at least the guys at firefox are messing with it
taxilian 11:11 hang on a minute, let me get my changes into a clone for you
DriesSt: try pulling from here:
or maybe better start with it clean
it seems to be working for me
DriesSt 11:11 it's building
taxilian 11:11 this might not (yet) affect Firefox, but we can tweak it if it seems to fix the problem on Safari
and Chrome
DriesSt 11:11 so it detects which browser is hosting?
taxilian 11:11 yes
64 bit mode it will always be used
otherwise is used on webkit
DriesSt 11:11 firefox4 is always 64bit on osx
taxilian 11:11 ok
then it will be used for firefox4
DriesSt 11:11 it seems to be working on safari
but safari crashes when unloading the plugin :/
but the callback event seems to be working ok at first sight
taxilian 11:11 crash dump for the unload crash?
and are you testing your own plugin or FBTestPlugin?
I can't reproduce this crash
DriesSt 11:11 with my own plugin
taxilian 11:11 can you see if it occurs with FBTestPlugin? I can't reproduce it with FBTestPlugin
if you can isolate what it is, it could be related to FireBreath
I just can't fix what I can't see =]
DriesSt 11:11 ok, ofcourse
I always have some odd behavior when refreshing the page that hosts the plugin
taxilian 11:11 that is a common problem with plugins
often caused by static or global variables or resources
DriesSt 11:11 I don't use any, but maybe the library I use does
taxilian 11:11 that wouldn't surprise me
amackera, are you around?
DriesSt 11:11 FBTestPlugin seems to be rock stable on safari
taxilian 11:11 awesome. I just ran it with Leaks on Firefox; no memory leaks detected
DriesSt 11:11 stable on minefield as well
this is definately a major improvement
does the test plugin do asynchronous callbacks?
taxilian 11:11 yes it does
not cross-thread, but they should work the same way
there is a call in there to test threading, but you have to call it yourself, the test page doesn't have it integrated ATM
taxilian 12:11 welcome ben__
ben__ 12:11 hi there
i just found your project yesterday -- looks like it's going to be a major timesaver for me
which is great
taxilian 12:11 that's the goal
ben__ 12:11 yes
i have a quick question
taxilian 12:11 that and to be ridiculously awesome, which we have obviously already managed
fire away
ben__ 12:11 from what i can tell, i'm supposed to edit files in the projects\ directory, then run prep and build from the build directory
taxilian 12:11 yep
ben__ 12:11 so if i want to edit and build within visual studio, what's the best way to go about that?
taxilian 12:11 open build/FireBreath.sln
and build
and edit
just any time you add new files to the project, do so using the cmake files
and try to keep your changes in your own files; if there are changes that need to be made elsewhere, they are FireBreath bugs or missing features
which is also fine, just know the difference =]
ben__ 12:11 okay - so the firebreath.sln references files in the projects\ directory, and then runs prep (or some equivalent) to replace the ones in the build directory, then runs the build?
oh, hold on
i'm backwards - none of the source files for my plugin are copied to the plugin's directory in the build directory
taxilian 12:11 right
ben__ 12:11 i guess that explains everything
taxilian 12:11 cmake generates project files that use your files
I recommend putting your projects/ directory outside of the firebreath root, which makes it easier to update firebreath
ben__ 12:11 got it - yes - it's somewhat more opaque when you rely on the IDE to tell you everything
which is probably my failing
taxilian 12:11 sorry, not sure how to make that more clear
ben__ 12:11 nah
it's okay
yeah, that was my second question
taxilian 13:11
ben__ 13:11 yeah, just saw that
okay, thanks for your help so far
taxilian 13:11 no problem
feel free to update the wiki if you find things that aren't clear
ben__ 13:11 is prep smart enough to recognize only firebreath projects in a directory full of other kinds of projects?
taxilian 13:11 hmm. maybe, but not always
you can have multiple projects in a single directory, and that allows them to share several of the projects
that may change at some point in the future when we add support for multiple mimetypes in a single plugin
but that's still waiting on one of us having time to brute force ATL
ben__ 13:11 you mean remove the dependency?
taxilian 13:11 that would be idea
at the very least, we need to replace the classfactory
with one that will figure out which CLSID was used to create the plugin, convert it to a mimetype, and use that to call createPlugin
so that a different pluginCore object can optionally be returned
ben__ 13:11 ah - so you are relying on ATL's com factory stuff, which is not flexible enough for that scenario
or that's what it sounds like
taxilian 13:11 right
I know that it is possible to do what we want to do, but it is somewhat non-trivial to figure out initially
so I just haven't had time yet
ben__ 13:11 well, with everything else you guys have done, i'm sure it won't be long
taxilian 13:11 I don't actually need it yet. need drives most features =]
ben__ 13:11 it's great how much work has gone into this over a year and a bit, especially relative to other opensource projects
taxilian 13:11 we're fairly pleased with it
ben__ 13:11 so modest
amackera 13:11 :D we're awesome
taxilian 13:11 ridiculously awesome, actually
but that would be telling
ben__ 13:11 too late
i've seen everything
taxilian 13:11 this is the problem with open source… everyone can see your secrets
where are you located?
ben__ 13:11 victoria, bc
working on a project for a san diego company
taxilian 13:11 cool
I'm in Utah, USA, working on a project for a san fransisco company :-P
ben__ 13:11 love those california tech companies
amackera 13:11 I'm in Waterloo, ontario, working on a project in Waterloo, Ontario :P
ben__ 13:11 we all have our crosses to bear amackera
amackera 13:11 hehe
I would love to move to BC though
ben__ 13:11 i like it
taxilian 13:11 you know what is annoying? there are good, free memory and heap debugging tools on every platform but windows
ben__ 13:11 windbg is free
not sure whether you'd call it good
it's powerful
taxilian 13:11 what does it do that visual studio doesn't?
ben__ 13:11 well, here's a list of the common commands
more of a system level debugger
i'm not an expert with it, but take a look
taxilian 13:11 hmm. stil not seing anything here for tracking down things like heap corruption and memory leaks beyond what visual studio has. maybe I'm not reading carefully enough?
ben__ 13:11 check out
nitrogenycs 13:11 hey, I just wanted to mention that
I've actually contributed a small bugfix to it :)
taxilian 13:11 cool; I'll take a look at this
nitrogenycs 13:11 oh, just that I mean this one:
taxilian 13:11 I'm hoping that Facebook will shell out to get me a license to purify
ben__ 13:11 yeah, that would be easier
taxilian 13:11 I've looked at VLD a bit; would that help me track down heap corruption issues as well?
what I'm really trying to find is why so many NPAPI browsers are getting the referencecount of their NPObjects messed up while we're holding onto them
nitrogenycs 13:11 I'm not sure, but you can set a breakpoint in visual studio on a memory location
taxilian 13:11 yeah, I might have to resort to that
nitrogenycs 13:11 so whenever that location changes or reaches a certain value the breakpoint is executed
ben__ 13:11 i'm off. thanks again - i'm sure i'll be back\
taxilian 13:11 problem is that as far as I can tell, we're doing everything correctly, and it is not a consistent bug
good luck, ben__
so I'm wondering if maybe we're freeing something we shouldn't (or giving the browser something that should have been allocated using the browser's heap instead of ours, so that the browser frees something it shouldn't) and that's causing the memory to get toasted
but then you'd think it would affect more than just NPObjects
nitrogenycs 13:11 hmm, no idea really
i also get random crashes at page close at the moment
the bug might be in my code though
taxilian 13:11 what platform?
nitrogenycs 13:11 windows 7, firefox
taxilian 13:11 version of firebreath used?
nitrogenycs 13:11 the one from default trunk
i didn't have the issue until I updated hg 2 weeks ago
but I need to investigate more on my own, before blaming you or amackera :-)
taxilian 13:11 hmm. well, update again, since there are some new fixes since then
but nothing that sounds like it should do that
does it crash in such a way that you can attach a debugger?
nitrogenycs 13:11 I've updated it today, but nothing changed
probably yes
just the crashes are random
sometimes it works, sometimes it doesnt
taxilian 13:11 well, the easiest way to find out what is happening is to get a crash dump
if you turn off mozilla crash reporter (or figure out how to get at what it collects)
there is probably a way to get a dump of the process
which you can then load in visual studio
nitrogenycs 13:11 I'll just attach the bugger a few times and then catch the crash in the act
taxilian 13:11 also a good option
I'd really like to know if that is in FireBreath
nitrogenycs 13:11 while crash dumps are useful I prefer live debugging
taxilian 13:11 I keep itching to release 1.3.1 but every time I am ready to do so someone mentions something else
ok. I better work on some homework for awhile
good luck everyone
oka801 14:11 Hello!
oka801 14:11 With FireBreath 1.3.0 I get JSAPIAuto objects never deleted - this happens with generated plugin, destructor of JSAPIAuto is never called, and m_api.use_count() in the PluginCore destructor is always 2 or 3 and left to 1. I tried to use weak_ptr for JSAPIAuto subclass to implement Observer patttern - but failed because use_count() always remained 1 in a weak_ptr (after page reload). First I...
...thought that it is my fault as I do not know c++ and boost well, but it looks that even with default plugin JSAPIAuto objects are never deleted. Is this known problem?
I'm testing with firefox, NPP_Deallocate is called for the object.
nitrogenycs 14:11 hmm, I found one cause of my bug
the crashing one
I am running a second thread in my app
the second thread does this:
api->getHost()->ScheduleAsyncCall( DoProcessing, api );
ScheduleAsyncCall calls PluginThreadAsyncCall(func, userData) in turn
which in turn ends u at NPNFuncs.pluginthreadasynccall(m_npp, func, userData);
and the crash is on that line
any comment?
Is ScheduleAsyncCall not threadsafe?
that kind of seems to defeat its purpose
unfortunately the crash is somewhere deep inside xul.dll and I don't have a debug build of firefox
taxilian 14:11 nitrogenycs: what version of firefox is this?
nitrogenycs 14:11 I think the latest 3.6
I did an update yesterday
taxilian 14:11 oka801 left already, I guess?
nitrogenycs 14:11 I can't look atm, cause it's still in the debugger :)
seems so
taxilian 14:11 if he comes back and I'm not here, let him know that the bug he's worried about is fixed in the latest stable nightly
nitrogenycs 14:11 okay
taxilian 14:11 nitrogenycs: that's really odd; pluginthreadasynccall should be threadsafe
are you using OOPP maybe?
nitrogenycs 14:11 I don't think so
taxilian 14:11 I think 3.6 can be set to do plugins out of process...
that is bad
really bad
nitrogenycs 14:11 i'll terminate the debugger and have a look
that also explains why the crash occurs only sometimes
taxilian 14:11 I'm starting to think that we need to stop ever using pluginthreadasynccall and always provide our own
nitrogenycs 14:11 here's an idea
taxilian 14:11 I've never known it to be a problem on windows, though
at least on firefox 3 or later
nitrogenycs 14:11 maybe the plugin is already destroyed
but NPNFuncs.pluginthreadasynccall is still non-null
so when the thread wants to call that func, the plugin is not there anymore really
taxilian 14:11 hmm… that's possible, I suppose
let me think on that
nitrogenycs 14:11 cause this problem always happens on reload
taxilian 14:11 you're storing the host but not the plugin, I take it?
nitrogenycs 14:11 storing it where?
taxilian 14:11 a reference to it
a shared_ptr
nitrogenycs 14:11 DCEngineWebPlayerAPI* api = static_cast<DCEngineWebPlayerAPI*>( param );

while ( !api->quitting )
api->getHost()->ScheduleAsyncCall( DoProcessing, api );
that might be bad
taxilian 14:11 let me think a bit..
nitrogenycs 14:11 It should probably be a shared ptr, not sure
taxilian 14:11 yes
extraordinarily bad
most definitely
you should *never ever ever* be keeping a raw pointer to your JSAPI class
nitrogenycs 14:11 was this always wrapped in a shared_ptr or was that added at a later point
taxilian 14:11 as of firebreath 1.2
it's documented in the changelog
and all over the place
nitrogenycs 14:11 ok, I probably missed to change my own code
taxilian 14:11 and here:
probably what you should do is store a weak_ptr
nitrogenycs 14:11 btw, the streams also need the smart ptr I think
taxilian 14:11 then just try to lock the weak_ptr
yeah, I was considering that. I haven't had a chance to try using the streams yet
I planned to look at doing that when I did
but if you're back working on the plugin that might be good for you to do, if you're willing
nitrogenycs 14:11 yes, currently I need to get some things done, so this will be on the backburner until I've finished that stuff. Or it gets in my way, then I fix it earlier :)
taxilian 14:11 no problem
I might fix it earlier as well
it's usually a good idea to have at least two developers look over all of your code
neilg_ has provided a second pair of eyes on yours now and it's becoming much more mature, but me going over it as well couldn't hurt
it's also the largest piece of code in the codebase that I don't know well =]
nitrogenycs 14:11 sure. I've also never had time to polish it really. I was happy enough it worked :)
taxilian 14:11 hehe. believe me, I was (am) as well =]
it will save me a lot of time
so try changing any raw pointers you have to firebreath objects (except events; those are still raw pointers) to shared_ptr and see if that fixes your problem
my bet is that it will
nitrogenycs 14:11 I think I did that in almost all places, just that place I missed
cause I have to pass a raw pointer to CreateThread()
taxilian 14:11 when you're using threads it's even more important not to use raw pointers
btw, you may want to consider instead of using ScheduleAsyncCall using ScheduleOnMainThread
nitrogenycs 14:11 yeah. I'm using a custom intrusive smart pointer class for my own projects (created before shared_ptr became widespread) and am not yet really familiar with shared_ptr semantics
taxilian 14:11 which probably didn't exist when you started it
yeah; we used to do that, but it ended up having problems. turns out that smart pointers are ridiculously hard to do well
nitrogenycs 14:11 ok, switch to ScheduleOnMainThread
:) I've debugged them more than once
taxilian 14:11 then you don't have to worry about using an opaque_ptr
nitrogenycs 14:11 there was a small problem I found after years of use
taxilian 14:11 if it were me, I'd change them all to shared_ptr
but then, I already did that with firebreath
and it just made so many things so much easier
also gives us the ability to use weak_ptr, which is absolutely fantastic
nitrogenycs 14:11 Actually, in my project almost everything uses smarpointers
taxilian 14:11 firebreath is getting there too
nitrogenycs 14:11 except in the cases where I need the raw speed
Though I keep wondering why not use a ref counted language straight away :)
or gc collected
i know, because we have to :)
taxilian 14:11 hehe
yeah; it does get a bit confusing to start out with
but once you get used to it, it is nice to have
nitrogenycs 14:11 i think it gets a lot simpler after you realize the power of smart pointers
taxilian 14:11 yep
nitrogenycs 14:11 once anything is shared you go mad without them
taxilian 14:11 yep
nitrogenycs 14:11 it's very hard/impossible to keep track of ownership by hand
taxilian 14:11 oka801: update to the latest nightly, that hsould fix your memory leak problem
nitrogenycs 14:11 hey oka801, taxilian wants to tell yu something about your problem :)
taxilian 14:11 ha! I beat you!
nitrogenycs 14:11 damn
I get old
oka801 14:11 Hello :)
nitrogenycs 14:11 that's what she said
taxilian 14:11 lol
oka801 15:11 taxilian: Yes, I just found that the reason is in <param name="onload"...> and that async event. Probably reference to JSAPIRoot get stuck somwhere. Disabling that "paramer" tag in the sample page fixes the problem. Regarding nightly builds - this is what I wanted to ask as well - do you mean 1.4 nightly or 1.3 one?
Another question is what is the best way to organize my project so that it would be easy to switch between firebreath versions? Currently I keep my files in firebreath/projects/projectName/, but I'd like to keep plugin code aside. Is that possible? Would you recommend to keep files in "build" also under version control?
taxilian 15:11 well, they both ahve the fix, but the 1.3 one is the "stable" one
just move your projects directory somewhere else
when you call the prep script, pass the location of the projects dir as the first parameter
and the second parameter should be where the build/ folder should go to
honestly, what I would recommend is to just check firebreath out of source control
either stable or dev, depending on how brave you are (and whether you're willing to occasionally pop in and tell me if I broke something on you)
nitrogenycs: are the docs on ScheduleOnMainThread clear enough for how to use it?
oka801 15:11 taxilian: thank you for the explanation and for the great project! I'll start with stable 1.3, but in case I encounter a bug, I'll try first to make sure it is present in the latest 1.4 version before bothering you.
I definitely will pop up here, mainly because being an experienced programmer I have mostly no experience with c and c++ (someone would say that I shouldn't then call myself a programmer :)) - and firebreath lies just on my learning curve or better to say my learning curve leads me through the firebreath. Probably when I finish my plugin I will know c++ well enough, but ironically will no...
...longer need it :)
taxilian 15:11 oka801: we try to put bugfixes in stable, unless they require significant changes
nitrogenycs 15:11 taxillian: I think so, I'm looking at them in detail in a few mins. First need to pass the weak_ptrs into the threads. That's a bit ugly, but hopefully works
taxilian 15:11 dev should be primarily for new features or changes
oka801: best of luck with your plugin, and feel free to drop in anytime. If we're not here, stick around for awhile and we'll be back
oka801: Also, as I tell everyone, if it is really useful for you please consider contributing back by helping to update and extend the documentaiton on the wiki
oka801 15:11 taxilian: Thank you and I will do my best to help you.
ben__ 15:11 hello again
taxilian 15:11 welcome back
long time no see
we've missed you
ben__ 15:11 yes
so kind
so, inevitable newbie question - my new plugin with one method that takes and returns a std::string works on FF and chrome, but dies on IE9 with a script exception
(i've tried the test plugin on IE9, and it works fine)
taxilian 15:11 what is the exception?
ben__ 15:11 IE's developer tools say "script exception"
taxilian 15:11 err, yeah
ben__ 15:11 anyway, a method that takes or returns an int is fine
taxilian 15:11 you might have to step through the code to see what is going on
which could be a little harry
ben__ 15:11 so, it sounds related to memory
taxilian 15:11 but you should be able to step through until the exception is thrown
I haven't used IE9, so I have no idea if there are any issues with FireBreath plugins and IE9
ben__ 15:11 sure
the test plugin works well though, so i figure it's something else
i should probably just try on ie8
taxilian 15:11 could be. I would attach a debugger and step through
ben__ 15:11 doing that now
yeah, it's not even reaching my method
interesting, since the test plugin is much more complex than what i'm doing
taxilian 15:11 ok; then go to JSAPI_IDispatchEx.h and set a breakpoint in Invoke
find out what exception is being fired
ben__ 15:11 so it's trying for a property named securityctx
taxilian 15:11 that's normal
ignore that
it's something else
ben__ 15:11 possibly; it throws FB::invalid_member on that call
taxilian 15:11 right
ben__ 15:11 and then no more calls to Invoke
taxilian 15:11 that's normal
ben__ 15:11 ah
taxilian 15:11 that's not
ben__ 15:11 i'm also seeing 'enabled' and 'valid'
nitrogenycs 15:11 taxilian: one really dumb question about ScheduleCallOnMain: How do I create a boost::functor out of a regular function pointer?
I tried boost::bind, but did not work, maybe I did something wrong
taxilian 15:11 nitrogenycs:
boost::bind is correct
you probably did something wrong
look at JSObject.cpp for an example
nitrogenycs 15:11 taxilian: ok, but I don't want to bind to a member function
and I have no args
taxilian 15:11 ben__: are you sure you registered your method correctly?
nitrogenycs 15:11 i'll try again
taxilian 15:11 nitrogenycs: I would expect that to be easier, then =] I haven't used boost::bind on a global function, but shouldn't be hard, I'd imagine. might be something as simple as boost::bind(&function)
ben__ 15:11 is there more to it than: registerMethod("methodname", make_method(this, &classname::methodname)) ?
taxilian 15:11 no, that should do it
what is the name of the method?
ben__ 15:11 i've tried both 'install' and 'test'
taxilian 15:11 and you changed the name you registered it as?
ben__ 15:11 yes: the c++ method names and the strings match exactly
nitrogenycs 15:11 hmm, it works when I use a parameter, so I don't care for now
taxilian 15:11 ben__: I have no idea; try it in IE8
ben__ 15:11 yeah
method sig is std::string myAPI::install(const std::string& metadataTag)
taxilian 15:11 looks okay
ben__ 15:11 i'll give that a shot
taxilian 15:11 if you can send me an example that reproduces the issue I might be able to track it donw
but I can't install IE9 on my main machine right now
ben__ 15:11 np
nitrogenycs 15:11 taxilian: the problem seems to persist, my code looks like
boost::shared_ptr<DCEngineWebPlayerAPI> api = apiWeak->lock();
if ( !api || api->quitting ) break;
api->getHost()->ScheduleOnMainThread( api, boost::bind(DoProcessing, api) );
it still crashes in the npn scheduleasynccall
taxilian 15:11 can you look at the npp and see what the value of pdata is?
or otherwise verify if the plugin has been destroyed already?
nitrogenycs 15:11 pdata looks like a valid pointer
the plugin seems to be alive
taxilian 15:11 but it crashes on that actual call? is the pluginthreadasynccall pointer valid?
nitrogenycs 15:11 it has a value of 0x5d26b4d3
which looks ok, but I can't tell if there's a function at that address
taxilian 15:11 hmm
that makes no sense
you're on windows?
nitrogenycs 15:11 yes
taxilian 15:11 try adding the mozilla symbol server and find out which function it actually crashed in
or is that the top of the stack?
nitrogenycs 15:11 the crash is in xul.dll so I will tryt he mozilla symbol server
taxilian 15:11
hopefully that works
hmm. there used to be good docs on how to do that
nitrogenycs 15:11 ahh, I had it still in my list, just need to reactivate it. Totally forgot about it
taxilian 15:11 cool
ok, I'll be back in a bit
nitrogenycs 15:11 k
taxilian 15:11 gotta run and get some food
nitrogenycs 15:11 hmhmhm, it's crashing somewhere in NPAPIPluginInstance::OnRunning, but the symbols don't seem to match the firefox version i have
oka801 16:11 Question: when I call FireEvent("eventName", FB::variant_list_of(char *)(char *)) - is that correct that (char *) values will then, eventually, be freed by the browser. So if I want to pass a "char *" argument, then I should make a strdup (for example) of original data and then pass copy allocated on heap, expecting that passed value will then be released?
taxilian 16:11 oka801: the char* gets copied into a string and you are responsible for freeing them
so no, don't do a strdup
in fact, I try to avoid ever using char* directly at all; use std::string wherever possible to avoid memory leaks
firebreath does it's best to make sure that as long as you follow the conventions, you never have to worry about memory management directly
oka801 16:11 taxilian: on my model thread I have object with a "char *" member (or let it be of type std::string). so I'm passing just this string to the FireEvent("event", variant_list_of( I do not have to worry about "name" fate, as variant_list_of copies it and frees copy when needed? Is that correct?
taxilian 16:11 right
one of the design goals of FireBreath is to enable constructive laziness
oka801 16:11 taxilian: thank you! it looks like I managed to overcame most of the "make it run and get understanding of objects and memory lifecycle" sort of problems and finally get to the point of implementing business logic! And it didn't take long! I hope that before long I'll be on the other side of the blackhole - working mainly on the javascript part of the application :)
Firebreath impressed me also with its cross-browser support - my first attempt to write plugin with "pure" NPAPI finished in plugin only working in Chrome without any idea on how to make it work in firefox without breaking chrome version.
taxilian 16:11 if you had it working on Chrome you were probably almost there
but yeah, that's why I wrote it
oka801 17:11 taxilian: It's 1am here already and I'm going home. It was a productive day, thanks to firebreath and you. cu.