Re: [Edbrowse-dev] segfault in latest Edbrowse

[Geoff McLane <ubuntu@geoffair.info>]

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.