vsdiff SEGV

[b]

I've started encountering SEGV issues with vsdiff.  I'm trying to compare changes between a vendor's modified source against ours and in the past, comparison of the the two trees worked great (e.g., vsdiff dir1 dir2).  However, this time, I can collapse some build subtrees and try to diff two apparent changes and it never launches the diff (just crashes with a notice to my console).  I don't even have SE running while performing this. 

Attached is a screen shot showing the header file I am trying to launch the diff.   I can DM strace outputs (parent and children) separately.

Both files (and all directories leading to the files) are real, (no symlinks or hard links).   Although the vendor supplied directory contains a hash, so the paths do exceed 128 characters.

Snippet from strace of parent vsdiff:

Code: [Select]

open("/tmp/vstemp.7899.0", O_RDWR|O_CREAT, 0664) = 3
readlink("/tmp", 0x7fff195ac9c0, 1024)  = -1 EINVAL (Invalid argument)
readlink("/tmp/vstemp.7899.0", 0x7fff195ac9c0, 1024) = -1 EINVAL (Invalid argument)
fcntl(3, F_SETLK, {type=F_WRLCK, whence=SEEK_SET, start=0, len=100}) = 0
ftruncate(3, 0)                         = 0
lseek(3, 0, SEEK_END)                   = 0
lseek(3, 0, SEEK_END)                   = 0
lseek(3, 0, SEEK_SET)                   = 0
write(3, "filespec:*\nexcludefilespec:\npath"..., 102) = 102
close(3)                                = 0
stat("/home/bjkurlex/slickedit/bin/vs", {st_mode=S_IFREG|0755, st_size=1599, ...}) = 0
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7fcbbb8f3a90) = 7900
wait4(7900, Segmentation fault (core dumped)
[{WIFEXITED(s) && WEXITSTATUS(s) == 139}], 0, NULL) = 7900
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=7900, si_status=139, si_utime=0, si_stime=0} ---
exit_group(0)                           = ?
+++ exited with 0 +++

Snippet for strace of children (-f) of vsdiff

Code: [Select]

[pid  7935] brk(0x82ba000)              = 0x82ba000
[pid  7935] brk(0x82db000)              = 0x82db000
[pid  7935] brk(0x82fc000)              = 0x82fc000
[pid  7935] poll([{fd=6, events=POLLIN|POLLOUT}], 1, 4294967295) = 1 ([{fd=6, revents=POLLOUT}])
[pid  7935] writev(6, [{"\213\24?\0,\0\200\0\1\0\0\0\200\0\0\0\r\0\16\0\1\0\f\0\10\0\0\0\0\0\0\0"..., 16340}, {"\0\0S\315\367\342\214\1\0T\377\377\356\362\377\4\0\330\377~\0\1\\\2\32\377\360\6\0\0\0\0"..., 80}, {"", 0}], 3) = 16420
[pid  7935] poll([{fd=6, events=POLLIN|POLLOUT}], 1, 4294967295) = 1 ([{fd=6, revents=POLLIN|POLLOUT}])
[pid  7935] recvmsg(6, {msg_name(0)=NULL, msg_iov(1)=[{"\34\0\240V\234\236\200\0\22\1\0\0H\233\343\25\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 192
[pid  7935] writev(6, [{"\213\24\33\0+\0\200\0\1\0\0\0+\0\0\0\10\0\n\0\0\0\n\0\10\0\0\0\34\377\320\0"..., 16332}, {"\10\377\340\0\0\0\0\0\10\377\340\0\0\0\0\0\10\377\340\0\0\0\0\0\10\377\340v\362\337C\0"..., 112}, {"", 0}], 3) = 16444
[pid  7935] --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0xc6fe53a0} ---
[pid  7948] +++ killed by SIGSEGV (core dumped) +++
[pid  7947] +++ killed by SIGSEGV (core dumped) +++
[pid  7946] +++ killed by SIGSEGV (core dumped) +++
[pid  7945] +++ killed by SIGSEGV (core dumped) +++
[pid  7944] +++ killed by SIGSEGV (core dumped) +++
[pid  7943] +++ killed by SIGSEGV (core dumped) +++
[pid  7942] +++ killed by SIGSEGV (core dumped) +++
[pid  7941] +++ killed by SIGSEGV (core dumped) +++
[pid  7940] +++ killed by SIGSEGV (core dumped) +++
[pid  7939] +++ killed by SIGSEGV (core dumped) +++
[pid  7938] +++ killed by SIGSEGV (core dumped) +++
[pid  7935] +++ killed by SIGSEGV (core dumped) +++
[pid  7930] <... wait4 resumed> [{WIFSIGNALED(s) && WTERMSIG(s) == SIGSEGV && WCOREDUMP(s)}], 0, NULL) = 7935
[pid  7930] --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_DUMPED, si_pid=7935, si_status=SIGSEGV, si_utime=1613, si_stime=381} ---
[pid  7930] rt_sigreturn()              = 7935
[pid  7930] write(2, "Segmentation fault (core dumped)"..., 33Segmentation fault (core dumped)
) = 33
[pid  7930] read(10, "", 8192)          = 0
[pid  7930] exit_group(139)             = ?
[pid  7930] +++ exited with 139 +++
<... wait4 resumed> [{WIFEXITED(s) && WEXITSTATUS(s) == 139}], 0, NULL) = 7930
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=7930, si_status=139, si_utime=0, si_stime=0} ---
exit_group(0)                           = ?
+++ exited with 0 +++

Installation:

Code: [Select]

SlickEdit Pro 2015 (v20.0.1.3 64-bit)

Serial number: FE10297
Licensed number of users: Single user
License file: /home/bjkurlex/slickedit/bin/slickedit.lic

Build Date: March 23, 2016
Emulation: Vim

OS: Linux
OS Version: Ubuntu 14.04.4 LTS
Kernel Level: 3.19.0-51-generic
Build Version: #58~14.04.1-Ubuntu SMP Fri Feb 26 22:02:58 UTC 2016
Processor Architecture: x86_64

X Server Vendor: The Cygwin/X Project
Memory: 32% Load, 19465MB/59762MB Virtual
Shell Information: /home/bjkurlex/slickedit/bin/secsh -i
Screen Size: 1920 x 1200, 1680 x 1050, 1600 x 900

Project Type: (Other)
Language: .c (C/C++)
Encoding: Automatic

Installation Directory: /home/bjkurlex/slickedit/
Configuration Directory: /home/bjkurlex/.slickedit/20.0.1/

Hotfixes:
/home/bjkurlex/.slickedit/20.0.1/hotfixes/hotfix_se2001_6_cumulative.zip (Revision: 6)
/home/bjkurlex/.slickedit/20.0.1/hotfixes/hotfix_se2001_2_cumulative.zip (Revision: 2)
/home/bjkurlex/.slickedit/20.0.1/hotfixes/hotfix_se2001_7_cumulative.zip (Revision: 7)
/home/bjkurlex/.slickedit/20.0.1/hotfixes/hotfix_se2001_5_cumulative.zip (Revision: 5)


[Dan]

What happens if you just diff these two files (without multi-file diff)?

[b]

I had tried that yesterday on the isolated file, and it worked just fine.  Went back to the directory form and tried it again, and it SEGV'd.   

FWIW, I also tried various different directory references between the two files (full path, full path in reverse order, relative path...all worked).   It appears only to fault when I select the same file from the chooser.

Again, I also spent the time to individually double check that there were no symlinks or hard links in the paths of each file.   Both files are standard ASCII source files (Unix line endings).

[Dan]

What if you do multifile diff from the editor as opposed to vsdiff?

[b]

I tend to use the command line so I hadn't tried that method (takes too many clicks and back traversals to set it up when I can do it once on the command line).  Since SE tries to be helpful and only show the last path, it is painful as I have to collapse and reexpand the tree to find the directories in question--for both source and target.

Regardless, for the test I've set it up.   I've tried it a couple of times from within SE with varying results.  Once, it crashed halfway through the tree comparison  (I've got 100k+ of files, thus why I wanted a tool to tell me what's changed).  Another time, I was left with a grey box, waiting for the picker and after about 3-4 minutes, it crashed.  Neither time was I able to get as far as what vsdiff from the command line produced.  I performed the same, again, with vsdiff on the command line and at least get the picker window (after a long wait), but faults when I attempt to diff two changed files.

As noted, there appears to be a time after it has processed the directories, but before it shows the picker that no status window is displayed at all (when using vsdiff directly) or a blank gr[ae]y window is displayed (used within SE).  I watch the process via htop and patently wait for something to reappear (see attached showing process pegging a single core).  From the images you can see that processor and memory aren't an issue. :-)

So, with my attempts within SE to do a multi-file compare, I never get as far as I do with vsdiff from the command line.  But in either case, it faults.

[Dan]

Just trying to narrow this down... is it every time you diff a mismatched file this is happening?

What compare options (if any) do you have turned on?

What kind of files are these?

Are you using Source Diff?

[b]

As I mentioned in an earlier post when selecting a file to diff:

Both files are standard ASCII source files (Unix line endings).

I've been using the defaults for vsdiff. 

[edit]
Looking at the dialog (see attached) I was doing a source diff.  However, unchecking this and selecting a header file to diff still causes a SEGV
[/edit]

Code: [Select]

vsdiff iscsi/psme-sdv-src AMI/IntelRSA-AMI_Master-3baf7f2b868b46539c5263a20f2cb383bec81669/psme-iscsi-boot-updated

(both arguments passed are the root directory of the trees I wish to compare)

I'm not sure how not to try mismatched files when doing a diff via vsdiff of two directory trees.  Only the changed directories/files (added/or removed) show up.

There are binary files object files in both trees, but I've only tested selection of pure source files to diff.

[Dan]

Is it any time you diff two files from mutli-file diff?

I'm suspecting there's a particular pair of files we can track this down to.  I've run diff over and over and Linux and so far I can't reproduce the problem.

[b]

In the example provided, yes.   Any random file chosen from the multi-file diff caused the SEGV.     I'll continue to see what I can narrow down as time allows.

[b]

I didn't realize that vsdiff could also take the -sc parameter.  Discovering this, I tried to compare directories and it didn't crash.   

Therefore, what is in my SE configuration that the multi-file diff is using that may be causing it to choke?

[Dan]

Wow, I'm not sure.  Can you zip up the config and send it to me?  PM me and I'll give you an email address.

[b]

PM sent.   Also, I retested diffzilla with the new 20.0.2 drop and it, too, has the SEGV.
I look forward to finding out what bad juju in my config i causing diffzilla issues, but not apparently SE, itself.