SubTile crashing (segmentation fault) when using Diff

[Anand Wu]

Hi,

I'm using firefox/45.0.2 on Red Hat Enterprise Linux Server release 6.6 (Santiago) (64 bit)
and whenever I'm trying to use Diff the application crashes (Segmentation fault)

Do you need some more info from my machine?

Anand

[Dmitri Zoubkov]

Hi,
thanks for feedback.
Would you mind to provide following infos:

1. Which version of subversion is installed?
2. What version of SubTile are you using?
3. Did you try to run SubTile with xulrunner on the same machine? If yes, does Diff crash then too?

My latest test on OpenSuse 13.1 with firefox 45.0 and subversion 1.8.15-2 doesn't show any problems with Diff, but it is known that some combinations of firefox/subversion produce unexpected errors.

If you check out the SubTile trunk on that machine and run it from terminal like this:
firefox <SUBTILE_WORKING_COPY>/src/xul/application.ini you will get full JS logging and evtl. exception trace in the terminal window that you can post here to help investigation.

[Anand Wu]

Hi Dmitri,

Here's what I could gather:
1. SVN version: 1.9.4 (r1740329)
2. SubTile version: 0.2.201505202
3. Yes I did and yes it crashes (Mozilla XULRunner 17.0.10 - 20131023040931)

I've attached the log.

[Dmitri Zoubkov]

I see from the log that you diff'ing within repository connected via svn: protocol, using this protocol is connected with some issues (s. [FAQ] Q2). May I ask you to do the following:

Run this in terminal:
svn diff svn://svn.code.sf.net/p/subtile/code/trunk/src/xul/application.ini@1 svn://svn.code.sf.net/p/subtile/code/trunk/src/xul/application.ini@7
Does this succeed?

Connect repository in question in SubTile via https: and try the Diff on same path there. Does this work?

[Anand Wu]

The svn diff cmd seems to work, here's the output:

svn diff svn://svn.code.sf.net/p/subtile/code/trunk/src/xul/application.ini@1 svn://svn.code.sf.net/p/subtile/code/trunk/src/xul/application.ini@7
Index: application.ini
===================================================================
--- application.ini     (nonexistent)
+++ application.ini     (revision 7)
@@ -0,0 +1,18 @@
+[App]
+Vendor=diVISION
+VendorURL=http://di-vision-co.biz
+Name=SubTile
+Version=0.1
+BuildID=201505174
+Copyright=Copyright (c) 2015
+ID={8a6aa836-1861-4a6f-92e5-17a680ad426a}
+Debug=true
+Devel=true
+
+[Gecko]
+MinVersion=3.7
+MaxVersion=50
+
+[Shell]
+Icon=chrome/icons/default/subtile
+

Property changes on: application.ini
___________________________________________________________________
Added: svn:eol-style
## -0,0 +1 ##
+native
\ No newline at end of property
Added: svn:keywords
## -0,0 +1 ##
+Author Date Id Revision Log URL HeadURL
\ No newline at end of property
Added: svn:mime-type
## -0,0 +1 ##
+text/plain
\ No newline at end of property

As for the https in SubTile, no, that didn't work...
Attached another log

[Dmitri Zoubkov]

This looks strange...
Well, if it is not too much work, could you please do this:

1. Download attached snv.jsm
2. Put it in checked out SubTile trunk under <SUBTILE_WORKING_COPY>/src/xul/modules (overwriting exiting file)
3. Increment BuildID=201505202 in <SUBTILE_WORKING_COPY>/src/xul/application.ini (to enforce XUL cache reload)
4. Repeat the crashing diff operation and post the resulting log

[Anand Wu]

Mornin' Dmitri,

I've made the modifications but the log didn't change.
I've also added the line:

diff: function(req, receiver, ...) {
        this.logger.debug("Entered diff!");

to check if the cache was rebuilt and if I was running the correct thing and that message appears in the log:

2016-10-04 07:03:01.803 svn.cli.Command      DEBUG      Entered diff!
2016-10-04 07:03:01.803 svn.cli.Command      DEBUG      diff(https://svn.code.sf.net/p/subtile/code/trunk/src/xul/application.ini, https://svn.code.sf.net/p/subtile/code/trunk/src/xul/application.ini)
2016-10-04 07:03:01.804 svn.cli.Command      DEBUG      diff(https://svn.code.sf.net/p/subtile/code/trunk/src/xul/application.ini, https://svn.code.sf.net/p/subtile/code/trunk/src/xul/application.ini, revision_t(1, ctypes.Int64("489")), revision_t(7, ctypes.Int64("0"))), ptmp=/tmp/tempfile.17.tmp
Segmentation fault (core dumped)

but the other messages don't.

[Dmitri Zoubkov]

Hi, the fact the other messages didn't show up in log has a significant meaning alright: segfault occurs somewhere whithin libsvn.client.diff3() call. This one won't easy to debug.
Do you have the core dump by any chance? Posting it wouldn't be good idea but you could mail it to me dimamizou\at\users.sourceforge.net.

[Anand Wu]

Sent, I hope. :)

[Anand Wu]

Dmitri,

I've took the liberty to run a valgrind in hopes it will provide some additional info (attached log).
Also, I've noticed that SubTile is reporting SVN version as 1.6.11 (I'm guessing it's pointing to /usr/bin/svn) but here's the issue:

> which svn
/arm/tools/apache/subversion/1.9.4/rhe6-x86_64/bin/svn

> svn --version
svn, version 1.9.4 (r1740329)
   compiled Jul  4 2016, 12:00:56 on x86_64-unknown-linux-gnu

> /usr/bin/svn --version
svn, version 1.6.11 (r934486)
   compiled Feb  4 2015, 07:24:44

Maybe some .so-s get mixed up?

[Dmitri Zoubkov]

Version mix! Could be very well the cause! Try pointing SubTile to /arm/tools/apache/subversion/1.9.4/rhe6-x86_64/bin/ (Preferences->SVN). Better yet, you uninstall svn 1.6.1 and all dependencies (libapr*) and reinstall 1.9.4.

Thanks for the coredump by the way, I could access it but had difficulties to untgz (18:35:37 in name...).

[Anand Wu]

Pointing to/arm/tools/apache/subversion/1.9.4/rhe6-x86_64/bin/ didn't work, had to use /arm/tools/apache/subversion/1.9.4/rhe6-x86_64/lib/, but that path was missing libapr*.
I made a folder and dumped links to all svn libs (version 1.9.4) and links to libapr* version 1.4.2 - horrible, I know, but redirecting SubTile to that folder seems to work.

Unfortunately it's not possible to update/reinstall packages (not by me anyway and not without extensive testing). The server uses MODULES to configure the environment, I know it's a bit of a mess but that way everyone can have access to all kinds of different versions of different software - backwards compatibility and such (you should see the horrors that happen when you try loading a different glibc).

Anyway, what I'm trying to say is thanks for all the help, Dmitri :)
I'm going to start checking out some larg projects and see how well SubTile holds

[Anand Wu]

Nope, can't get it to fully work.
So, diff works now but I can't checkout anything, attached an error.

BTW, with SVN version 1.6.11 I was unable to run svn diff

> /usr/bin/svn diff svn://svn.code.sf.net/p/subtile/code/trunk/src/xul/application.ini@1 svn://svn.code.sf.net/p/subtile/code/trunk/src/xul/application.ini@7
svn: 'svn://svn.code.sf.net/p/subtile/code/trunk/src/xul/application.ini' was not found in the repository at revision 1

[Dmitri Zoubkov]

Your last problem is easy: s [FAQ] Q3
In case of running under firefox the operation is to be performed in the different direction: copy (or link) libsqlite3.so from wherever your SVN loads it from to /usr/lib/firefox/libmozsqlite3.so

[Anand Wu]

That worked, thanks!