IRC Log Viewer » #firebreath » 2012-02-29

IRC Nick Time (GMT-7) Message
pkrumins 05:02 dougma: hey, yes browserling can do plugin testing if you get a dedicated plan
dougma: we have Windows 2003 Server and Windows 2008 Server
mkoch 07:02 hi!
if I need to start a static thread and keep it alive as long as at least one plugin instance is running, then destroy it after the last one has died (not necessarrily immediately), is the globalPluginInitialize() and globalPluginDeinitalize() in the Factory.cpp a good place to do it?
in which circumstances can the staticInitialize called more then once per process? (a code comment says it might happen)
linearray 07:02 yes/none
mkoch 07:02 pls explain :)
linearray 07:02 in my experience it just works
mkoch 07:02 okay
dougma 08:02 i had some problems today with not shutting my threads down fast enough for IE's liking
Jake__ 09:02 hey guys... little problem here... i keep getting an assertion failed... i don't even know what it means but everytime I execute a function from my plugin it keeps popping up
taxilian 10:02 well, what assertion is it?
linearray 10:02 dougma: but it killed the process then, right?
Jake__ 10:02 expression px!=0
taxilian 10:02 that means somewhere you're trying to USE a shared_ptr that is NULL
meh, caps accidental
connect a debugger and step up the stack to see which one
mkoch 10:02 if I set FF to run the plugins in the same process, then the StaticDeinitialize() will not be called until FF quits, right?
taxilian 10:02 well, that's not guaranteed, but it is likely
Jake__ 10:02 i really am not trying to use a shared_ptr
heck i don't even know where that is
linearray 10:02 mkoch: I made my own pluginCounter and when it hits 0, I unload my stuff
works well so far
mkoch 10:02 linearray: I already have one for other reasons, so I can use that then
linearray 10:02 there is already a pluginCounter in PluginCore but it's protected IIRC
mkoch 10:02 the bigger problem that my plugin crashes again during the Deinitialize and only in Safari, so I can't gdb it... :S
linearray 10:02 using a breakpoint doesnt work?
mkoch 10:02 I can't connect a debugger to it with 64bit safari
taxilian 10:02 yeah; annoying, huh?
linearray 10:02 and 32-bit?
mkoch 10:02 I must go for 64bit, my static lib I link to is 64bit
linearray 10:02 actually I use 64-bit safari and I can attach just fine
mkoch 10:02 linearray: how?
linearray 10:02 Attach to "PluginProcess" in xcode
mkoch 10:02 can you explain me in detail how to do it w. xcde 4?
xcode
linearray 10:02 yes
open xcode
open safari and open your page
attach to "PluginProcess"
(Product -> Attach to Process)
mkoch 10:02 yes, got it
cpu is on almost maximum usage now and Safari seems to be frozen
ch 10:02 well, attaching with gdb takes a while
lldb attaches faster, but crashes more often =)
mkoch 10:02 how can I tell it has attached?
ah I guess I can: plugin failure :D
ch 10:02 xcode should say "Running PluginProcess" in the status thingy
plugin failure is bad
give lldb a try if gdb doesnt attach in time
mkoch 10:02 now gdb managed to connect, I can see my beakpoints!
taxilian 10:02 yay!
mkoch 10:02 EXC_BAD_ACCESS :D
that's from where I continue tomorrow :)
bye!
taxilian 10:02 =] good luck
Jake__ 10:02 what could possibly be accessing a shared_ptr?? can anyone help me please?? i just know i didn't touch anything shared_ptr
taxilian 10:02 Jake__: attach a debugger, when the assertion fires you can see the stack trace
then you can walk up the stack to see what it is
Jake__ 10:02 alright i'll try that.. tnx
dreijer 13:02 taxilian: can I generate my firebreath projects in any destination folder I like?
I'd like to keep it outside of the firebreath dist
taxilian 13:02 you can move them after you generate them
I often put firebreath as a subdir to my project
then run ./firebreath/prepmac.sh . build/
dreijer 13:02 oh, I thought that wouldn't work because the vs projects puts the binary in a folder above the vs dir
taxilian 13:02 ? vs projects just go in the build dir
build/FireBreath.sln is what you should be loading, btw
in case you aren't and that's why you're confused
dreijer 13:02 yeah, according to the docs, it said I could just load the specific project if I didn't want to load everything else
taxilian 13:02 those docs should probably be fixed
it might work
but I don't recommend it
dreijer 13:02 it's worked so far, but ok :)
taxilian 13:02 it doesn't work on Mac, I can tell you that for sure
dreijer 13:02 so you're saying I can more the entire build dir then?
*move
taxilian 13:02 no, I'm saying you can delete the build dir and generate it somewhere else
dreijer 13:02 alright, so put firebreath inside my versioned tree and generate the files there
taxilian 13:02 I use it as a git submodule, so that's why I put it there
but you can put firebreath wherever you want
dreijer 13:02 right
taxilian 13:02 C:\firebreath\prep2010.cmd . build
etc
and the build dir can go wherever you want, just make sure you don't try to version it
dreijer 13:02 right
it was mostly because I really just wanted the vs project itself and the source files in my versioned tree, and everything else somewhere else
taxilian 13:02 the vs project itself *must not* be versioned
it is part of the build dir
you can generate it in your subdirectory, that's fine, but *don't* put it in source control
dreijer 13:02 why is it so bad to version the project files? Like if I wanted to add it to my own sln and build everything in one big swoop
taxilian 13:02 those are disposable; cmake generates them. They use absolute paths, for one thing. another is that anytime firebreath updates you may need to regenerate those files
dreijer 13:02 right
taxilian 13:02 they won't work on another computer because they have machine-specific stuff in them
some people do it even though I tell them not to
dreijer 13:02 so, about cmake
taxilian 13:02 to my knowledge nobody has ever still thought it was a good idea 6 months later
dreijer 13:02 my plugin is using a static library with some code shared with some other stuff I have. What's the best way to get that added to the auto generated cmake project (if possible at all)
taxilian 13:02 I'm on a call; give me a bit
dreijer 13:02 sure, np
taxilian 14:02 okay, back
dreijer 14:02 hey
taxilian 14:02 there are a few ways you can do it, but they all come down to figuring out where the static lib is and adding it to target_link_libraries for the plugin target
!wiki Libraries
FireBreathBot 14:02 8 results found. Note: Results limited to 8
"Using Libraries": http://goo.gl/cUVa6
"FireBreath Libraries": http://goo.gl/KqjOI
"Json": http://goo.gl/aWWju
"Re: Feedback": http://goo.gl/xZWWc
"Documentation To-Do": http://goo.gl/XzBGF
"Building on Mac OS X": http://goo.gl/iQ1mh
"FireBreath 1.5.0RC1 Released!": http://goo.gl/lppMa
"Helpful Links": http://goo.gl/vDlMu
dreijer 14:02 so if i put the cmake script under version control in my project folder, I ought to be able to point to the static lib with a relative path, I'd think?
taxilian 14:02 use ${CMAKE_CURRENT_BINARY_DIR} and ${CMAKE_CURRENT_SOURCE_DIR}
dreijer 14:02 to generate the full path, you mean?
taxilian 14:02 or to be relative
i.e. ${CMAKE_CURRENT_SOURCE_DIR}/../something/
dreijer 14:02 yeah, that's what I meant
let me try update the cmake file and see what happens
Binbo 18:02 how to end a boost thread that running infinite loop in it when the plugin shutdown?
it causing the plugin crashed when i reloaded the page
dougma 19:02 your thread should be listening for a stop signal
Binbo 19:02 for example?
dougma 20:02 thread() { while (!stop) { /* do stuff */ } }
Binbo 20:02 that means for my problem while(!pluginnotshutdown) rite?