IRC Log Viewer » #firebreath » 2011-06-09

IRC Nick Time (GMT-7) Message
_pq_ 08:06 How do i debug under linux
.
?
neilg_ 09:06 _pq_: You'll have to use GDB
If you start (from the command line) either Chrome or Chromium with the parameter --plugin-startup-dialog then the browser will halt every time a plugin loads and will display in the terminal the PID of the plugin process
You can then attach to that process using GDB
That SHOULD work just fine... though I haven't tried it
But that's how I debug on the Mac, I can't imagine it not working on Linux
_pq_ 09:06 I don't know how to do a debug build
Binaries I go seems to have no debug symbols
neilg_ 09:06 Pass in -O0 as a compilation flag to GCC
And possibly -G too
FuzzYspo0N 09:06 evening
neilg_ 09:06 I forget, I don't tend to use GCC from the command-line very often
Hey
Oh, it's lowercase - it's -g not -G
linearray 10:06 I found --plugin-startup-dialog not really useful, unless the plugin crashes right away or something
you can get the pid from ps aux or something
FuzzYspo0N 10:06 thats a god send in chrome, its annoying in firefox to have a long sleep
which reminds me
added a note to the wiki for firefox
ppsushi 11:06 Hi
FuzzYspo0N 11:06 hello
ppsushi 11:06 is there a way to install a timer under linux to get periodic events in the plugin?
FuzzYspo0N 11:06 in c++ ? sure.
ppsushi 11:06 yes c++
and how?
I can't find it in the doc....
FuzzYspo0N 11:06 the c++ doc? Or are you asking if the plugin API has a timer....
ppsushi 11:06 I looked the npapi doc
FuzzYspo0N 11:06 well, how periodical are these events?
ppsushi 11:06 30 times in a sec
more or less
FuzzYspo0N 11:06 it sounds like its just c++ you need.
Unless you have more info?
ppsushi 11:06 i want it to trigger a callback in the same thread i get mouse events from
don't care how i get it
in windows it's CreateTimer or so
in mac os is NSTimer scheduledTimerWithInterval or so
FuzzYspo0N 11:06 hmm, i have a crazy idea for you
since javascript is there and active, and its cross platform, maybe hook up a JS side event to c++ , and call setTimeout() inside the JS :)
ppsushi 11:06 go ahead
FuzzYspo0N 11:06 so the js runs the time -> calls c++ plugin handler
its simple, and cross platform
ppsushi 11:06 I can't do it 30 times in a sec...
FuzzYspo0N 11:06 uh, why not ? :)
ppsushi 11:06 good try anyway
FuzzYspo0N 11:06 Games run at 60 fps
entire games... not just simple callbacks
ppsushi 11:06 I tried something like that yet
but the javascript calls are too slow
FuzzYspo0N 11:06 hmm
ppsushi 11:06 just gettin' the mouse move in tis way il too slow for us
any idea?
FuzzYspo0N 11:06 like i said, it sounds like a simple timer class. You even mentioned API's by name :) I would implement or look for a cross platform timer ( or make a simple one using std::clock or something )
I don't know the api well enough to know if it has anything like that
ppsushi 11:06 thanks, I will investigate it
neilg_ 12:06 I'm so confused, FireBreath isn't doing the right thing for Core Animation according to the NPAPI spec. Except if we're in Safari 32-bit. Bizarre. And, I suspect, a bug since with Chromium I see the layer get deallocated... and then still used. Ugh!
sabotaged|wk 12:06 explain more?
neilg_ see if what you're seeing is related to this: http://jira.firebreath.org/browse/FIREBREATH-95
FireBreathBot 13:06 FIREBREATH-95: Summary: MyCALayer over release on 64-bit Safari
FIREBREATH-95: Assigned To: richard
FIREBREATH-95: Priority: Major, Status: Open, http://jira.firebreath.org/browse/FIREBREATH-95
neilg_ 13:06 I think it's very related, yes
I'm tracking down an error where if I go onto a page with a CA plugin, click back, click forward then nothing is rendering in the 2nd instance
Though I just changed it to retain the layer in PluginWindowMacCA::GetValue(...) and it still deallocates the layer
Seems... wrong
sabotaged|wk 13:06 hmm, well making it retain there fixed the issue for me
do you ever release or retain that layer in your plugin code?
neilg_ 13:06 Nope
Never
And the callstack makes it look like Chromium itself is releasing the layer!
sabotaged|wk 13:06 it doesn't crash? just doesn't draw properly?
neilg_ 13:06 No crash. But I want to be explicit: It's deallocing the layer for the very first instance. It does this very early on too! It's just the second one that shows symptoms of errors!
This could be a Chromium issue itself though - not helped by the issue in FB
sabotaged|wk 13:06 very early? when
neilg_ 13:06 Hmm, right after the 2nd onWindowResized message is handled
So the first message passes in 0x0 as the resolution, the 2nd call passes in the _actual_ resolution... And then Chromium releases the layer and I see the dealloc called on MyLayer
sabotaged|wk 13:06 this is on the 2nd navigation to plugin page?
neilg_ 13:06 No
sabotaged|wk 13:06 oh
neilg_ 13:06 Safari doesn't do that so... probably a Chromium bug.
So, probably red herring - I'm still seeing the 2nd instance not work even in Safari. Depressing!
sabotaged|wk 13:06 yeah, i think there's something screwy with chrome around this
i saw crashing in core animation drawing on my 2nd instance sometimes, other times an over release of the 1st layer
what firebreath version are you using
neilg_ 13:06 The latest in master. Well, the latest in master as of Monday anyway
sabotaged|wk 13:06 oh wait.. i was seeing this issue in safari, not chrome
might be related
neilg_ 13:06 I think it is. I'm looking into it some more anyway but it's very odd! I was using Chromium because it's easy to debug the plugin but for now I'm just relying on logging. log4cplus is pretty useful!
sabotaged|wk 14:06 i've only been able to attach to safari 64-bit if my plugin is also built 64-bit
neilg_ 15:06 Huzzah!
Now I understand the problem
FuzzYspo0N 15:06 oh?
neilg_ 15:06 I'm using CA and not ICA. CA itself has a timer that tells the browser to update. If I hit back and then forward, that timer is still using the old layer...
But if I hit back, wait, then hit forwards - works.
That along with the fix making it retain the layer means this works now!
sabotaged|wk 15:06 oh, cool
neilg_ 15:06 Or somehow StopAutoInvalidate() gets called when it should be starting - it gets confused somehow when you do that
6/9/11 5:54:09 PM com.apple.WebKit.PluginAgent[18328] 06-09-11 17:53:54,000 [0xa05f6540] INFO FireBreath <> - /tmp/sandstone.LQdl6ht0/sandstone/plugin/firebreath/src/PluginCore/PluginCore.cpp:40 - static void FB::PluginCore::setPlatform(const std::string&, const std::string&) - os: 0xbfffe30c; browser: NPAPI
6/9/11 5:54:09 PM com.apple.WebKit.PluginAgent[18328] 06-09-11 17:53:54,000 [0xa05f6540] INFO FireBreath <> - /tmp/sandstone.LQdl6ht0/sandstone/plugin/firebreath/src/PluginAuto/Mac/PluginWindowMac.mm:100 - bool initPluginWindowMac_CG(const FB::Npapi::NpapiBrowserHostPtr&, NPDrawingModel&) - NPDrawingModel=NPDrawingModelCoreGraphics
6/9/11 5:54:09 PM com.apple.WebKit.PluginAgent[18328] 06-09-11 17:53:54,000 [0xa05f6540] INFO FireBreath <> - /tmp/sandstone.LQdl6ht0/sandstone/plugin/firebreath/src/PluginAuto/Mac/PluginEventMac.cpp:72 - static NPEventModel FB::PluginEventMac::initPluginEventMac(const FB::Npapi::NpapiBrowserHostPtr&, NPDrawingModel) - NPEventModel=NPEventModelCocoa
6/9/11 5:54:09 PM com.apple.WebKit.PluginAgent[18328] 06-09-11 17:53:54,000 [0xa05f6540] INFO FireBreath <> - /tmp/sandstone.LQdl6ht0/sandstone/plugin/firebreath/src/PluginAuto/Mac/NpapiPluginMac.mm:141 - virtual int16_t FB::Npapi::NpapiPluginMac::GetValue(NPPVariable, void*) - GetValue(NPPVpluginScriptableNPObject)
sabotaged|wk 15:06 what happens when you don't have that retain?
neilg_ 15:06 6/9/11 5:54:09 PM com.apple.WebKit.PluginAgent[18328] 06-09-11 17:53:54,000 [0xa05f6540] INFO FireBreath <> - /tmp/sandstone.LQdl6ht0/sandstone/plugin/firebreath/src/PluginAuto/Mac/PluginWindowMac.mm:305 - virtual void FB::PluginWindowMac::StopAutoInvalidate() - AutoInvalidate STOPPED
6/9/11 5:54:11 PM com.apple.WebKit.PluginAgent[18328] 06-09-11 17:53:54,000 [0xa05f6540] INFO FireBreath <> - /tmp/sandstone.LQdl6ht0/sandstone/plugin/firebreath/src/PluginCore/PluginCore.cpp:40 - static void FB::PluginCore::setPlatform(const std::string&, const std::string&) - os: 0xbfffe30c; browser: NPAPI
Ugh... Sorry, that was formatted pretty terribly...
It can (and does sometimes!) crash on exit
Besides, the NPAPI spec specifically states that the plugin should retain it before sending it to the browser
So why we don't... I don't understand.
I suspect a workaround had been put in to deal with buggy browsers - just a suspicion
sabotaged|wk 15:06 yeah it says that, but we retain it when we create it
but it's strange it says to retain and release on npp destroy, because you'd think that wouldn't matter if your plugin already has it retained
neilg_ 15:06 Well, we didn't retain it when we create it if we weren't Safari, that's the point
sabotaged|wk 15:06 in the constructor of PluginWindowMacCA it's [[MyCALayer layer] retain]
neilg_ 15:06 Which branch are you in?
sabotaged|wk 15:06 1.5
neilg_ 15:06 Because I'm on master and I see that line... inside an if statement that only does that for Safari
And it doesn't retain it if it isn't Safari
And that's just wrong.
sabotaged|wk 15:06 you're in the constructor? or GetValue
neilg_ 15:06 Oh, sorry, that was in GetValue
sabotaged|wk 16:06 but yeah, it almost seems like the docs imply double retaining it (once upon initialization, then again upon giving it to the browser)
neilg_ 16:06 Yes, that's true
But I've definitely seen it crash with the obj_selector looking for release on an object that clearly wasn't retained :)
(in Chromium)
sabotaged|wk 16:06 it would be good to leave a comment here http://jira.firebreath.org/browse/FIREBREATH-95
FireBreathBot 16:06 FIREBREATH-95: Summary: MyCALayer over release on 64-bit Safari
FIREBREATH-95: Assigned To: richard
FIREBREATH-95: Priority: Major, Status: Open, http://jira.firebreath.org/browse/FIREBREATH-95
neilg_ 16:06 Hmm, maybe THAT is a bug in Chromium
Because it does seem that the plugin just needs to retain it once and release it in NPP_Destroy()
And perhaps Chromium actually tried to release the layer
sabotaged|wk 16:06 i don't know where webkit shared code fits into this, but safari 64-bit seems to have the exact same issue, where i see an over release
neilg_ 16:06 Okay, so perhaps that's what is happening - the browser isn't obeying the spec and they release the layer. Hmm...
neilg_ 16:06 Hahahaha, I think I understand that bug (FIREBREATH-95)
FireBreathBot 16:06 FIREBREATH-95: Summary: MyCALayer over release on 64-bit Safari
FIREBREATH-95: Assigned To: richard
FIREBREATH-95: Priority: Major, Status: Open, http://jira.firebreath.org/browse/FIREBREATH-95
neilg_ 16:06 Damn you FireBreathBot
It's the timer if you're using CA. It has another reference - so if you hit back then forwards fast enough the timer hasn't stopped (and a new one doesn't get created) and it gets very confusing
And it's the same issue hitting me right now
So, um, I'll just fix it
Well, I will if Xcode decides to unfreeze at some point today
Well, that's my theory anyway. If the BasicMediaPlayer uses ICA then I'm clearly wrong...
sabotaged|wk 16:06 StartAutoInvalidate?
neilg_ 16:06 Yep
sabotaged|wk 16:06 i don't use that
and chrome should use ICA anyways right?
neilg_ 16:06 It does but FB supports both CA and ICA and uses the timer for CA to tell the browser to update
And if you use CA you don't have a choice, that's how it works! :)
sabotaged|wk 16:06 so you aren't using ICA for chrome?
neilg_ 16:06 No
I want to (of course) but our multi-threaded game engine wasn't set up to tell the plugin to render
Damnit, I'm wrong. I thought it was using StartAutoInvalidate() automatically
Well, back to the drawing board. I was quite excited then!
sabotaged|wk 16:06 heh
neilg_ 16:06 Damn damn damn. I don't understand why, if I wait, hitting back and then forwards works perfectly
sabotaged|wk 16:06 how long do you wait?
neilg_ 16:06 5 seconds? Something like that
Not too long
sabotaged|wk 16:06 hmm, i tried removing the retain and waiting 10 seconds, but it still crashed
neilg_ 16:06 Yeah, it definitely needs it. But... it shouldn't. Now I understand why that code was put in - it's just to hack around Safari not obeying the NPAPI spec. :(
sabotaged|wk 16:06 one thing that taxilian suggested is placing an autorelease pool around init of MyCALayer. that should at least make the autorelease a bit more deterministic
neilg_ 16:06 Hmm. It would have to exist while the plugin existed - but that wouldn't be so bad either
Could create one in my constructor and free it in the destructor. That's not a bad suggestion...
Well, I'm off home now - feeling depressed for being completely wrong. :)
sabotaged|wk 16:06 you only need to place it around that one initialization line
since there is a retain there anyways
FuzzYspo0N 18:06 anyone familiar with the wix stuff?