From root@ciam.ru  Mon Jan 29 15:36:51 2007
Return-Path: <root@ciam.ru>
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id 0AF1416A405;
	Mon, 29 Jan 2007 15:36:51 +0000 (UTC)
	(envelope-from root@ciam.ru)
Received: from mail.ciam.ru (host-74.ALL2PC.macomnet.net [213.247.195.74])
	by mx1.freebsd.org (Postfix) with ESMTP id BFBFD13C491;
	Mon, 29 Jan 2007 15:36:50 +0000 (UTC)
	(envelope-from root@ciam.ru)
Received: from root by mail.ciam.ru with local (Exim 4.x)
	id 1HBY3t-000GCA-PT; Mon, 29 Jan 2007 18:04:49 +0300
Message-Id: <E1HBY3t-000GCA-PT@mail.ciam.ru>
Date: Mon, 29 Jan 2007 18:04:49 +0300
From: Sergey Matveychuk <sem@ciam.ru>
Reply-To: Sergey Matveychuk <sem@FreeBSD.org>
To: FreeBSD-gnats-submit@freebsd.org
Cc: mux@FreeBSD.org
Subject: csup is dumped when run under socksify command
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         108518
>Category:       bin
>Synopsis:       csup is dumped when run under socksify command
>Confidential:   no
>Severity:       serious
>Priority:       low
>Responsible:    mux
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Jan 29 15:40:24 GMT 2007
>Closed-Date:    Tue Jun 12 07:57:53 GMT 2007
>Last-Modified:  Tue Jun 12 07:57:53 GMT 2007
>Originator:     Sergey Matveychuk
>Release:        FreeBSD 6.2-RELEASE i386
>Organization:
>Environment:
System: FreeBSD xxx.xxx.ru 6.2-RELEASE FreeBSD 6.2-RELEASE #0: Tue Jan 23 22:03:59 MSK 2007 root@xxx.xxx.ru:/usr/obj/usr/src/sys/XXX i386


	
>Description:
	
	csup is core dumped after some time of work.

# socksify csup cvsupfile
Connected to 195.34.34.240
Updating collection ports-all/cvs
Abort (core dumped)
# gdb /usr/bin/csup csup.core
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-marcel-freebsd"...
Core was generated by `csup'.
Program terminated with signal 6, Aborted.
Reading symbols from /usr/local/lib/libdsocks.so...done.
Loaded symbols for /usr/local/lib/libdsocks.so
Reading symbols from /lib/libcrypto.so.4...done.
Loaded symbols for /lib/libcrypto.so.4
Reading symbols from /lib/libz.so.3...done.
Loaded symbols for /lib/libz.so.3
Reading symbols from /lib/libpthread.so.2...done.
Loaded symbols for /lib/libpthread.so.2
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /usr/lib/libpam.so.3...done.
Loaded symbols for /usr/lib/libpam.so.3
Reading symbols from /lib/libcrypt.so.3...done.
Loaded symbols for /lib/libcrypt.so.3
Reading symbols from /libexec/ld-elf.so.1...done.
Loaded symbols for /libexec/ld-elf.so.1
#0  0x2821549b in pthread_testcancel () from /lib/libpthread.so.2
[New Thread 0x80a8200 (LWP 100239)]
[New Thread 0x80a8000 (LWP 100240)]
[New Thread 0x8068e00 (runnable)]
[New Thread 0x8068c00 (sleeping)]
[New Thread 0x8068a00 (LWP 100245)]
[New Thread 0x8068800 (sleeping)]
[New Thread 0x8068600 (LWP 100134)]
[New Thread 0x8068000 (sleeping)]
(gdb) bt
#0  0x2821549b in pthread_testcancel () from /lib/libpthread.so.2
#1  0x28204772 in sigaction () from /lib/libpthread.so.2
#2  0x281fdd64 in pthread_kill () from /lib/libpthread.so.2
#3  0x281fd561 in raise () from /lib/libpthread.so.2
#4  0x282ee622 in abort () from /lib/libc.so.6
#5  0x28099007 in sys_getsockname (s=6, name=0x1, namelen=0x1)
    at interposition.c:333
#6  0x280a0f4c in socks_addrisok (s=3) at ../lib/address.c:237
#7  0x2809d63e in Rrecvfrom (s=3, buf=0xbf7fcf90, len=1, flags=0, from=0x0,
    fromlen=0xbf7fcec4) at ../lib/udp.c:141
#8  0x280a918e in Rrecvmsg (s=3, msg=0xbf7fcec0, flags=0)
    at ../lib/Rcompat.c:320
#9  0x280a9286 in Rrecv (s=382, msg=0x17e, len=382, flags=382)
    at ../lib/Rcompat.c:280
#10 0x280a92e6 in Rread (d=382, buf=0x17e, nbytes=382) at ../lib/Rcompat.c:231
#11 0x2809a431 in read (d=3, buf=0xbf7fcf90, nbytes=1) at interposition.c:656
#12 0x080520b3 in sock_read (s=3, buf=0xbf7fcf90, size=1)
    at /usr/src/usr.bin/csup/../../contrib/csup/mux.c:258
#13 0x08052100 in sock_readwait (s=3, buf=0xbf7fcf90, size=1)
    at /usr/src/usr.bin/csup/../../contrib/csup/mux.c:274
#14 0x0805344d in receiver_loop (arg=0x806c440)
    at /usr/src/usr.bin/csup/../../contrib/csup/mux.c:1092
#15 0x28205dfb in pthread_create () from /lib/libpthread.so.2
#16 0x282d71e3 in _ctx_start () from /lib/libc.so.6

>How-To-Repeat:
	
	Run: socksify csup cvsupfile

	Content of my cvsupfile:
	*default host=cvsup4.ru.FreeBSD.org
	*default base=/usr
	*default prefix=/usr
	*default release=cvs tag=.
	*default delete use-rel-suffix
	*default compress
	ports-all
>Fix:

	


>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->feedback 
State-Changed-By: mux 
State-Changed-When: Mon Jan 29 22:25:56 UTC 2007 
State-Changed-Why:  
After a quick glance at the net/dante code, and some toying with socksify, 
it seems that the problem here is that socksify just can't cope with 
multithreaded binaries.  I believe that a workaround to this problem would 
be to link csup to libc_r instead of libthr/libpthread. 

You can do this easily by adding this to /etc/libmap.conf: 
%% 
[csup] 
libpthread.so.2 libc_r.so.6 
libpthread.so   libc_r.so 
%% 

If that works, it would confirm my theory about socksify not being able to 
deal correctly with multithreaded binaries and I would suggest you to report 
this problem to dante's authors. 


Responsible-Changed-From-To: freebsd-bugs->mux 
Responsible-Changed-By: mux 
Responsible-Changed-When: Mon Jan 29 22:25:56 UTC 2007 
Responsible-Changed-Why:  
After a quick glance at the net/dante code, and some toying with socksify, 
it seems that the problem here is that socksify just can't cope with 
multithreaded binaries.  I believe that a workaround to this problem would 
be to link csup to libc_r instead of libthr/libpthread. 

You can do this easily by adding this to /etc/libmap.conf: 
%% 
[csup] 
libpthread.so.2 libc_r.so.6 
libpthread.so   libc_r.so 
%% 

If that works, it would confirm my theory about socksify not being able to 
deal correctly with multithreaded binaries and I would suggest you to report 
this problem to dante's authors. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=108518 

From: Sergey Matveychuk <sem@FreeBSD.org>
To: bug-followup@FreeBSD.org, mux@FreeBSD.org
Cc:  
Subject: Re: bin/108518: csup is dumped when run under socksify command
Date: Tue, 30 Jan 2007 12:46:28 +0300

 Unfortunately with the libmap.conf csup can't connect to server at all.
 
 Well, I've tried to reproduce the crash on another machine but I could
 not. May be problem was with my first machine where I upgraded FreeBSD
 5.3->5.5->6.2? But on the second one just 6.2->6.2-PRE->6.2-RELEASE.
 
 I think the PR may be treated as unconfirmed and closed.
 
 Thank you for your attention.
 -- 
 Dixi.
 Sem.
State-Changed-From-To: feedback->closed 
State-Changed-By: linimon 
State-Changed-When: Tue Jun 12 07:56:22 UTC 2007 
State-Changed-Why:  
Closed at submitter's request. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=108518 
>Unformatted:
