From owner-freebsd-hackers Wed Oct 11 15:18:18 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA20865 for hackers-outgoing; Wed, 11 Oct 1995 15:18:18 -0700 Received: from rk.ios.com (rk.ios.com [198.4.75.55]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id PAA20859 for ; Wed, 11 Oct 1995 15:18:10 -0700 Received: (from rashid@localhost) by rk.ios.com (8.6.11/8.6.9) id GAA03636 for hackers@freebsd.org; Thu, 12 Oct 1995 06:18:13 -0400 From: Rashid Karimov Message-Id: <199510121018.GAA03636@rk.ios.com> Subject: ANNEX's erpcd . To: hackers@freebsd.org Date: Thu, 12 Oct 1995 06:18:13 -0400 (EDT) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1634 Sender: owner-hackers@freebsd.org Precedence: bulk Hi there folx, I've compiled those ones with "-g" and have connected to them via gdb. It's really weird - they all are in crypt() fcall,doing something crazy - since they all are in the list of the processes consuming the most amount of time ! So as the time flow - more and more erpcd's get stuck in crypt(), which leads to huge load averages finally. The idea of the sequential search thru the acp_passwd doesnt contribute much to it - it's suprisingly fast. So what the heck is going on ... ? I use DES crypt() on this computer. The parameters to the crypt() look pretty innocent to me :( Here goes the small transcrypt from the gdb session: ( it was invoked as : gdb erpcd PID) Reading symbols from /usr/libexec/ld.so...done. Reading symbols from /usr/lib/libcrypt.so.2.0...done. Reading symbols from /usr/lib/libc.so.2.1...done. 0x802eab4 in crypt.so () (gdb) bt #0 0x802eab4 in crypt.so () #1 0x802ef6b in crypt () #2 0x8ae8 in acp_validate (User=0xefbfd2a0 "bm8474", Password=0xefbfd2c0 "BTGA474t") at acp_policy.c:1849 #3 0x7831 in ppp_security (Acp=0x18c00, logid=3775079420, inet=72422606, port=15, service=8, direction=0, Name=0xefbfd2a0 "bm8474", Pass=0xefbfd2c0 "BTGA474t", to=0x0) at acp_policy.c:676 #4 0x4f57 in acp_req_serial_validate (Acp=0x18c00, message=0xefbfd3a6 "t\b`\2275\004pXR\016@ua\003#|N\024Q\004", length=192, to=0x0) at acp_rpc.c:352 #5 0x45f7 in acp (s=3, message=0x1c9a8 "", mlen=42, iaddr=72422606) at acp.c:357 #6 0x1dfc in spawn_child (ccount=42, rpnum=3) at erpcd.c:465 #7 0x268c in main (argc=5, argv=0xefbfdc28) at erpcd.c:761 (gdb)