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
[code]>nm -C lib/debug/libcef.so | grep 'malloc$'
0000000002528020 t av_fast_malloc
00000000024d17e0 t av_fast_padded_malloc
0000000002527240 t av_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,