IRC Log Viewer » #firebreath » 2011-02-27

IRC Nick Time (GMT-7) Message
physicsrob 19:02 ugh.. I just updated my installer and now IE is not finding my plugin. Anyone have any ideas what to check for?
taxilian 22:02 physicsrob: "updated your installer"… elaborate?
physicsrob 22:02 taxilian, I updated the wix template to the latest, I think I did it correctly but I could have easily missed something. I guess that's my question: what sort of thing could I have missed that would make IE not see the plugin? Is there anyway I can double check that the registry is setup correctly?
taxilian 22:02 the first thing I would check is to look at the generated np????.wxs file and see if it looks right
physicsrob 22:02 I looked through it in detail since I customized it per the instruction on the website
to disable to restart apparatus whatever it's called
taxilian 22:02 not your main one
the generated one
physicsrob 22:02 Oh
taxilian 22:02 that starts with np
it is created by heat
physicsrob 22:02 taxilian: by the way -- it looks like I just discovered a memory leak in 1.4
taxilian 22:02 and it should have everything namespaced wtih w:
physicsrob 22:02 yea... every function call that returns something is leaking 18 bytes
18 kbytes
taxilian 22:02 file an issue with details (since I won't be fixing it tonight)
I'll look over it
did you find it with a leak detection tool or observation?
physicsrob 22:02 so for(i=0;i<1000;i++) myplugin.myDummyMethod() will leak 18MB
taxilian 22:02 hmm
so you don't know where it is?
physicsrob 22:02 nope.. but if the method returns void it's not an issue
and it's only on the NPAPI browsers not IE
and only on windows
taxilian 22:02 interesting
that could be (likely is) very bad news
physicsrob 22:02 yeah
sorry to be the bearer of bad news
taxilian 22:02 well, here is the thing
the only difference between the IE version and the firefox version of that call
is in Firefox
however, that doesn't make sense in the "not applicable if it returns void" bit
physicsrob 22:02 nope
actually I was wrong
it does happen if it returns void
chrome and firefox are the same, by the way
taxilian 22:02 hmm
file an issue, also if there is a conclusive way to test it please include that (sample projects are particularly useful)
do async calls do it as well? or only sync calls?
18KB is a ton to leak for something like that...
very weird
and only on windows, you say?
physicsrob 22:02 only on windows
I don't know about async calls
taxilian 22:02 could you try it?
it should be the same
but if it isn't, that will tell me something
physicsrob 22:02 I'm not familiar with async calls in firebreath
taxilian 22:02 CallOnMainThread is synchronous
ScheduleOnMainThread is asynchronous
calling Invoke on a JSObject is synchronous, InvokeAsync is asynchronous
physicsrob 22:02 Oh -- I think there was a miscommunication
taxilian 22:02 for every sync call there is an equal and completely different async call… well, not really, but it sounds good
physicsrob 22:02 I'm talking about calling the plugin from javascrip
taxilian 22:02 wait, what?
that's weird
physicsrob 22:02 yeah
taxilian 22:02 explain this again, please =]
physicsrob 22:02 if I call any method on my plugin object in javascript it leaks 18kb
even if the method does absolutely nothing
taxilian 22:02 that don't make no sense...
and you're sure it's windows only?
that actually makes less sense if it's windows only
physicsrob 22:02 I'm pretty sure it's windows NPAPI only
I can double check on mac really quick
taxilian 22:02 see, the thing is that windows NPAPI does nothing different that I can think of than mac NPAPI in the JS layer
it's all cross-platform
the only platform specific stuff is in loading and drawing
now, a windows-only browser bug in firefox or something I could believe, but all of them? that has to be somewhere in our code
physicsrob 22:02 nope -- it's mac too
but it's much smaller
taxilian 22:02 okay
that makes a bit more sense, then
interesting; it must be new, since I've checked wtih leaks and not seen it previously
please file an issue and I'll look at it tomorrow
(I dont' work on Sundays)
also, I'm about to go to bed =]
physicsrob 22:02 okay.. can I ask one more question really quickly:
taxilian 22:02 sure
physicsrob 22:02 I updated FBSTRING_CLSID
Can that be the cause of it no longer working on IE
the installer, that is?
taxilian 22:02 does it work with regsvr32?
physicsrob 22:02 it does
taxilian 22:02 then it should work with your wix installer
could you pastebin me your np<plugin name> generated wix file?
physicsrob 22:02 frustrating
taxilian 22:02 it'll show up in visual studio, or you can find it somewhere in the build directory
physicsrob 22:02
taxilian 22:02 C6BDB9CB-5921-5A0D-ACED-D5F0EBCD92A1 is your new CLSID?
physicsrob 22:02 yeah
but literally i just changed it from ...2A1 to ...2A0
opposite of that rather
taxilian 22:02 then this looks right to me
I figured =]
see, this file is generated by heat.exe
by basically running regsvr32 and capturing the output
so if that works, this should also work
physicsrob 22:02 very strange
taxilian 22:02 are you certain that your'e using the new WiX installer?
maybe you have an old binary still kicking around somehow
physicsrob 22:02 do I need to make certain that everything is uninstalled before running it?
taxilian 22:02 that would not be a bad idea, though if you've set up the installer correctly that should happen automatically
physicsrob 22:02 I haven't upgraded the installation of wix recently
I mean do I have to make sure everything is uninstalled before generating my installer with heat?
if it's doing a registry delta of sorts
sorry.. this has turned into not so short of a question
thanks for the help
taxilian 22:02 no, it shouldn't matter
it doesnt' actually change the registry
it just captures the calls that it tries to make
physicsrob 22:02 oh okay
taxilian 22:02 very cool, actually
you're not overriding any of the rgs files?
physicsrob 22:02 nope
taxilian 22:02 the next thing I'd try is run the installer, then check for instances of the new CLSID
better, beforehand check for the old one
in the registry
maek sure it's gone
then run the installer, and then look for the new one
and see if the registry keys look like they should
physicsrob 22:02 regsvr32 only changes the registry, right?
taxilian 22:02 regsvr32 only calls DllRegisterServer on the DLL
in our case, yes, it only modifies the registry
technically it could do anything you wanted it to, though
physicsrob 22:02 so I should be able to run regsvr32 and check to see what changes to isolate the porblm
taxilian 22:02 well, you know what regsvr32 is going to do
I would run your installer
and check to see what changes (or doesn't change)
and that'll tell you more
look at the generated .rgs file (in build/projects/<your plugin>/gen) to see what the keys should be
I bet somehow your WiX file isn't the right one, though
or you have somehow extra keys from previous non-wix installs
simply based on things I've seen in the past
could be wrong, of course
physicsrob 22:02 okay.. well thanks for the tips
taxilian 22:02 another thing to try is using process monitor
you can set up filters to only show the registry changes from whatever process runs the wix file (not sure what that is)
and see exactly what it is doing
physicsrob 22:02 cool
that's handy
taxilian 22:02 yeah
believe me, I've spent more *days* debugging weird COM installations than I even want to think about
which is why I recommend using MSIs so strongly
it avoids pretty much all of the problems I've had to track down
and every time someone assumes I'm being overparanoid I have to just shake my head and sigh
physicsrob 22:02 hehe
taxilian 22:02 (which I do, as melodramatically as possible, 'cause hey, if you do something, do it right, y'know?)
physicsrob 22:02 this is really frustrating
taxilian 22:02 oh, that I beleive
physicsrob 22:02 I also changed my dll to use the pattern you recommended where you append a release number
so it's npMyPlugin3.dll
taxilian 22:02 that is important info.. hang on, let me look again
how big is the WiX msi file?
and have you tried deleting the msi file to make sure it's really getting regenerated?
wow… there are 164 members of the firebreath-dev mailing list
physicsrob 22:02 I haven't deleted it
taxilian 22:02 try that
physicsrob 22:02 okay
taxilian 22:02 there could be an error running wix and you're not noticing
physicsrob 22:02 btw.. I just called regsvr32 after using the MSI on the installed dll and it works in IE
so something is definitely wrong with my msi
taxilian 22:02 so you're still using the old version
physicsrob 22:02 gotcha
taxilian 22:02 I'm really betting you're still using the old version somehow
physicsrob 22:02 oops.. I just cleaned my whole project.. I guess I'll find out in an hour :)
thanks for the help tonight
taxilian 22:02 lol. good luck! =]
quick question; do you have any external dll dependencies?
physicsrob 22:02 none that I'm aware of
taxilian 22:02 ooh… could you pastebin me your projectDef.cmake file?
something I want to check quickly
physicsrob 22:02 sure one sec
taxilian 22:02 the Win/ one, obviously
physicsrob 22:02 pastbin is cool btw -- I've never used that before
taxilian 22:02 is another one
there are quite a few
but yeah, invaluable for IRC
physicsrob 23:02
taxilian 23:02 is the signing stuff working for you?
physicsrob 23:02 I think it is
taxilian 23:02 awesome
physicsrob 23:02 there looks like there's a bug in it actually. I had to change one line in Win.cmake
if you pass blank values
for the timestamp dll for example
taxilian 23:02 shouldn't be a timestamp dll
shoudl be a timestamp URL
and I highly recommend you provide it
but that's me
physicsrob 23:02 yeah that's what I mean
taxilian 23:02 I may not have remembered to test that
physicsrob 23:02 when firebreath_sign_plugin calls firebreath_sign_file it fails if you have that blank
taxilian 23:02 ahh
physicsrob 23:02 the blank doesn't get passed correctly from one function to the next
taxilian 23:02 okay
good to know
physicsrob 23:02 not sure the correct syntax
taxilian 23:02 could you put an issue in for that as well? just something quick
physicsrob 23:02 sure
taxilian 23:02 really just need to put " around that variable in the call, I suspect
the firebreath_sign_file call
is there a reason you're not timestamping it?
physicsrob 23:02 by the way -- is there a link to the bug tracker from
no good reason -- is there a good reason to timestamp it?
taxilian 23:02 yes, it's in the top left corner of the screen
physicsrob 23:02 ?
taxilian 23:02 yes; if you timestamp it then people know exactly how long it's been since it was created, so they know if the cert is likely trustworthy, etc
physicsrob 23:02 oh
taxilian 23:02 also sometimes programs don't trust DLLs without timestamping
mainly just good practice
found it? =]
ok, your projectDef.cmake file looks okay; just wanted to verify something real quick
physicsrob 23:02 thanks
what method gets called by npapi when the object tag gets a method call (e.g. myobjtag.mymethod()) ?
where's that entrypoint into firebreath?
taxilian 23:02 NPJavascriptObject
for a method call, it's Invoke
physicsrob 23:02 cool. Thanks
I want to try to track down this memory leak
taxilian 23:02 Rob, that's music to my ears =]
it is wonderful to have people around who are willing to do their own legwork and don't just expect me to fix everything =]
if you haven't found it by tomorrow I will help you
now I'm going to bed, though