* Re: [Edbrowse-dev] segfault in latest Edbrowse
2016-02-05 13:59 ` Karl Dahlke
@ 2016-02-05 14:21 ` Geoff McLane
2016-02-06 11:57 ` Adam Thompson
2016-02-06 12:03 ` Adam Thompson
1 sibling, 1 reply; 8+ messages in thread
From: Geoff McLane @ 2016-02-05 14:21 UTC (permalink / raw)
To: edbrowse-dev
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Edbrowse-dev] segfault in latest Edbrowse
2016-02-05 13:59 ` Karl Dahlke
2016-02-05 14:21 ` Geoff McLane
@ 2016-02-06 12:03 ` Adam Thompson
1 sibling, 0 replies; 8+ messages in thread
From: Adam Thompson @ 2016-02-06 12:03 UTC (permalink / raw)
To: Karl Dahlke; +Cc: Edbrowse-dev
[-- 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 --]
^ permalink raw reply [flat|nested] 8+ messages in thread