Cool VL Viewer forum

View unanswered posts | View active topics It is currently 2017-05-23 20:41:59



Reply to topic  [ 7 posts ] 
Running without the SUID sandbox! 
Author Message

Joined: 2017-04-05 23:56:46
Posts: 5
Reply with quote
Hi Henri, I wasn't sure weather to mail you directly or use a forum - but I decided on the latter in order not to be too intrusive ;).
And now maybe someone else may lend a hand as well (not to mention that this conversation will be archived).

The reason I contact you about this is because I believe you are the only competent coder left that works on SecondLife.
I've always admired you concise emails; and I remember that in the past I've told Oz that if you write to their mailinglist
he should take the time to take it all very serious, because what you have to say matters.

Hopefully you remember me too ;) I'm Aleric Inglewood -- I started coding for LL's main viewer, then Snowglobe,
and after they SUDDENLY released Viewer 2 which then turned out to not have ANY of our improvements and
patches that were put in Snowglobe over a YEAR... I even stayed and started porting my code to Viewer 2, again,
because they also changed opensource manager (Oz) and he made beautiful promises that I fell for (again).
But since soon they started to ignore (not merge) even my second generation snowglobe patches for 2 months
I had seen enough and went on to work for a third party viewer: Imprudence. I coded for them quite a while, until
at some point it was made clear to me that I was not considered part of the "core team" and therefore not
entitled to be part of ANY decision making whatsoever (which strikes me as weird for a coder of my caliber who
works full-time on a project). So, next was Singularity, which I joined about half a year after it was started. I put
YEARS of my life into that viewer; mostly working on stability and robustness issues; if I wasn't swamped with
fixes regression bugs introduced by Linden Lab (literally all bugs come from LL). Also this wasn't meant to last:
what happened here is that the HTML download code was SO bad that it needed a rewrite. By the time I was
done with that (a full year later), LL SUDDENLY threw their version over the wall-- but fortunately Siana was
convinced my version is indeed better and we went with that (and it is). Something went wrong between Liru
and me though; at first he was an 18 y/o noob with no experience, but over time he became more and more
arrogant (ignoring the fact that I'm like you a senior coder with decades of experience). While I have to opinion
"the less Linden code the better" (no need anymore to merge, bug fix or worry about some part of the code),
he saw the large amount of code that I wrote as redundant. The main problem was that for some unknown
reason he became the, eventually, the guy who would do the git merges (Siana being sick often and stuff).
He hinted that my 1 year-work of http code might have to be replaced with LL's shitty code because they
were going to support http pipelining... I took this seriously, so I added http pipelining support to my code,
for which I had to fix a LOT of bug in libcurl itself (do NOT attempt to use http pipelining unless you use my
version of libcurl). However, now I just wasted another year of my life; because he kept saying he was busy
with other stuff and was going to merge it later... for half a year long. At that point I left Singularity too.
That was 2 years ago.

(PS If you're interested then I might be willing to give you a helping hand with Cool Viewer; ie, stuff like
linux 64bit support, and adding my http pipelining support to it ;).

Using a (Singularity based) viewer with many custom stuff, I kept using my own viewer without upgrading
for the past 2 years; but eventually the bento extensions has forced me to port all my code to the current
singularity viewer code. Their code is a mess... I spent the past two weeks on fixing linux 64bit stuff :/.

The one thing that I can't seem to figure out is the error that I'm getting of the topic of this post.

Full excerpt of debug output being:

[code]Calling ::execv("/opt/secondlife/viewers/singularity/SingularityViewer/linden/build-linux-x86_64/newview/packaged/bin/SLPlugin", "/opt/secondlife/viewers/singularity/SingularityViewer/linden/build-linux-x86_64/newview/packaged/bin/SLPlugin", "44160") with DISPLAY=":0.0"
VIEWER : 2017-04-06T12:34:21Z INFO: read_pipe: Received: "CALLING EXECV" (bytes read: 13)
SLPlugin RCFILE : /home/carlo/.libcwdrc:11: channels_on = malloc,viewer,notice,warning,backtrace
SLPlugin RCFILE : Turned on MALLOC
SLPlugin RCFILE : Turned on VIEWER
SLPlugin RCFILE : Turned on NOTICE
SLPlugin RCFILE : Turned on WARNING
SLPlugin RCFILE : Turned on BACKTRACE
SLPlugin RCFILE : /home/carlo/.libcwdrc:19: gdb = /usr/bin/gdb
SLPlugin RCFILE : /home/carlo/.libcwdrc:20: xterm = konsole --nofork --workdir "$PWD" --geometry 165x24-0+0 -e %s
VIEWER : 2017-04-06T12:34:23Z INFO: LLPluginProcessParent::receiveMessage: plugin version string: CEF plugin 1.1.3
VIEWER : 2017-04-06T12:34:23Z INFO: LLPluginProcessParent::receiveMessage: message class: base -> version: 1.0
VIEWER : 2017-04-06T12:34:23Z INFO: LLPluginProcessParent::receiveMessage: message class: media -> version: 1.0
VIEWER : 2017-04-06T12:34:23Z INFO: LLPluginProcessParent::receiveMessage: message class: media_browser -> version: 1.0
[0406/143423:ERROR:browser_main_loop.cc(203)] Running without the SUID sandbox! See https://code.google.com/p/chromium/wiki ... evelopment for more information on developing with the sandbox on.[/code]

(I'm using libcwd for debugging, the 'VIEWER' channel being the normal viewer debug output)

Of course I did my research -- the bottom line being that the whole chrome-sandbox isn't necessary anymore (since June 2016 or so)
to begin with; but well - even after chown-ing root and chmod-ing 4755 chrome-sandbox I still get that error while I think I shouldn't.

Hence, I think I'll have to compile CEF myself and debug it. Unless you have another idea of
what might possibly be wrong here :/

I found your excellent posts https://lists.secondlife.com/pipermail/ ... 10106.html
and https://lists.secondlife.com/pipermail/ ... 10121.html

A question I have is, how can it be that LL ever released a package that would be as broken as you
described? Isn't it possible that their viewer, and possibly other viewers need tcmalloc to be compiled
into libcef.so / libllceflib.a ?

The package that singu is using is http://depot.alchemyviewer.org/pub/linu ... 00.tar.bz2
which contains

[code]>nm -C lib/debug/libcef.so | grep 'malloc$'
0000000002528020 t av_fast_malloc
00000000024d17e0 t av_fast_padded_malloc
0000000002527240 t av_malloc
U g_malloc
U __libc_malloc
0000000000e94de0 T malloc
0000000001612db0 t sk_data_new_from_malloc
0000000002d8be40 t sqlite3_malloc
0000000004fee4f0 t vpx_malloc
0000000001b342c0 t wk_png_malloc[/code]

Note sure if that means that tcmalloc is still compiled in here - but
it seems so because it defines a 'malloc' function :/.
If that really wrong that why is it working for most people (or is it ;)?

Thanks for any help / hints you can give me,
Aleric


2017-04-06 15:03:18
Profile

Joined: 2009-03-17 18:42:51
Posts: 3558
Reply with quote
Quote:
A question I have is, how can it be that LL ever released a package that would be as broken as you described? Isn't it possible that their viewer, and possibly other viewers need tcmalloc to be compiled into libcef.so / libllceflib.a ?
LL doesn't provide a Linux viewer with CEF support. That's how they "dealt" with it. I described the problem on the mailing list, gave all the necessary pointers and even provided recipes and patches to fix it and implement Linux support. But LL simply decided that supporting Linux was not worth it... Shame on them.

Quote:
The package that singu is using is http://depot.alchemyviewer.org/pub/linu ... 00.tar.bz2
which contains
.../...
Note sure if that means that tcmalloc is still compiled in here - but it seems so because it defines a 'malloc' function :/.If that really wrong that why is it working for most people (or is it ;)?
As for other viewers, AFAIK, Singularity is indeed linked with tcmalloc (there are alignment issues (for SSE2) that they didn't fix in their sources, that would otherwise cause crashes for 32 bits binaries), so they can use the CEF pre-built library as provided by the CEF team.

AFAIK, apart from the Cool VL Viewer, only Firestorm got Linux builds without tcmalloc (and therefore with a rebuilt from scratch, tcmalloc-less CEF library). Nicky did the work for Firestorm, at first based on my own work.

You can find the tcmalloc-less CEF library that I rebuilt myself (for both 32 and 64 bits builds) here, and the corresponding pre-built packages that you can use to compile a viewer here: be aware however that, for the latter pre-built packages, the CEF plugin interface is slightly different than LL's (it's extended), and you will therefore need to patch the CEF plugin (or just use the sources from the Cool VL Viewer's media_plugins/cef / directory.

Note that my version of llceflib also got the sandbox disabled.


2017-04-06 17:11:42
Profile WWW

Joined: 2017-04-05 23:56:46
Posts: 5
Reply with quote
Hi again, thanks for the pointers.
While working on this I ran into a change that you made (compared to latest linden version of bitbucket)
that makes me wonder if it's a bug fix or a typo. In src/llceflibimpl.cpp you do:

- if (mMediaStreamEnabled == true) // for webcam/media access
+ if (mSystemFlashEnabled) // for webcam/media access

shouldn't that be just 'if (mMediaStreamEnabled)' ?


2017-04-09 11:39:30
Profile

Joined: 2009-03-17 18:42:51
Posts: 3558
Reply with quote
Aleric wrote:
Hi again, thanks for the pointers.
While working on this I ran into a change that you made (compared to latest linden version of bitbucket)
that makes me wonder if it's a bug fix or a typo. In src/llceflibimpl.cpp you do:

- if (mMediaStreamEnabled == true) // for webcam/media access
+ if (mSystemFlashEnabled) // for webcam/media access

shouldn't that be just 'if (mMediaStreamEnabled)' ?
The code is correct, and adapted to the Cool VL Viewer (no 'mMediaStreamEnabled' in my sources).
Please, bear in mind that the Cool VL Viewer was forked from Snowglobe v1.5 code with many patches (most by me, some by others) applied to it, and was then deeply reworked by me to implement v2/3/4/5 features. And this went on for now 10 years... Its code, while mostly compatible with LL's viewer, therefore parts significantly from it in many ways/paths/algorithms/coding choices. When adapting code from my viewers to yours, you cannot just apply 'diff' files: you must review every line of code, one after the other, to work out every difference/idiosyncrasy, just like what I do when backporting stuff from any other viewer to mine.


2017-04-09 12:27:42
Profile WWW

Joined: 2017-04-05 23:56:46
Posts: 5
Reply with quote
Henri Beauchamp wrote:
The code is correct, and adapted to the Cool VL Viewer (no 'mMediaStreamEnabled' in my sources).


MmmyeahnoIdontthinkso...

I think you made an error there ;). Your code does have mMediaStreamEnabled too.
in llceflibimpl.h :

Code:
class LLCEFLibImpl :
    public CefApp
{
[...]
        bool mMediaStreamEnabled;


which gets set in llceflibimpl.cpp in LLCEFLibImpl::init :

Code:
        mMediaStreamEnabled = user_settings.media_stream_enabled;


That's from http://sldev.free.fr/libraries/sources/ ... rc.tar.bz2

I am looking at every line.. in fact, I'm having a hard time doing so because
your tar ball (the above) is outdated and was re-indented... so in the end
I've been comparing it with diff -ruwd with an older checkout from LL's
bitbucket to see what you did.


2017-04-09 15:01:00
Profile

Joined: 2017-04-05 23:56:46
Posts: 5
Reply with quote
These are the changes that I ended up actually applying after going over your differences,
along with adding support for autobuild of course.

https://github.com/AlericInglewood/3p-l ... 2a97158328

Lemme know if you see something weird (ie, something credited to you with <CV:HB> that you didn't do).

Thanks,
Aleric


2017-04-09 15:57:29
Profile

Joined: 2009-03-17 18:42:51
Posts: 3558
Reply with quote
Aleric wrote:
Henri Beauchamp wrote:
The code is correct, and adapted to the Cool VL Viewer (no 'mMediaStreamEnabled' in my sources).
MmmyeahnoIdontthinkso...

I think you made an error there ;). Your code does have mMediaStreamEnabled too.
in llceflibimpl.h :

Code:
class LLCEFLibImpl :
    public CefApp
{
[...]
        bool mMediaStreamEnabled;

I was speaking of the viewer sources... Apparently you were speaking about llceflib sources... Please, be accurate about what you are referring to.

Quote:
I am looking at every line.. in fact, I'm having a hard time doing so because your tar ball (the above) is outdated and was re-indented...
It's not "outdated", it's different... If you are to use my plugin version, you should use the llceflib sources I published, else you'll get into troubles...

Quote:
so in the end I've been comparing it with diff -ruwd
'diff -BwdurN' is best.

Quote:
with an older checkout from LL's bitbucket to see what you did.
Be careful, LL's latest changes to 3p-llceflib broke media flipping for CEF3.

Then they migrated the code to their new/upcoming dullahan llceflib library fork... I did not yet adapt it to Linux (waiting for LL to adopt it in their release viewer).


2017-04-09 16:41:35
Profile WWW
Display posts from previous:  Sort by  
Reply to topic   [ 7 posts ] 

Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software.