IRC Log Viewer » #firebreath » 2010-09-20

IRC Nick Time (GMT-7) Message
amackera 08:09 hey guys
catching up on the mailing list
kalev 08:09 looks like we have some new faces around
Mr. Cheng and Mr. Peng
taxilian 08:09 yeah
do a twitter search for "FireBreath"
there are literally nearly 50 tweets from a chinese site about us
kalev 08:09 whoah, amazing
taxilian 08:09 amackera: do you have time to look at the mac crash reported today? I don't know if I'll get to it today or not
amackera 08:09 sure i'll take a look
taxilian 08:09 then I can focus what time I have on fixing the IE8 issue that Nikita reported
fix those things, then a 1.2.1 release mid-week is my hope
kalev 09:09 by the way, I see little point with the dev.firebreath branch
the way I think things should ideally work is like this:
each feature is developed in a separate clone
when done, it's merged into trunk
that way trunk is always reasonably stable
if you need to create stable bugfix releases, create a separate 1.2 branch and cherry-pick bugfixes to that branch from trunk
imho that scheme is much easier to follow than having a separate dev repo
taxilian 09:09 in general, I agree with you
the main reason I created the dev branch is to give me a place where I can stage things that I want to collaborate with someone on
to avoid creating dozens of branches for each feature
(exagerating, of course)
kalev 09:09 ah yes
amackera 09:09 i find hg branches to be pretty confusing
kalev 09:09 yeah, I see the problem -- others can't push to your personal clone
taxilian 09:09 it may end up only getting used as my primary development banch =]
amackera: agreed; that's why I'm not using them, and created the "dev" repository
it's kinda an experiment; we'll see how it goes
also, I've moved all the boost stuff into another repository, and I wanted the dev branch that we can all work out of a little bit to make sure that it is going to work as we expect
kalev 09:09 there's a small problem though: all the boost files are still in mercurial history, which makes cloning the repo slow as hell
if you intend to start keeping boost in a separate repo it might make sense to rewrite some of the main repo's history and strip boost out of it
it'll be pain for everyone who already has firebreath checked out though, almost as bad as switching to git :(
taxilian 09:09 actually, my experience so far is that switching to dev was completely painless
try it and let me know how it works for you
worst case is you do a new checkout
however, I agree with you on the speed issue; any idea how to strip out the history for those files?
kalev 09:09 I tried to do a new checkout and only annoying thing I noticed was that it printed out all filenames from the "external" boost repo when doing the clone
taxilian 09:09 yeah
but the main reason I decided to do it that way is because now the ohloh stats are accurate
and IMO that is worth the minor inconvenience
kalev 09:09 I'm sure history rewriting is possible and not too hard; I could do it easily with git but with mercurial I'd need to read some docs first
amackera 09:09 So I should check out the dev branch and push my changes to that and not trunk, yes?
taxilian 09:09 right
I will probably switch nightly to build off of dev instead of the primary
kalev: FWIW:
amackera 09:09 taxilian: the URL for dev is incorrect in the mailing list post
taxilian 09:09 is it?
amackera 09:09 it should be https
taxilian 09:09 oops
amackera 09:09 hmm
kalev 09:09 taxilian: you could use feature branches where others can push instead of dev too
amackera 09:09 nvm, works fine
kalev 09:09 I can already see lots of confusion where one should push stuff: dev or trunk
amackera 09:09 only pushes require https
kalev 09:09 taxilian: as in, Georg and Amackera are working on a new shiny mac feature and you create a "shinymac" official clone for them
when done, they merge it to trunk and delete the clone
random patches would still go to trunk
amackera 09:09 kalev: i think the problem is that the clone system is confusing to new users who are used to SVN
taxilian 09:09 kalev: general rule of thumb: unless you've checked with Georg or I, push it to dev =]
kalev 09:09 what's trunk used for then?
amackera 09:09 stable nightly builds
taxilian 09:09 in general, the only reason we would have you put something directly in trunk is if it is a small bugfix that will go into a special bugfix release
dev is the primary development branch
my goal has always been to have the main repository essentially "stable"
so that people can develop on it
but sometimes we need a slightly less stable branch where we don't worry as much when we push things to
and my hope is that everyone here will use that to develop against, knowing that in the case of a bug we will fix it quickly
for example, amackera's mac changes should have gone into something like the dev branch instead of staying to be tested in his repo for so long
but we didn't have it then
kalev 09:09 most projects I've worked with tend to do development in the main repo and have a separate branch for bugfix releases, as in there's trunk and 1.2 branch where you create 1.2.1, 1.2.2 etc releases
nitrogenycs 09:09 would you maybe want to switch the naming of dev and trunk?
taxilian 09:09 nitrogenycs: I don't think I can, TBH
nitrogenycs 09:09 Whenever I read trunk I think "that's the place where people put the hottest stuff and I know it might be broken"
amackera 09:09 think of how people will interface with the project
they land on the project page
go to source
checkout trunk
(or download the releases, let's ignore this for now)
if trunk is busted because of a 2AM commit, that results in a bad experience
taxilian 09:09 amackera: exactly my line of thinking
nitrogenycs 09:09 that's what I'd probably expect to happen
it's fine
to me at least
taxilian 09:09 tell ya'll what; I don't want this to be a big deal. Let's just try it this way for a release or two, and then if it turns out that it confuses people, we'll adjust
nitrogenycs 09:09 all I can say is that when i read about the dev/trunk stuff on the mailing list or here it seems quite confusing
amackera 09:09 sure
nitrogenycs 09:09 i think i understand it now though :)
taxilian 09:09 nitro: how do you think I could best clear up the confusion?
amackera 09:09 it's simple, there's a clone that we do all our development work on. think of it as replacing the existing trunk
when it's stable, we push to the real trunk
when we're ready for a release we tag and upload
but having said that, i don't care either way
like i'm not advocating for or against the existance of the dev clone
taxilian 09:09 the core idea here is that I want people to be able to use source control to update FireBreath
because I want them to be running on the latest release
but not neccesarily the latest "bleeding edge"
because using tarballs it is a pain to update FireBreath
nitrogenycs 09:09 ya, i can see, up to you really
it certainly makes sense
ya, i am using hg ever since
taxilian 09:09 to be clear, I appreciate the feedback and I'm not trying to be arbitrary; I just think I want to try it this way
nitrogenycs 09:09 sure
i don't really mind, just wanting to give feedback
taxilian 09:09 however, knowing that this is confusing is good; I'll keep an eye out for confusion and revisit the decision later
amackera 09:09 so for the time being, push changesets to dev? if it turns out it's too confusing we'll just merge to trunk, delete dev, and work on trunk?
taxilian 09:09 I appreciate that, and from you as well, kalev
amackera: something along those lines, yes
amackera 09:09 k
this safari crash is weird
taxilian 09:09 I believe you
have you tried taking out his embed tag to make sure it's not that?
I have no idea why he put it there...
amackera 09:09 A plugin inside a plugin inside a plugin inside a...
taxilian 09:09 the only thing I can figure out is that he meant is as a failover, in case something doesn't support object tag
amackera 09:09 Nope doesn't fix it
taxilian 09:09 was worth a try :-/
does the same problem occur on FBTestPlugin, and somehow I missed it?
(sorry, I'd try it myself, but I'm in class)
amackera 09:09 i'm going to try to figure out the cause of the crash, then we'll know if FBTestPlugin has the same bug
taxilian 09:09 ok
I was just thinking that if you could determine that it doesn't occur in FBTestPlugin, that would tell you that it is something related to the plugin configuration
amackera 09:09 Ahh good point
I'll try that out, I'm just going to reproduce the crash in my debugger
happens in FBTestPlugin also
taxilian 09:09 hmm
amackera 09:09 It's not consistently reproducable, and happens during deallocation
taxilian 09:09 ok
amackera 09:09 seems like an object is being referenced after dealloc, but... race condition? since it's not consistent
taxilian 09:09 so it is probably this issue:
amackera 09:09 same bug
taxilian 09:09 also worth looking at:
though I'm not as convinced that those are the same
however, the first one is absolute top priority; I'll probably try to get the IE thing fixed today, since I think it will probably be easy
but whatever I can do to help you figure this one out, we have to track it down
or it will absolutely kill us
amackera 09:09 happens in NPNFuncs.releaseobject()
taxilian 09:09 hmm
might be the same bug, then
as 24
see if you can catch a case in ReleaseObject where referenceCount > 10; it is probably corrupt
amackera 09:09 hmm referenceCount == 0, but it's still calling NPNFuncs.releaseobject()?
taxilian 09:09 that would also do it
amackera 09:09 perhaps it's as simple as changein to
taxilian 09:09 because when referenceCount hits 0, it will automatically release the object
ok, this is the same issue as 24, then
though they look different
amackera 09:09 if( NPNFuncs.releaseobject != NULL && npobj.referenceCount > 0) {
taxilian 09:09 anttix first reported it
kalev and I have discussed it
amackera 09:09 what's the verdict?
taxilian 09:09 the verdict is it doesn't make any sense
amackera 09:09 lol
taxilian 09:09 but it almost has to be something related to FireBreath specifically
because it doesn't happen otherwise
do you know what object NPN_Release is getting called on that causes it?
is it a javascript callback or one of ours?
actually, I guess it has to be one of ours
amackera 09:09 JSAPI
taxilian 09:09 JSAPI… but is it NPObjectAPI?
amackera 09:09 yes
taxilian 09:09 ok
that's what I expected
so, for testing
amackera 09:09 so what's happening here? we need to tell the browser that we're finished with our API object? so we call NPN_ReleaseObject?
taxilian 09:09 right
but for some reason, the reference count is already 0
amackera 09:09 ahh
taxilian 09:09 try this: put a printf statement in retain and release
print out the address of the NPObject in question
and the reference count
and the operation
in the short time needed to reproduce, there shouldn't be a ton of them
if they match up, it's a browser bug and we hack it to not usually happen
if they don't match up, we know it's our problem somewhere
amackera 10:09 sure, one question though: good idea
whoa sorryy lol
it's a good idea
one question though: does printf() work in safari OOP?
taxilian 10:09 hmm
I really don't know
amackera 10:09 i'll figure it out
taxilian 10:09 actually, I don't think it does
I seem to remember having that problem
grr. one of us needs to look into the boost logging abstraction =]
we really need those logs
amackera 10:09 i guess i could set a break point and write it out by hand :P
taxilian 10:09 so much to do and so little time
the more I think about it, though, the more I think this has to be our problem somehow
but I can't figure out how
but it happens on multiple browsers — it has been seen on Safari and Firefox
and it's a refcount on a browser-owned object
which doesn't crash if we're not involved
nitrogenycs 10:09 I am not sure if this is of any help to you:
taxilian 10:09 unfortunately, that places the blame squarely on code that I wrote =] but it's gotta be us
nitrogenycs 10:09 I have seen crashes like this in custom code with shared pointers. It happened when you created a smart pointer from a regular pointer. The ref count was not increased in this case. But the smart pointer tried to delete the object of course. The problem would only show up in the end when ref count was already 0 and another smart pointer tried to delete the object again.
taxilian 10:09 yeah; somewhere something like this must be happening
but we specifically wrap the NPObject in a NPObjectAPI that is, itself, reference counted
its destructor calls release, and then I believe NULLs out the NPObject pointer
so that should prevent it from releasing it twice
amackera 10:09 well from the Mozilla documentation it says: Decrements the reference count of the given NPObject. If the reference count reaches 0, the NPObject is deallocated by calling its deallocate function if one is provided; if one is not provided, free() is used.
could we just provide our own dealloc function?
taxilian 10:09 no; we aren't allowed to touch the NPObject except at creation time
rather, the NPClass
but if the NPObjectAPI calls retain when it grabs it and release when it is freed, we should be okay
unless something else is releasing it somewhere
in which case we need to figure out why
amackera 10:09 ok i'm setting up our sanity check
nitrogenycs 10:09 does the problem still appear if you retain it multiple times at creation?
taxilian 10:09 it becomes less prominent
but doesn't go away
nitrogenycs 10:09 that's strange
taxilian 10:09 anttix had a hack that he used that drastically reduced the occurance
it's attached to issue #24, I think
or #22
anyway, anyone want to volunteer to find us a logging abstraction to use with FireBreath?
amackera 10:09 aha
taxilian 10:09 I like "aha"
"aha" sounds hopeful
amackera 10:09 this obj's refcount is at 1069103
taxilian 10:09 that sounds a little high...
amackera 10:09 need to dig a bit more
lol i attached xcode debugger to by accident
taxilian 10:09 lol
amackera 10:09 and when i stopped it it killed my terminal
taxilian 10:09 it was actually pretty funny
need to dig a bit more
amackera left the room (quit: Quit: Lost terminal).
amackera 10:09 lol
taxilian 10:09 well, I better do homework first and firebreath later
so I'm going to go get it done so I have ti for my class today
be back later, guys
amackera 10:09 ttyl
taxilian 10:09 amackera: thanks for looking into that (though I suspect it affects your work plugin too, so it's definitely a good thing for you as well to get it fixed
amackera 10:09 no problem :) and you're right everybody wins
amackera 10:09 taxilian: I really can't figure this one out
I have some pretty big bug fixes i need to work on for the time being in my plugin
this'll have to get put on the backlog for now
taxilian 10:09 amackera: were you able to confirm whether or not the release was getting called the right number of times?
amackera 10:09 it seems to be, yes
taxilian 10:09 maybe a better question is: what (if anything) did you learn?
amackera 10:09 i have tried it several times in the debugger, and cannot seem to reproduce it
but as soon as i run it outside the debugger it happens once in a while
taxilian 10:09 hmm
amackera 10:09 and once the referenceCount of an object was waaay off, but it didn't crash
not very helpful, sorry :S
cygmatic 10:09 hi
amackera 10:09 hey :)
taxilian 11:09 amackera: thanks for looking into it
cygmatic: we really really need a logging system for FireBreath
cygmatic 11:09 amackera: ah, good to see you here... do you have your cmake linking lines for CA/CG/... handy? :)
taxilian 11:09 aren't they in the fbgen template?
cygmatic 11:09 taxilian: hm, nothing i could recommend from regular use
amackera 11:09 cygmatic: from FactoryMainMac?
cygmatic 11:09 no, they are not in the template
amackera: not the factories, the cmake stuff to link to the CA/CG frameworks and to the Objective-C runtime
amackera 11:09 oh sorry right
cygmatic 11:09 i always forget how this is done in cmake
taxilian: fwiw, the top suggestions here seem to be common:
amackera 11:09 cygmatic: one second, sorry
can i email them to you?
cygmatic 11:09 amackera: sure :)
amackera 11:09 just about to head to a meeting
taxilian 11:09 hmm. log4cxx looks good, except it requires the APR
I've been thinking about using the boost.log lib
cygmatic 11:09 boost.log looks nice enough and is at least provisionally accepted. it might still change a bit though for final acceptance into boost
taxilian 11:09 I may still pull it in; I need *something* to give me some help debugging things like this refcount bizarreness
cygmatic 11:09 ok, the dependencies don't look that light-weight though: "The logging library uses several other Boost libraries that need building too. These are Boost.Filesystem, Boost.System, Boost.DateTime, Boost.Thread and Boost.Regex."
taxilian 11:09 hmm. yeah; that would require a bit more work
cygmatic 11:09 hm, log4cxx with APR doesn't sound too nice, log4cpp is LGPL and log4cplus doesn't look as well documented
taxilian 11:09 you see my problem?
I guess we could roll our own, but I hate doing that
cygmatic 11:09 yep :/
taxilian 11:09 on the other hand, I'd kinda like to have those boost libraries usable by FireBreath plugins anyway
just not sure I want to completely require them
cygmatic 11:09 maybe trying to make the actual library opaque behind some macros and their use/linking optional works for now?
taxilian 11:09 that's kinda what I'm thinking
but even that sounds messy
we could certainly disable all firebreath built-in logging when not in debug mode by default
cygmatic 11:09 at least i wouldn't like to have those dependencies forced on me
taxilian 11:09 yeah
even if I include them in FireBreath (at what point does it stop making sense to extract things and make more sense to just link to the boost repo?), it seems silly to force everyone to use them
however, even if we were to roll our own, I don't see a good way around a dependency on filesystem and thread
thread is already a dependency, of course
cygmatic 11:09 right, filesystem isn't too heavy anyway i think
oh well, i don't have a good idea either... but rolling our own definitely isn't worth it
taxilian 11:09 hmm
cygmatic 11:09 by the way, would be putting library linking setup in NpapiPluginWindows cmake files the right place?
and should everything go first to dev now as the nightlies are built from there?
taxilian 11:09 yes, things should go first to dev
unless they need to be released sooner than what is in dev
what type of library linking stuff are you talking about?
cygmatic 11:09 the CoreAnimation, CoreGraphics, Objective-C runtime
taxilian 11:09 generally that needs to go into the project itself, unfortunately
however, there is a global place where you can probably add that...
look at
cygmatic 11:09 ah, ok
as those libs are required anyway with that configurations i think it should be done transparently
taxilian 11:09 agreed
amackera 11:09 hey bacj
taxilian 11:09 wb
cygmatic 11:09 cool, i can review myself on google code :D
i could review me with positive or negative scores
taxilian 12:09 lol
amackera 12:09 cygmatic: right, so, you needed cmake linking things?
just use find_library(FRAMEWORK_VAR FrameworkName)
like find_library(COCOA_FRAMEWORK Cocoa)
then target_link_libraries(${PROJNAME} ${COCOA_FRAMEWORK})
you'll need ApplicationServices, Foundation, and QuartzCore if you're using CoreAnimation
cygmatic 12:09 alright, thanks
amackera 12:09 as for the objc runtime...
i'm actually confused about this
i was under the impression that if the file extension was .m or .mm the runtime would get linked automagically
cygmatic 12:09 in my experience (and in the case of FB projects) not
amackera 12:09 well colour me confused
we need to link the objc library
cygmatic 12:09 great, i didn't have logging on... what where the needed libraries again? ^^
taxilian 12:09 [12:08:54] cygmatic: right, so, you needed cmake linking things?
[12:09:53] just use find_library(FRAMEWORK_VAR FrameworkName)
[12:10:04] like find_library(COCOA_FRAMEWORK Cocoa)
[12:10:31] then target_link_libraries(${PROJNAME} ${COCOA_FRAMEWORK})
[12:11:00] you'll need ApplicationServices, Foundation, and QuartzCore if you're using CoreAnimation
cygmatic 12:09 thanks
amackera 12:09 Ugh this InvalidatingCoreAnimation is annoying
it's a tiny, tiny change in normal CA
but it still requires it's own model negotiation
I'm thinking just assume that the user wants ICA, and negotiate that if they specify FBMAC_USE_COREANIMATION
and if it fails just default to normal CA
taxilian 12:09 sounds reasonable to me; looks like most browses don't intend to support the normal version going forward
amackera 12:09 Yeah, just Safari as far as I'm aware
taxilian 12:09 so I'm debating how critical having a threaded file logger is
hypothetically if your file logger is synchronous, it can slow down your program much more than an asynchronous file logger would
cygmatic 13:09 if the actual logging was opaque, one could have both (or just start with easier synchronization for now)
taxilian 13:09 true
which it should be
cygmatic 13:09 ... and later even thread-id logging etc. could be added to hunt weird bugs
taxilian 13:09 considering this:
that's another good point, though; the logger needs to be threadsafe
cygmatic 13:09 well, the fun part is that e.g. boost.log already supports things like syslog as a sink (afair)
taxilian 13:09 true
cygmatic 13:09 i don't think handling all those sinks is much fun
taxilian 13:09 and I'm betting it probably also supports the debug console sink on windows
long story short is that the boost one is probably the most complete
but also has a lot of dependencies
cygmatic 13:09 as it can be made optional, i guess the main question is: do we need the functionality of nice sink implementations etc.?
taxilian 13:09 I don't think we really *need* it, as long as we have support for the basics
since someone could always put in their own logging library
cygmatic 13:09 good point, maybe a sinking hook would be the best thing?
so we can optionally plugin e.g. boost.log for fb-test-builds and users whatever they already use?
taxilian 13:09 seems like it could potentially work well
cygmatic 13:09 so "standard fb macro" -> "fb logging core" -> "your sink of choice"
taxilian 13:09 in order to change it, you'd just define your own logging macro that is compatible, or some such
cygmatic 13:09 or register a logging sink function with, say, plugincore
taxilian 13:09 yeah
'course, not all logging functions work the same way
but they don't have to use our logging functions if they don't want to
cygmatic 13:09 right
differentiating between fb-internal and user messages would be good
either different sink functions or a flag
taxilian 13:09 some implementations use a string heirerchal system
something like "FB:CORE"
and you can set log level for "FB"
or for "FB:CORE"
that can be controlled seperately if desired
that can be really nice for testing
on the other hand, it may be overkill for what we need
cygmatic 13:09 ok, maybe starting with the basic opaque/sink concept and extending it later if the need arises?
if different macros for fb-internal and user log are used the implementation can later be changed transparently
taxilian 13:09 sounds like a good plan
cygmatic 13:09 amackera: it seems the other frameworks already pull libobjc.dylib in
amackera 13:09 I think that's why I wasn't seeing any linker errors before
taxilian 14:09 nirvdrum or cygmatic (or anyone else, I just think you two know the most about COM): any idea if there is a way to detect if CoInitialize has been called already on the current thread?
nirvdrum 14:09 No idea. Isn't that basically handled by the container?
cygmatic 14:09 me neither, but as long as the flags are the same and the calls are balanced with the right amount of couninitialize/counitializeex it doesn't hurt to call it again
taxilian 14:09 hmm
so here is the thing
cygmatic 14:09 nirvdrum, only for the main thread
taxilian 14:09 I found another way to say "call this IDispatch thing on the main thread"
but it requires that CoInitialize is called for the thread in question
however, it does *not* require a window
thus eliminating the need for one of the biggest hacks in the codebase
and allowing us to do events and callbacks from other threads on windowless IE plugins
nirvdrum 14:09 I just use ATL to handle my IDispatch stuff. It works pretty well.
Although I guess I really only expose IDispatch methods. I don't call any (don't need to, I have C++)
taxilian 14:09 right; but even with ATL, if you call IDispatch->Invoke(…) on a different thread it doesn't work
nirvdrum 14:09 I found with ActiveX I didn't need the callback / separate thread hack I needed for NPAPI.
I didn't really look into the execution semantics though.
cygmatic 14:09 if calling com methods from a thread that didn't coinitialize worked, its basically luck :)
nirvdrum 14:09 No, it was more like I could make a blocking call and not have the browser completely lockup.
cygmatic 14:09 taxilian, i don't see how we could correctly counitinialize on an arbitrary different thread
nirvdrum, ah, that works for STA models
or i think it should?
taxilian 14:09 nirvdrum: when I tried that it never even did anything; returned S_OK but nothing happened
well, that leaves us with either forcing them to use our thread abstraction or at least giving them ThreadInitialize() and ThreadDeinitialize() calls
nirvdrum 14:09 I have most of that open sourced, not using Firebreath at the moment:
cygmatic 14:09 taxilian, is there any real problem with creating a window for the "get on the main thread" at the moment?
taxilian 14:09 hypothetically, if we can leave it hidden when we have to, no
in fact, it might be the easier way to do it
but I don't actually know all that much about windows programming :-P
so I'm not sure how to do it
cygmatic 14:09 nirvdrum: yay for clean looking com code :)
but does that call com methods from another thread somewhere?
taxilian 14:09 if it does, and you don't do anything special to do so, it's not threadsafe; that much I know
cygmatic 14:09 taxilian, with the alternatives above i think the hidden window would be even the cleaner way to do it
nirvdrum 14:09 cygmatic: Nope. It's called from JS and blocks until it's complete. It's not great, but it's also taking a screenshot, so you really don't want the underlying HWND changing on you anyway.
taxilian 14:09 cygmatic: you could be right; are you sure a hidden window still gets the full event loop?
I guess it still ought to...
cygmatic 14:09 we have it in use somewhere for similar async calls
taxilian 14:09 then maybe we should create a hidden window even when we're not using it to draw
even when we have another window to draw
so that we always do it the same way
cygmatic 14:09 sounds reasonable
taxilian 14:09 any chance you could find me some sample code for that? =]
cygmatic 14:09 oh, googling my own knowledge is awesome ... first hit on google:
then some subclassing, e.g.:
and then send and handle some WM_FB_ASYNC_MSG
taxilian 14:09 lol
amackera 14:09 lol
taxilian 14:09 ok, fixing first problem first...
(unrelated to discussion at this point)
then I'll do that part
cygmatic 14:09 hm, does hg have any equivalent to "cvs diff --brief"?
i.e. showing only what files are different?
taxilian 14:09 you want to see the list of files, or the diff for those files?
it's been a long, long time since I used cvs =]
or even svn
cygmatic 15:09 the list of files
amackera 15:09 er, hg status?
minus the '?'
cygmatic 15:09 ah, of course, thanks
amackera 15:09 np
cygmatic 15:09 taxilian: think legacy cvs repositories with >10 years of history in them and the fear of porting this... ;)
amackera 15:09 taxilian: we should probably put some message on the project page about dev.firebreath, point people in the direction of the bleeding edge source
taxilian 15:09 yeah
so what do you guys think? should we have a nightly stable and a nightly dev?
or just a nightly dev?
amackera 15:09 hmm
ok, i've got to be doing this wrong
so i'm working away on my local hg clone
i think to myself "hey, let's pull the recent changesets from gcode!"
`hg pull`
sweet, a bunch of new changesets
now i try hg update, but i realize i have uncommitted changes
so i `hg commit`
but now my tip is my working copy, and the things i just pulled from gcode are no longer highest revision number
oh wait, nvm
so how do i hg update to the head i pulled from gcode, so as to merge my local changesets?!
ahh `hg update -r <rev>`
taxilian 15:09 hg merge
well, yeah, you can do that
but that loses your changesets
you can merge from either side
amackera 15:09 ohh really?
ok that solves the problem
as long as i commit my changesets, then when i update to an older revition i can still merge my other head
but if i can merge without updating that solves the problem
taxilian 15:09 well, you still need to commit your changesets, I believe
but I could be wrong
amackera 15:09 yes that's right
taxilian 15:09 the IE issue (as well as another one) is fixed
next I will look at the mac crash
that one really has me worried
amackera 15:09 taxilian: sorry i couldn't be of more help
it's a little over my head
taxilian 15:09 that's okay
you never did get any logging to work, did you?
amackera 15:09 nope
taxilian 15:09 I think I'm going to hack it for now
amackera 15:09 apart from breaking and using the anson-log-by-hand library
taxilian 15:09 and then work on a logging abstraction
amackera 15:09 yeah that's probably best
taxilian 15:09 to try to figure out what is actually happening
the ohloh stats are pretty fun, now that they don't include boost in the analysis
cygmatic 15:09 oh, now i have the fun part with merging the mac-stuff *g
amackera: we thought linking to the frameworks should happen transparently according to the FBMAC_USE_* flags... or do you see anything that wouldn't work nicely with that?
i.e. i have those now in cmake/
taxilian 15:09 ok, I did an early nightly 39 to make sure that nightlies are working correctly from dev
amackera 16:09 cygmatic: yeah that seems reasonable
amackera 16:09 well i'm off for the day, might be on later
see you guys :)
cygmatic 16:09 see you
cygmatic 16:09 ah, well... i read about the nightlies but i guess my mind was somewhere else ;)
oh, by the way... R in the ohloh stats comes from the mac resource files with the .r suffix
do you know where that one file with the boost license is?
taxilian 17:09 cygmatic: so my message-only window doesn't get called
any idea why?
the winproc is never called, I mean
cygmatic 17:09 right-away no - did you do the subclassing etc.?
taxilian 19:09 I found it
turned out first I wasn't setting up the window class correctly
and then second I wasn't calling DefWindowProc(..)
working now cygmatic
cygmatic 19:09 ouch
sounds like happy debugging
taxilian 19:09 not as bad as it could have been
at least the really weird problem (not calling DefWindowProc) I found quickly on google
it returns no error, but NULL from the CreateWindowEx call… :-P
taxilian 20:09 fixes for IE to use the messaging window are now in dev
that should make the windowless mode work better
cygmatic 20:09 nice
is there any known problem on the windows side regarding self-registration?
with vs2010
taxilian 20:09 using regsvr32, you mean?
not that I'm aware of
the only self-registration problem that I know of is on vs2005 the hack we put in makes it so that it doesn't work with WiX (MSI generation)
cygmatic 20:09 yes, just wanted to abuse fbtestplugin to test something and got 0x80070715
taxilian 20:09 from regsvr32?
cygmatic 20:09 which according to the igor (who apparently post on all things com) could mean that the rgs files are not included properly as resources
taxilian 20:09 hmm. vs2010? I just used it 5 minutes ago
and it worked fine for me
cygmatic 20:09 ok, i'll just try cleaning buildex and building anew - maybe i had some left-overs
taxilian 20:09 do you think it's safe to say that any value over 0xFFFF (65535) in the refcount field is an error of some sort?
cygmatic 20:09 yes
taxilian 20:09 thinking of even dropping off another bit or two
FFF is 4095
cygmatic 20:09 why?
taxilian 20:09 because the mac crash that was reported (issue #69) is that sometimes the reference count on objects from the browser is off
i.e. we'll go to release and refcount is 0
or it's 562804325
or so
it's one of the main reasons I want logging, to prove that it isn't us
cygmatic 20:09 is it internally signed or unsigned?
taxilian 20:09 unsigned, unfortunately
cygmatic 20:09 and you mean fbs ref-count?
taxilian 20:09 no, I mean the NPObject ref-count
uint32_t referenceCount
and this isn't on an object we created
cygmatic 20:09 ah
taxilian 20:09 it's on a JS method that was passed in
and retained
so I'm going to call retain 10x, then when we release, if the number isn't >= 10 and <= CUTOFF, I'm going to assign 0x0FFFFFFF (so it doesn't ever get released and possibly crash) and ignore it
dunno what else to do
it's a dirty hack; it's a variation on something that anttix came up with
I'm not at all happy with it
cygmatic 20:09 ok... things that come to mind: something was already deallocated/reused
taxilian 20:09 yeah; actually, maybe I better not try to change it
but I will ignore it
cygmatic 20:09 the data wasn't ever initialized
taxilian 20:09 most likely I think it was already deallocated
but as far as we can tell (and looking at NPObjectAPI this seems like the only possibility), the problem is in the browser
cygmatic 20:09 hm :/
taxilian 20:09 in fact, perhaps I'll just do something like "if (obj->referenceCount >= INC_NUM && obj->referenceCount <= INC_NUM * 5)" and only release if it matches that
I'd rather leak a small amount of memory than crash
cygmatic 20:09 not... nice :)
taxilian 20:09 I'm open to better ideas =]
Anson spent an hour on this today and finally gave up
cygmatic 20:09 could an nprelease be happening on another thread?
i.e. race conditions
taxilian 20:09 the only places in the entire code where we even call release is in NPObjectAPI and NpapiPlugin,
and keep in mind that I added checks to make sure that release is only called on the main thread
cygmatic 20:09 ok, this is weird... the clean vs2010 build failed to register too, but a clean vs2005 build worked
taxilian 20:09 there is an assertion whenever in debug mode
that is really weird
you're on dev?
cygmatic 20:09 no, thats the default repo
taxilian 20:09 hmm. try it from dev, see if that fixes whatever it is
if that doesn't work, we know it's something setup related, since mine does work
cygmatic 20:09 ok, but even with the main thread check, could there still be race conditions on release <-> deallocation?
taxilian 20:09 not in our code; we're only running on thread
could there be in the browser? well, maybe; if the browser is breaking NPAPI rules
NPN_ReleaseObject and NPN_RetainObject are only allowed to be called on the main thread
incidently, traffic on the project page is still around 150 / day since last week; Sunday it was only 101, but sundays are usually closer to 30...
taxilian 21:09 cygmatic: I am pushing dev into default
is that okay?
cygmatic 21:09 i'd think so
... was kvm'd away
tested with the dev-repo, same thing with regsvr32... i'm willing to blame it on a setup anomaly
taxilian 21:09 no prob
that is somewhat concerning, though
if you're having the problem, others might
unfortunately, the best way I know to track that down is to debug DllRegisterServer
and that's not a task I'd wish on anyone
cygmatic 21:09 i know, i did this once *g
taxilian 21:09 lol
cygmatic 21:09 traffic sounds good, though i was most surprised last week as i noticed the dev-group having nearly 100 members
taxilian 21:09 hehe
97 today
most of those don't ever post =]
cygmatic 22:09 but i assume they are there for a reason... either using it or taking a look at it
taxilian 22:09 one would hope, anyway =]
every so often, we get hints that a lot more people using it than we realize
cygmatic 22:09 oh?
taxilian 22:09 just people who suddenly speak up and ask about things that they are using
maybe not a lot more, but I'm sure there are more
cygmatic 22:09 ah, right
taxilian 22:09 so I'm going to have to implement getElementsByTagName in BrowserHostWrapper
on IE it won't let you call it properly on window
however, fortunately it wasn't difficult