[EMAIL PROTECTED] (Nicholas Clark) writes:
> On Sat, Jan 03, 2004 at 03:31:45AM +0100, Campo Weijerman wrote:
>> On Fri, Jan 02, 2004 at 05:25:27PM +0000, Nicholas Clark wrote:
>
>> > > ../t/op/pwent.t.........................FAILED at test 0
>> >
>> > Is this going SEGV?
>>
>> It seems so:
>>
>> Extending failures with Harness
>> FAILED--1 test script could be run, alas--no output ever seen
>> ../t/op/pwent....dubious
>> Test returned status -1 (wstat 139, 0x8b)
>> test program seems to have generated a core
>>
>> ../t/op/pwent.t.........................FAILED at test 0
>
> mmm. Does the compiler produce any prototype mismatch errors for any
> of the password functions? Particularly when compiling pp_sys.c and
> reentr.c?
No, the compile is clean. However, when adding -qwarn64 to the
compiler flags, I get a few ominous messages:
`sh cflags "optimize='-O'" reentr.o` reentr.c
CCCMD = cc_r -DPERL_CORE -c -qwarn64 -D_ALL_SOURCE -D_ANSI_C_SOURCE
-D_POSIX_SOURCE -qmaxmem=16384 -qnoansialias -DUSE_NATIVE_DLOPEN -DNEED_PTHREAD_INIT
-I/usr/local/include -q32 -D_LARGE_FILES -qlonglong -O
"reentr.c", line 40.49: 1506-743 (I) 64-bit portability: possible change of result
through conversion of int type into unsigned long int type.
"reentr.c", line 75.49: 1506-743 (I) 64-bit portability: possible change of result
through conversion of int type into unsigned long int type.
"reentr.c", line 318.5: 1506-744 (I) 64-bit portability: possible truncation of
pointer through conversion of pointer type into unsigned int type.
"reentr.c", line 370.30: 1506-742 (I) 64-bit portability: possible loss of digits
through conversion of unsigned long int type into int type.
"reentr.c", line 377.30: 1506-742 (I) 64-bit portability: possible loss of digits
through conversion of unsigned long int type into int type.
"reentr.c", line 379.30: 1506-742 (I) 64-bit portability: possible loss of digits
through conversion of unsigned long int type into int type.
"reentr.c", line 437.30: 1506-742 (I) 64-bit portability: possible loss of digits
through conversion of unsigned long int type into int type.
"reentr.c", line 444.30: 1506-742 (I) 64-bit portability: possible loss of digits
through conversion of unsigned long int type into int type.
I also briefly looked at t/op/pwent.t, it loops over setpwent();
getpwent(); endpwent(); twice. The core dump seems to occur at the
first getpwent(); of the second iteration.
The man page has the following remark that might be relevant:
Attention: All information generated by the getpwent, getpwnam, and
getpwuid subroutines is stored in a static area. Subsequent calls to
these subroutines overwrite this static area. To save the
information in the static area, applications should copy it.
And:
The getpwent, getpwnam, and getpwuid subroutines return a pointer to
a valid password structure if successful. Otherwise, a null pointer
is returned.
The getpwent subroutine will return a null pointer and an errno
value of ENOATTR when it detects a corrupt entry. To get subsequent
entries following the corrupt entry, call the getpwent subroutine
again.
Any clue?
--
$_ = "Campo Weijerman [rfc822://nl.ibm.com/]" and tr-[:]/-<@>-d and print;
