Re: [opensource-dev] Linux x64 - libmedia_plugin_cef.so error
On 2018-03-23 02:00, Henri Beauchamp wrote: > #elif defined(__linux__) > CefString(_subprocess_path) = "dullahan_host"; > #endif > > > Henri. Well that certainly got me further! Thank you! Its' at least _trying_ to start dullahan_host now, but some strange behavour: alex@desktop:~/ivyviewer$ grep dullahan trace.txt | pcregrep -o1 '.*(execve\([a-z0-9\/_\"]+),' execve("/usr/local/sbin/dullahan_host" execve("/usr/local/bin/dullahan_host" execve("/usr/sbin/dullahan_host" execve("/usr/bin/dullahan_host" execve("/sbin/dullahan_host" execve("/bin/dullahan_host" execve("/usr/games/dullahan_host" execve("/usr/local/games/dullahan_host" execve("/snap/bin/dullahan_host" It is trying to launch it from the wrong place... lol! I am guessing I have failed to set some setting for dullahan somewhere or something silly like that. Looks like I have some more debugging to do. -- Kind Regards, Alex. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Linux x64 - libmedia_plugin_cef.so error
On 2018-03-23 02:00, Henri Beauchamp wrote: > On Fri, 23 Mar 2018 01:48:08 +1000, Alex wrote: > >> It does indeed sound like the viewer is subsequently spawning another >> SLPlugin instead of dullahan_host, you are right. I have no idea why >> the >> viewer would be doing that. From what I am aware, the viewer _should_ >> start one instance of SLPlugin and dullahan_host when its at the login >> screen. >> >> Do you have a rough idea (assuming the standard LL viewer behavior) >> where these processes get launched from on startup (which part of the >> viewer code)? > > In fact, the viewer (and SLPlugin) code itself got no knowlegde of > dullahan_host: the latter is launched (and gets passed arguments) by > CEF, from a setting given in dullahan_impl.cpp, in > dullahan_impl::init() > > My guess is that your plugin lacks a #elif defined(__linux__) and the > corresponding CefString(_subprocess_path) there. > Here is what I put in mine: > #elif defined(__linux__) > CefString(_subprocess_path) = "dullahan_host"; > #endif > > Henri. Ahhh!!! Thats going to be what it is for sure! I am missing that part in mine.. and it explains why I found no reference to the dullahan_host in my strace data.. Not even attempt to start it. It all makes sense now. Thank you so much! I'll rebuild the plugin and the viewer and see how that goes. -- Kind Regards, Alex. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Linux x64 - libmedia_plugin_cef.so error
On Fri, 23 Mar 2018 01:48:08 +1000, Alex wrote: > It does indeed sound like the viewer is subsequently spawning another > SLPlugin instead of dullahan_host, you are right. I have no idea why the > viewer would be doing that. From what I am aware, the viewer _should_ > start one instance of SLPlugin and dullahan_host when its at the login > screen. > > Do you have a rough idea (assuming the standard LL viewer behavior) > where these processes get launched from on startup (which part of the > viewer code)? In fact, the viewer (and SLPlugin) code itself got no knowlegde of dullahan_host: the latter is launched (and gets passed arguments) by CEF, from a setting given in dullahan_impl.cpp, in dullahan_impl::init() My guess is that your plugin lacks a #elif defined(__linux__) and the corresponding CefString(_subprocess_path) there. Here is what I put in mine: bool dullahan_impl::init(dullahan::dullahan_settings& user_settings) { DLNOUT("dullahan_impl::init()"); #ifdef WIN32 CefMainArgs args(GetModuleHandle(nullptr)); #else CefMainArgs args(0, nullptr); #endif CefSettings settings; // point to host application #ifdef WIN32 CefString(_subprocess_path) = "dullahan_host.exe"; #elif __APPLE__ NSString* appBundlePath = [[NSBundle mainBundle] bundlePath]; CefString(_subprocess_path) = [[NSString stringWithFormat: @"%@/Contents/Frameworks/DullahanHelper.app/Contents/MacOS/DullahanHelper", appBundlePath] UTF8String]; #elif defined(__linux__) CefString(_subprocess_path) = "dullahan_host"; #endif // Do not bother with the stupid sandbox which keeps failing under Windows // and which must be set UID root under Linux... settings.no_sandbox = true; .../... Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Linux x64 - libmedia_plugin_cef.so error
On Thu, 22 Mar 2018 16:31:29 +0100, Henri Beauchamp wrote: > In my viewer, SLPlugin is never passed any other argument than the port, > so maybe these arguments you see passed are an "extension" to Firestorm's > plugin system... In fact, looking at the processes for a viewer on at login sceen step, I get: 4283 ?S 0:00 /bin/bash /usr/local/CoolVLViewer-1.26.21/cool_vl_viewer 4309 ?SLl0:02 ./bin/cool_vl_viewer-bin 4326 ?Sl 0:00 /usr/local/CoolVLViewer-1.26.21/bin/llplugin/SLPlugin 41321 4330 ?S 0:00 /usr/local/CoolVLViewer-1.26.21/bin/llplugin/dullahan_host --type=zygote --no-sandbox --log-file=/root/.secondlife/ --product-version=(Dullahan:1.1.1080 [64bit] - SecondLife/1.26.21.14 (Cool VL Viewer; default skin)) Chrome/65.0.3325.146 [64bit] - 4356 ?Sl 0:00 /usr/local/CoolVLViewer-1.26.21/bin/llplugin/dullahan_host --type=renderer --no-sandbox --disable-gpu-compositing --service-pipe-token=3FECC7FC7B452E7F87FF8F85FB58EB32 --lang=en-US --log-file=/root/.secondlife/ --product-version=(Dullahan:1.1.1080 4357 ?Sl 0:00 dullahan_host --type=gpu-process --no-sandbox --log-file=/root/.secondlife/ --product-version=(Dullahan:1.1.1080 [64bit] - SecondLife/1.26.21.14 (Cool VL Viewer; default skin)) Chrome/65.0.3325.146 [64bit] --lang=en-US --gpu-preferences=KA So, the argument you are seeing are actually dullahan_host ones ! Could it be that your viewer launches SLPlugin instead of dullahan_host ? Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Linux x64 - libmedia_plugin_cef.so error
On Thu, 22 Mar 2018 23:39:51 +1000, Alex wrote: > 2018-03-22T10:08:12Z llplugin/slplugin/slplugin.cpp(194) : error > 2018-03-22T10:08:12Z ERROR: llplugin/slplugin/slplugin.cpp(194) : main: > port number must be numeric > .../... > 4589 execve("/home/alex/ivyviewer/bin/SLPlugin", > ["/home/alex/ivyviewer/bin/SLPlugin", "38655"], [/ 66 vars /] > > 4592 execve("/home/alex/ivyviewer/bin/SLPlugin", > ["/home/alex/ivyviewer/bin/SLPlugin", "--type=zygote", "--lang=en-US", > "--log-file=/home/alex/ivyviewer/bin/debug.log", > "--product-version=(Dullahan:1.1.820 [64bit] - SecondLife/5.1.3.54978 > (Firestorm-private-x64build; firestorm skin)) Chrome/59.0."...], [/ 69 > vars /] > > I am seeing SLPlugin called once correctly, with the port number it > expects, then it is being called a second time with data that it is not > expecting, thus the error condition is triggered in slplugin.cpp > > I know this is a bit of a shot in the dark but can you think of any > possibilities why this could happen? Hard to tell without having the sources to look at, but to me, it would appear like an arguments quoting or missing argument issue in the command line passed to SLPlugin... In my viewer, SLPlugin is never passed any other argument than the port, so maybe these arguments you see passed are an "extension" to Firestorm's plugin system... You'll have to follow the track in the code, starting from LLViewerMedia, then LLPluginClassMedia, LLPluginProcessParent, LLProcessLauncher, etc... Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Linux x64 - libmedia_plugin_cef.so error
On 2018-03-21 19:30, Henri Beauchamp wrote: > Yes, under Linux, ld uses the provided library and searches for > , lib.so, lib.a, etc... > > But your problem was related to a bad call in your plugin (did you read > my message dated Wed, 21 Mar 2018 00:43:41 +0100 ?). Hi Henri, I saw it. Ive resolved the loading issues of the plugin not loading. I no longer see symbol errors. I have no working media still which is strange. I did notice an error in the log which looked suspicious so hopefully I am going down the right path here with troubleshooting it... I notice there are no instances of SLPlugin running when my viewer starts, or any instance of dullahan_host, that immediately got me suspicious. This is the error I saw in the log: 2018-03-22T10:08:12Z llplugin/slplugin/slplugin.cpp(194) : error 2018-03-22T10:08:12Z ERROR: llplugin/slplugin/slplugin.cpp(194) : main: port number must be numeric I've looked at the code in slplugin.cpp and see this: #elif LL_DARWIN || LL_LINUX if(argc < 2) { LL_ERRS("slplugin") << "usage: " << argv[0] << " launcher_port" << LL_ENDL; } U32 port = 0; if(!LLStringUtil::convertToU32(argv[1], port)) { LL_ERRS("slplugin") << "port number must be numeric" << LL_ENDL; } So the argc count is being satisfied... and obviously some parameter is being sent that obviously is not numeric and throwing the error. I ran the viewer under strace and observed some interesting behavior: 4589 execve("/home/alex/ivyviewer/bin/SLPlugin", ["/home/alex/ivyviewer/bin/SLPlugin", "38655"], [/ 66 vars /] 4592 execve("/home/alex/ivyviewer/bin/SLPlugin", ["/home/alex/ivyviewer/bin/SLPlugin", "--type=zygote", "--lang=en-US", "--log-file=/home/alex/ivyviewer/bin/debug.log", "--product-version=(Dullahan:1.1.820 [64bit] - SecondLife/5.1.3.54978 (Firestorm-private-x64build; firestorm skin)) Chrome/59.0."...], [/ 69 vars /] I am seeing SLPlugin called once correctly, with the port number it expects, then it is being called a second time with data that it is not expecting, thus the error condition is triggered in slplugin.cpp I know this is a bit of a shot in the dark but can you think of any possibilities why this could happen? Just thought I would ask since I am all out of ideas at this point. -- Kind Regards, Alex. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges