[Edbrowse-dev] segfault in latest Edbrowse

[Edbrowse-dev] segfault in latest Edbrowse

[Adam Thompson]

[-- Attachment #1: Type: text/plain, Size: 351 bytes --]

Hi all,

I updated my various copies of Edbrowse today and noticed that it appears
there's now a segfault, in particular I noticed it when viewing questions on
stack overflow (and other sites using that platform).

I'm happy to have a go at debugging this but was wondering how one gets a debug
build with our cmake based build system?

Cheers,
Adam.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[Edbrowse-dev] segfault in latest Edbrowse

[Karl Dahlke]

Don't know about cmake, but you can use
make clean ; make EBDEBUG=1
from the src directory.

I'm on the trail; have reduced it to a 37 line file.
http://www.eklhad.net/stackover
No problem if js is disabled,
which is weird since this file runs no js.
Those <script src= lines don't fetch anything from my website,
but if you remove them the bug goes away.

Karl Dahlke

Re: [Edbrowse-dev] segfault in latest Edbrowse

[Chris Brannon]

Adam Thompson <arthompson1990@gmail.com> writes:

> I'm happy to have a go at debugging this but was wondering how one gets a debug
> build with our cmake based build system?

cd build
cmake -DCMAKE_BUILD_TYPE=Debug ..
make

There's a script under there called build-me.sh, but it doesn't work at
the moment.  Apparently, it overwrites CMAKE_INSTALL_PREFIX and cmake
can no longer find tidy.  So I am going to try and fix that soon.
Anyway the commands I gave you above should work just fine.

-- Chris

Re: [Edbrowse-dev] segfault in latest Edbrowse

[Chris Brannon]

I broke the logic with cmake for finding tidy when I tried to "fix"
it last December.  So I pushed a new commit.  What we have now should be good.

cd build
./build-me.sh DEBUG
*should* give you a debug build.

Sorry for the mistake.

-- Chris

[Edbrowse-dev] segfault in latest Edbrowse

[Karl Dahlke]

Fixed by last push.

The problem here was me trying to work around the <A><DIV> tidy bug,
illustrated by:
http://www.eklhad.net/div
My tree rearranger worked most of the time, particularly in facebook,
cleaned a lot of things up,
but it found a false positive somewhere in stackoverflow,
fixed a tree that didn't need fixing, thus breaking the tree,
and that led to all the problems.
So I commented out the routine for now,
and stackoverflow works again, and facebook is back to being a little clunky.
In general, if you see

{} farm animals

It could likely mean {farm animals},
and you should click on the empty braces to see.

The moral if there is one is to be wary of trying to work around things
via html preprocessing code or tree postprocessing code.
Unless a bug really derails pages (which has happened in the past),
I should probably exercise patience, because tidy always catches up.

Karl Dahlke

Re: [Edbrowse-dev] segfault in latest Edbrowse

[Geoff McLane]

Hi,

===
Re: Debug Build

Yes, as Chris pointed out in CMake setting the build type to Debug
will add the -g to the compile, which then includes gdb symbols.

This can be done manually, or with build-me.sh
$ cd build
$ cmake .. -DCMAKE_BUILD_TYPE=Debug
or
$ ./build-me.sh DEBUG

Be aware, using build-me.sh will set the install location
to $HOME. In my $HOME/.bashrc, well actually in .bash_aliases
which it loads, I modify the PATH to include $HOME/bin with
the line -

export PATH=${PATH}:$HOME/bin:$HOME/share/bin

Alternatively, when using build-me.sh, you could adjust the line

TMPOPTS="-DCMAKE_INSTALL_PREFIX=$HOME"
to the more 'traditional'
TMPOPTS="-DCMAKE_INSTALL_PREFIX=/usr"

Removing it altogether and cmake will default to /usr/local

Note if this is done, changed then you may have to use
$ sudo make install
if you install edbrowse...

But most of the time I just use edbrowse exe exactly where
it was built...

===
Re: Find Tidy

And some notes on finding Tidy when building edbrowse. Of
course it depends on where you built and installed Tidy.

If you use the above CMAKE_INSTALL_PREFIX any path you
give there will also be used in finding Tidy headers and
library, as well as looking in the more 'traditional' places like
/usr/include, /usr/lib, /usr/local/include, /usr/local/lib
in the search...

If you have installed Tidy in some 'other' place
you can use -DCMAKE_PREFIX_PATH=/some/tidy/install/path,
and this can be a list of paths, and/or you can set
TIDY_ROOT in the environment...
export TIDY_ROOT=/some/tidy/install/path

Of course the above is in unix/linux, but it is quite
similar in Windows... Here I put Tidy and EdBrowse
source in the same ROOT, like say "F:\Projects"

When I build Tidy, in F:\Projects\tidy-html5\build\cmake,
I will set the CMAKE_INSTALL_PREFIX
to say F:\Projects\software, and that is where it will
be installed...

Then when building edbrowse I use the /SAME/ CMAKE_INSTALL_PREFIX
and it will find that installed Tidy.

And that goes for each of the other library dependencies
of edbrowse, namely CURL, PCRE, READLINE, MOZJS, THREADS,...

Each of these sources are built in F:\Projects\<project>,
and each installed to F:\Projects\software, so they are
all easily found...

Another more common name I use for this install location
is '3rdParty', so for instance I have LOTS of projects
on my X: drive, each in their own X:\<project>, and
each will be installed to X:\3rdParty

And that is just for 32 bit build. Many of those same
projects I also build in 64-bits, and these will all
be installed in X:\3rdParty.x64

Just my MO ;=))

===
Re: segfault

I have not actually experienced this, but in building
edbrowse today, using my build-me.sh which outputs
the build to a bldlog-1.txt I see some troublesome
warnings -

/usr/include/mozjs-24/jspubtd.h:370:74: warning: invalid access to 
non-static data member 
‘js::PerThreadDataFriendFields::RuntimeDummy::mainThread’  of NULL 
object [-Winvalid-offsetof]
      static const size_t RuntimeMainThreadOffset = 
offsetof(RuntimeDummy, mainThread);
^
/usr/include/mozjs-24/jspubtd.h:370:74: warning: (perhaps the ‘offsetof’ 
macro was used incorrectly) [-Winvalid-offsetof]
/usr/include/mozjs-24/jsfriendapi.h:1538:70: warning: invalid access to 
non-static data member 
‘JS::detail::CallReceiverBase<(JS::detail::UsedRval)1u>::argv_’ of NULL 
object [-Winvalid-offsetof]
      static const size_t offsetOfArgv = offsetof(JSJitMethodCallArgs, 
argv_);
^
/usr/include/mozjs-24/jsfriendapi.h:1538:70: warning: (perhaps the 
‘offsetof’ macro was used incorrectly) [-Winvalid-offsetof]
/usr/include/mozjs-24/jsfriendapi.h:1539:70: warning: invalid access to 
non-static data member 
‘JS::detail::CallArgsBase<(JS::detail::UsedRval)1u>::argc_’ of NULL 
object [-Winvalid-offsetof]
      static const size_t offsetOfArgc = offsetof(JSJitMethodCallArgs, 
argc_);
^
/usr/include/mozjs-24/jsfriendapi.h:1539:70: warning: (perhaps the 
‘offsetof’ macro was used incorrectly) [-Winvalid-offsetof]

Now I do not know exactly, but that may mean these are set to
a NULL... It is always a good thing to check and clear this
log of ALL warnings, just to be sure... even if that just means
suppressing the warning - see CMakeLists.txt around line 54.

You will note there is already a considerable suppressed warning
list. It is also a good idea to now and then remove these
suppressions and directly fix the warning...

Note, this is similar in WIN32, line 39. Again a list of warnings
suppressed, which can sometimes hide a real problem...

But in reading Karl's next, maybe he has found the problem, but
my suggestion about trying to clear these warnings still holds...

===
Re: This list

While I do read everything that comes, I have been a little
busy on other things lately, and may have overlooked some
questions directed to me...

If you want me to answer it is better you ping me directly. Karl
usually does this... This is more likely to 'stick' in my inbox
until I get around to answering it... thanks...

Regards,
Geoff.

Re: [Edbrowse-dev] segfault in latest Edbrowse

[Adam Thompson]

[-- Attachment #1: Type: text/plain, Size: 673 bytes --]

On Fri, Feb 05, 2016 at 03:21:31PM +0100, Geoff McLane wrote:
> Re: Debug Build
> 
> Yes, as Chris pointed out in CMake setting the build type to Debug
> will add the -g to the compile, which then includes gdb symbols.
> 
> This can be done manually, or with build-me.sh
> $ cd build
> $ cmake .. -DCMAKE_BUILD_TYPE=Debug
> or
> $ ./build-me.sh DEBUG
> 
> Be aware, using build-me.sh will set the install location
> to $HOME.

Ok, I've pushed a (hopefully) improved version of build-me.sh which fixes a
number of things, one of which is that one can now use the CMAKE_INSTALL_PREFIX
environment variable to control the install location.

Cheers,
Adam.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [Edbrowse-dev] segfault in latest Edbrowse

[Adam Thompson]

[-- Attachment #1: Type: text/plain, Size: 1789 bytes --]

On Fri, Feb 05, 2016 at 08:59:22AM -0500, Karl Dahlke wrote:
> Fixed by last push.

Thanks, I can confirm this works.

> The problem here was me trying to work around the <A><DIV> tidy bug,
> illustrated by:
> http://www.eklhad.net/div
> My tree rearranger worked most of the time, particularly in facebook,
> cleaned a lot of things up,
> but it found a false positive somewhere in stackoverflow,
> fixed a tree that didn't need fixing, thus breaking the tree,
> and that led to all the problems.

Ah ok, I wondered if it was that change but didn't have the time to check.

> So I commented out the routine for now,
> and stackoverflow works again, and facebook is back to being a little clunky.
> In general, if you see
> 
> {} farm animals
> 
> It could likely mean {farm animals},
> and you should click on the empty braces to see.

Yeah, I'm not sure how much of a bug this is exactly,
I think there's some odd interactions here which I'm not that sure about.

> The moral if there is one is to be wary of trying to work around things
> via html preprocessing code or tree postprocessing code.
> Unless a bug really derails pages (which has happened in the past),
> I should probably exercise patience, because tidy always catches up.

Yeah. Or we can fix in rendering possibly?
That's what's really going on here if I understand the bug correctly.
the Blank braces then text sound like a construct I've seen recommended by
various (unspecified) web developers to get "clickable" divs.
Since the text isn't actually in the link it's not contained in the node.
I think what most browsers do is render this as a link without actually
altering the DOM (because that'd be wrong).
I'm not sure if this is the same problem though.

Cheers,
Adam.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]