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
