Re: diff 2.8.1 dumps core on HPUX 10.20

[Paul Eggert]

> From: Jost Martin <address@hidden>
> Date: Fri, 29 Nov 2002 11:56:00 +0100
> 
> I'm trying to compile diff 2.8.1 on HPUX 10.20 using the HP ANSI-C-Compiler.
> 
> Linking gets:
> cc  +DAportable -Aa +O2  -D_POSIX_SOURCE -D_HPUX_SOURCE -D_XOPEN_SOURCE 
> -D_XOPEN_SOURCE_EXTENDED  -L/pd/libs/lib/ -o diff  analyze.o context.o diff.o 
> dir.o ed.o ifdef.o io.o normal.o side.o util.o version.o ../lib/libdiffutils.a
> ...
> /usr/ccs/bin/ld: (Warning) LDW instruction from file io.o(0xf0c) accesses 
> nonaligned data - check alignment options.

Thanks for your bug report.  This sounds quite strange.  I don't know
HP-UX, but it vaguely sounds like you are compiling with aggressive
optimization options that break diffutils, either because of a
compiler bug, or because the options produce an implementation that is
too strict about type punning.

> Backtrace gets: (Sorry, as usual, the problem disappears when compiling with 
> debug-info)
> #0  0xa41c in find_identical_ends () from 
> /home/pd/pd-sw/tools/diffutils/diffutils-2.8.1/src/./diff

This also sounds like your compiler is doing incorrect optimization.
find_identical_ends converts a word* pointer to char*, and uses the
char* pointer.  Perhaps your compiler is getting confused by this.
'word' == 'uintmax_t'.  If 'uintmax_t' is 'long long' on your host,
perhaps your compiler mishandles 'long long' in some cases.

I'm afraid that the only way to tell for sure whether my guess is
correct is to disassemble find_identical_ends and make sure that its
object code accurately implements the source code.


> ****  Purify instrumented ./diff (pid 22136)  ****
> ABR: Array bounds read:
>   * This is occurring while in:
>         find_identical_ends [io.o]
>         read_files     [io.o]
>         diff_2_files   [analyze.o]
>         compare_files  [diff.o]
>         main           [diff.o]
>         _start         [libc.1]
>   * Reading 4 bytes from 0x400189b8 in the zero'd data, bss section (1 byte 
> at 0x40
> 0189b8 illegal).
>   * Address 0x400189b8 is       16 bytes past start of global variable 
> "ignore_rege
> xp".
>     This is defined in diff.

If you are on a 32-bit machine, 16 bytes past the start of
"ignore_regexp" should be the "fastmap" component of "ignore_regexp".
find_identical_ends does not inspect ignore_regexp, so it is indeed a
bug find_identical_ends is loading ignore_regexp.fastmap.  However,
find_identical_ends should have inspected function_regexp.fastmap.
Purify didn't report that, so perhaps it is confused about the
distinction between ignore_regexp and function_regexp, or possibly the
compiler is generating incorrect code or debugging information.


> 
> ****  Purify instrumented ./diff (pid 22136)  ****
> ABR: Array bounds read:
>   * This is occurring while in:
>         diff_2_files   [analyze.o]
>         compare_files  [diff.o]
>         main           [diff.o]
>         _start         [libc.1]
>         $START$        [crt0.o]
>   * Reading 4 bytes from 0x400189b8 in the zero'd data, bss section (1 byte 
> at 0x40
> 0189b8 illegal).
>   * Address 0x400189b8 is       16 bytes past start of global variable 
> "ignore_rege
> xp".
>     This is defined in diff.

diff_2_files does indeed look at ignore_regexp.fastmap.  But it is
guaranteed to be zero, so I don't see why this is a bug.  Perhaps
Purify insists for some reason that you must explicitly initialize BSS
to zero?


> ****  Purify instrumented ./diff (pid 22136)  ****
> ABR: Array bounds read:
>   * This is occurring while in:
>         analyze_hunk   [util.o]
>         print_normal_hunk [normal.o]
>         print_script   [util.o]
>         print_normal_script [normal.o]
>         diff_2_files   [analyze.o]
>         compare_files  [diff.o]
>   * Reading 4 bytes from 0x400189b8 in the zero'd data, bss section (1 byte 
> at 0x40
> 0189b8 illegal).
>   * Address 0x400189b8 is       16 bytes past start of global variable 
> "ignore_rege
> xp".
>     This is defined in diff.

Similarly, this appears to be OK, since analyze_hunk indeed inspects
ignore_regexp.fastmap, which is guaranteed to be nonzero.