Mailing List Archive

Henk - CityWEB scribbled on 5/14/07 5:58 AM:

> On machine B, test 307-pre_sorter fails:
>
> t/307-pre_sorter..............dubious
> Test returned status 0 (wstat 11, 0xb)
> DIED. FAILED tests 1-9
> Failed 9/9 tests, 0.00% okay
>
>
> Is there something I can do to narrow this down for you?
>

In general, I find it helpful to run a failing test alone to see what (if any)
errors print that the 'make test' hides:

perl -Iblib/arch -Iblib/lib t/307-pre_sorter.t

--
Peter Karman . http://peknet.com/ . peter@peknet.com

On Mon, 14 May 2007, Peter Karman wrote:
> In general, I find it helpful to run a failing test alone to see what (if any)
> errors print that the 'make test' hides:
>
> perl -Iblib/arch -Iblib/lib t/307-pre_sorter.t


Thanks Peter. Running that line produces:

1..9
Segmentation fault

A few lines of the trace before the segv:

open("t/307-pre_sorter.t", O_RDONLY) = 3
lseek(3, 0, SEEK_CUR) = 0
fcntl(3, F_SETFD, FD_CLOEXEC) = 0
fstat(3, {st_mode=S_IFREG|0664, st_size=3362, ...}) = 0
rt_sigaction(SIGCHLD, NULL, {SIG_DFL}, 8) = 0
readlink("/proc/self/exe", "/usr/bin/perl", 4095) = 13
brk(0x67e000) = 0x67e000
getppid() = 20967
read(3, "use strict;\nuse warnings;\n\nuse T"..., 4096) = 3362
...
...
open("blib/lib/KinoSearch/Search/TopDocs.pm", O_RDONLY) = 5
lseek(5, 0, SEEK_CUR) = 0
read(5, "use strict;\nuse warnings;\n\npacka"..., 4096) = 731
lseek(5, 365, SEEK_SET) = 365
lseek(5, 0, SEEK_CUR) = 365
close(5) = 0
read(4, "{close_reader};\n}\n\n1;\n\n__END__\n\n"..., 4096) = 3739
lseek(4, 4127, SEEK_SET) = 4127
lseek(4, 0, SEEK_CUR) = 4127
close(4) = 0
brk(0xf87000) = 0xf87000

read(3, "", 4096) = 0
close(3) = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
Process 20968 detached


---

I compared this to the machine where it runs normally (which uses perl
5.8.7), and subsequent to file handle 3 being closed, overload.pm[c] is opened.

The machine where it segv's is using perl 5.8.8.

On May 14, 2007, at 3:58 AM, Henk - CityWEB wrote:

> On machine B, test 307-pre_sorter fails:
>
> t/307-pre_sorter..............dubious
> Test returned status 0 (wstat 11, 0xb)
> DIED. FAILED tests 1-9
> Failed 9/9 tests, 0.00% okay

I believe this has been addressed as of repository revision 2437,
which fixes a problem on machines where sizeof(int) != sizeof(void*).

Thanks for the report,

Marvin Humphrey
Rectangular Research
http://www.rectangular.com/

On Tue, 15 May 2007, Marvin Humphrey wrote:

>
> On May 14, 2007, at 3:58 AM, Henk - CityWEB wrote:
>
> > On machine B, test 307-pre_sorter fails:
> >
> > t/307-pre_sorter..............dubious
> > Test returned status 0 (wstat 11, 0xb)
> > DIED. FAILED tests 1-9
> > Failed 9/9 tests, 0.00% okay
>
> I believe this has been addressed as of repository revision 2437,
> which fixes a problem on machines where sizeof(int) != sizeof(void*).

I haven't really had the time to research this a bit more: do you reckon
this is a result of the diff between AMD Opteron (the working one) and
Intel Xeon 64-bit, or an issue with GCC 3.3.6 and 4.1.0 ?

Anyway, thank you very much. I just compiled the latest svn
version and it looks good on the Intel Xeon platform.

Regards
Henry

On May 16, 2007, at 2:47 AM, Henk - CityWEB wrote:

>> I believe this has been addressed as of repository revision 2437,
>> which fixes a problem on machines where sizeof(int) != sizeof(void*).
>
> I haven't really had the time to research this a bit more: do you
> reckon
> this is a result of the diff between AMD Opteron (the working one) and
> Intel Xeon 64-bit, or an issue with GCC 3.3.6 and 4.1.0 ?

It was presumably the architecture. If it's possible to make GCC
change the size of a pointer on a box from 8 bytes to 4, I don't know
how. :)

The bug would have affected any machine where pointers and ints were
not the same size: an array of ints was being sorted, but part of the
routine treated them like pointers. It's not the sort of error I'd
usually make, but in the middle of refactoring something complex, I
intentionally left that for later -- I knew it would come back to
haunt me and I didn't want to add any more complexity at that stage.

> Anyway, thank you very much. I just compiled the latest svn
> version and it looks good on the Intel Xeon platform.

Excellent.

Marvin Humphrey
Rectangular Research
http://www.rectangular.com/