[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#163260: libc6: crypt r() returning bogus result, not consistently reproducible



Package: libc6
Version: 2.2.5-15
Severity: normal

OK, this is horrible, but I have to ask for help somewhere...

I have Apache, mod_perl, and perl, and deep down in that mess I'm calling
Perl's crypt() function, which in turn calls crypt_r().

Now, sometimes, this is getting bogus results back. At first I thought the
problem went away when I used the libc6-dbg libraries, but then it came back
and started occurring with them too. I can't find a single cause that
produces this, although I will keep trying to isolate it.

What I have got is this output from gdb when I set a breakpoint on crypt_r()
to see the calls:

(gdb) b crypt_r
Breakpoint 1 at 0x4bb33b05: file crypt-entry.c, line 77.
(gdb) c
Continuing.
[Switching to Thread 1024 (LWP 7719)]

Breakpoint 1, 0x4bb33b05 in __crypt_r (key=0x8dd5c00 "foo", salt=0x8e6c750
"xxY8K1xpBNqPg", data=0x8d35af8) at crypt-entry.c:77
77      crypt-entry.c: No such file or directory.
        in crypt-entry.c
(gdb) finish
Run till exit from #0  0x4bb33b05 in __crypt_r (key=0x8dd5c00 "foo",
salt=0x8e6c750 "xxY8K1xpBNqPg", data=0x8d35af8) at crypt-entry.c:77
0x4c0173dd in Perl_pp_crypt () from /usr/lib/libperl.so.5.8
Value returned is $1 = 0x8d55b78 "xx9azPWyUVpW."

"xxY8K1xpBNqPg" is the correct answer, the return value is bogus...

So, my thoguht would be that something is overwriting the "data" struct
while crypt_r is executing? However, iirc, this was taken while I was
running Apache in single-process mode, so there shouldn't have been any
chance for something else to stomp on the struct while crypt_r was
running...

I am totally at a loss.

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux arise 2.4.18 #7-ARISE Thu Jun 13 23:55:15 BST 2002 i586
Locale: LANG=en_GB, LC_CTYPE=en_GB

Versions of packages libc6 depends on:
ii  libdb1-compat                 2.1.3-4    The Berkeley database routines [gl

-- no debconf information




Reply to: