From owner-freebsd-threads@FreeBSD.ORG Sun Feb 27 22:03:03 2005 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9EAF616A4CE for ; Sun, 27 Feb 2005 22:03:03 +0000 (GMT) Received: from creme-brulee.marcuscom.com (creme-brulee.marcuscom.com [24.172.16.118]) by mx1.FreeBSD.org (Postfix) with ESMTP id F068B43D49 for ; Sun, 27 Feb 2005 22:03:02 +0000 (GMT) (envelope-from marcus@FreeBSD.org) Received: from shumai.marcuscom.com (shumai.marcuscom.com [192.168.1.4]) j1RM3SrG099962 for ; Sun, 27 Feb 2005 17:03:28 -0500 (EST) (envelope-from marcus@FreeBSD.org) From: Joe Marcus Clarke To: threads@FreeBSD.org Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-p72yxbghLM0v8bsayiIw" Organization: FreeBSD, Inc. Date: Sun, 27 Feb 2005 17:02:59 -0500 Message-Id: <1109541779.39851.11.camel@shumai.marcuscom.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 FreeBSD GNOME Team Port Subject: [PATCH] Increase default stack sizes for libc_r and libthr X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Feb 2005 22:03:03 -0000 --=-p72yxbghLM0v8bsayiIw Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Here are patches to -CURRENT to increase default and initial thread stack sizes to those now in libpthread. All work was adapted from the libpthread changes, and compile and link tested. May I commit, or would you guys like to do it? Thanks. http://www.marcuscom.com/downloads/libc_r.diff http://www.marcuscom.com/downloads/libthr.diff Joe --=20 Joe Marcus Clarke FreeBSD GNOME Team :: gnome@FreeBSD.org FreeNode / #freebsd-gnome http://www.FreeBSD.org/gnome --=-p72yxbghLM0v8bsayiIw Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQBCIkOTb2iPiv4Uz4cRAru7AKCbsQXUrwx3l6tDl2MlWj15A4iOJACeLQrN 9AbYlsHnCUHsAopR9syXWyQ= =vXTA -----END PGP SIGNATURE----- --=-p72yxbghLM0v8bsayiIw-- From owner-freebsd-threads@FreeBSD.ORG Mon Feb 28 00:43:25 2005 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 77D4816A4CE for ; Mon, 28 Feb 2005 00:43:25 +0000 (GMT) Received: from straycat.dhs.org (h0050da134090.ne.client2.attbi.com [24.60.174.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 184F543D31 for ; Mon, 28 Feb 2005 00:43:23 +0000 (GMT) (envelope-from tmclaugh@sdf.lonestar.org) Received: from compass.straycat.dhs.org (compass.straycat.dhs.org [192.168.1.48]) by straycat.dhs.org (8.13.0/8.13.0) with ESMTP id j1S0iEDA011098 for ; Sun, 27 Feb 2005 19:44:16 -0500 (EST) From: Tom McLaughlin To: freebsd-threads@freebsd.org Content-Type: text/plain Date: Sun, 27 Feb 2005 19:43:38 -0500 Message-Id: <1109551418.782.30.camel@compass.straycat.dhs.org> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Subject: Mono's XSP crashes on browser connection X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2005 00:43:25 -0000 Hi, I have a port for Mono's XSP web server for ASP.NET but it has never worked from 1.0 to the latest version, 1.0.6. The crash has always been the same. Finally I've had a chance to sit down with a machine and generate a usable backtrace. The attached backtrace was generated on -STABLE from February 19 using Mono 1.1.4 after connecting to the server with a browser. (Mono 1.1.4 does not build on -CURRENT right now which has become the version I'm focusing on for crashes since 1.2 will be out in late April. The crash does occur on Mono 1.0.6 as well which is in ports and does build on -CURRENT.) If needed, I can regenerate the backtrace using -CURRENT once 1.1.4 builds. The xsp and mono-devel ports can be found here: http://tmclaugh.freeshell.org/files/mono/ Thanks, Tom Backtrace: [tom@europe-monodev test]$ cd /usr/local/share/doc/xsp/test [tom@europe-monodev test]$ gdb /usr/local/bin/mono 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"... (gdb) run /usr/local/lib/mono/1.0/xsp.exe --address 192.168.1.29 Starting program: /usr/local/bin/mono /usr/local/lib/mono/1.0/xsp.exe --address 192.168.1.29 xsp Listening on port: 8080 Listening on address: 192.168.1.29 Root directory: /usr/local/share/doc/xsp/test Hit Return to stop the server. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 4 (LWP 100105)] 0x2836b27c in _lock_acquire (lck=0x8203700, lu=0x8428248, prio=0) at /usr/src/lib/libpthread/sys/lock.c:182 182 /usr/src/lib/libpthread/sys/lock.c: No such file or directory. in /usr/src/lib/libpthread/sys/lock.c (gdb) bt full #0 0x2836b27c in _lock_acquire (lck=0x8203700, lu=0x8428248, prio=0) at /usr/src/lib/libpthread/sys/lock.c:182 i = 0 lval = -1083264012 __func__ = "_lock_acquire" #1 0x2835e537 in mutex_lock_common (curthread=0x8428200, m=0x285668e0, abstime=0x0) at /usr/src/lib/libpthread/thread/thr_mutex.c:519 private = 0 ret = 0 #2 0x2835fb03 in __pthread_mutex_lock (m=0x285668e0) at /usr/src/lib/libpthread/thread/thr_mutex.c:844 curthread = (struct pthread *) 0x8428200 ret = 0 #3 0x080e8af9 in WaitForSingleObjectEx (handle=0x1c98, timeout=500, alertable=0) at handles-private.h:100 ret = 135133339 waited = 1 abstime = {tv_sec = 1164, tv_nsec = 1056} thr_ret = 0 apc_pending = 0 current_thread = 0x1c71 __PRETTY_FUNCTION__ = "WaitForSingleObjectEx" #4 0x080df8d6 in CreateProcess (appname=0x18, cmdline=0x876455c, process_attrs=0x0, thread_attrs=0x0, inherit_handles=1, create_flags=1024, new_environ=0x0, cwd=0x0, startup=0xbf6eb594, process_info=0xbf6eb584) at processes.c:437 cmd = (gchar *) 0x881ca00 "'/usr/local/bin/mcs'" prog = (gchar *) 0x881ca40 "/usr/local/bin/mcs" full_prog = ( gchar *) 0x8809c00 "'/usr/local/bin/mcs' /target:library /debug- /optimize+ /warn:1 /out: \"/var/tmp/tom-temp-aspnet/854b17b2/14374.dll\" /r:\"System.dll\" /r: \"System.Xml.dll\" /r:\"System.Data.dll\" /r:\"System.Web.dll\" /r: \"Syst"... args = ( gchar *) 0x8809800 "/target:library /debug- /optimize+ /warn:1 /out: \"/var/tmp/tom-temp-aspnet/854b17b2/14374.dll\" /r:\"System.dll\" /r: \"System.Xml.dll\" /r:\"System.Data.dll\" /r:\"System.Web.dll\" /r: \"System.Web.Services.dll\" "... args_after_prog = ( gchar *) 0x8809800 "/target:library /debug- /optimize+ /warn:1 /out: \"/var/tmp/tom-temp-aspnet/854b17b2/14374.dll\" /r:\"System.dll\" /r: \"System.Xml.dll\" /r:\"System.Data.dll\" /r:\"System.Web.dll\" /r: \"System.Web.Services.dll\" "... dir = (gchar *) 0x881ca20 "/usr/local/share/doc/xsp/test" env = 1056 stored_dir = 88 stored_prog = 1164 i = 24 ret = 1 stdin_handle = 0xbf6eb584 stdout_handle = 0x18 stderr_handle = 0x0 pid = 23635 tid = 0 process_handle = 0x1c98 thread_handle = 0x1c99 process_handle_data = (struct _WapiHandle_process *) 0xbf6eb52c #5 0x080b764c in ves_icall_System_Diagnostics_Process_Start_internal ( appname=0x875f9d8, cmd=0x8764550, dirname=0x8371700, stdin_handle=0x0, stdout_handle=0x0, stderr_handle=0x0, process_info=0xbf6eb6ac) at process.c:847 ret = 24 dir = (gunichar2 *) 0x0 startinfo = {cb = 68, lpReserved = 0x0, lpDesktop = 0x0, lpTitle = 0x0, dwX = 0, dwY = 0, dwXSize = 0, dwYSize = 0, dwXCountChars = 0, dwYCountChars = 0, dwFillAttribute = 0, dwFlags = STARTF_USESTDHANDLES, wShowWindow = 0, cbReserved2 = 0, lpReserved2 = 0x0, hStdInput = 0x0, hStdOutput = 0x18, hStdError = 0x1a} procinfo = {hProcess = 0x1c98, hThread = 0x1c99, dwProcessId = 23635, dwThreadId = 0} shell_path = (gunichar2 *) 0x8824a00 env_vars = (gchar *) 0x0 free_shell_path = 0 newcmd = (gchar *) 0xbf6eb6ac "" tmp = (gchar *) 0x8760f90 "\020j\200\b" #6 0x28d038f6 in ?? () No symbol table info available. #7 0x0875f9d8 in ?? () No symbol table info available. #8 0x08764550 in ?? () No symbol table info available. #9 0x08371700 in ?? () No symbol table info available. #10 0x00000000 in ?? () No symbol table info available. #11 0x00000018 in ?? () No symbol table info available. #12 0x0000001a in ?? () No symbol table info available. #13 0xbf6eb6ac in ?? () No symbol table info available. #14 0xbf6ebb0c in ?? () No symbol table info available. #15 0x0841a6c8 in ?? () No symbol table info available. #16 0x08808dc0 in ?? () No symbol table info available. #17 0x0875f9d8 in ?? () No symbol table info available. #18 0x08761e10 in ?? () No symbol table info available. #19 0x08760f90 in ?? () No symbol table info available. #20 0xbf6eb640 in ?? () No symbol table info available. #21 0x28d038c4 in ?? () No symbol table info available. #22 0xbf6eb6d8 in ?? () No symbol table info available. #23 0x28d02eb5 in ?? () No symbol table info available. #24 0x0875f9d8 in ?? () No symbol table info available. #25 0x08764550 in ?? () No symbol table info available. #26 0x08371700 in ?? () No symbol table info available. #27 0x00000000 in ?? () No symbol table info available. #28 0x00000018 in ?? () No symbol table info available. #29 0x0000001a in ?? () No symbol table info available. #30 0xbf6eb6ac in ?? () No symbol table info available. #31 0xbf6eb684 in ?? () No symbol table info available. #32 0x08070f7f in x86_magic_trampoline (eax=141949400, ecx=141968720, edx=137828096, esi=0, edi=24, ebx=26, code=0x8760f90 "\020j\200\b", m=0xbf6eb684) at tramp-x86.c:123 reg = 8 '\b' disp = 141949400 o = 0x18 addr = 0x8761e10 __PRETTY_FUNCTION__ = "x86_magic_trampoline" Previous frame inner to this frame (corrupt stack?) (gdb) -- BSD# Project - Porting Mono to FreeBSD http://forge.novell.com/modules/xfmod/project/?bsd-sharp From owner-freebsd-threads@FreeBSD.ORG Mon Feb 28 04:45:39 2005 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C220416A4CE; Mon, 28 Feb 2005 04:45:39 +0000 (GMT) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5111A43D39; Mon, 28 Feb 2005 04:45:39 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) j1S4jcfo009688; Sun, 27 Feb 2005 23:45:38 -0500 (EST) Date: Sun, 27 Feb 2005 23:45:38 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Joe Marcus Clarke In-Reply-To: <1109541779.39851.11.camel@shumai.marcuscom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) cc: threads@freebsd.org Subject: Re: [PATCH] Increase default stack sizes for libc_r and libthr X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Daniel Eischen List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2005 04:45:39 -0000 On Sun, 27 Feb 2005, Joe Marcus Clarke wrote: > Here are patches to -CURRENT to increase default and initial thread > stack sizes to those now in libpthread. All work was adapted from the > libpthread changes, and compile and link tested. May I commit, or would > you guys like to do it? Thanks. > > http://www.marcuscom.com/downloads/libc_r.diff The libc_r diffs look OK to me. -- Dan From owner-freebsd-threads@FreeBSD.ORG Mon Feb 28 05:48:06 2005 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C855816A4CE for ; Mon, 28 Feb 2005 05:48:06 +0000 (GMT) Received: from straycat.dhs.org (h0050da134090.ne.client2.attbi.com [24.60.174.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2AC8143D2D for ; Mon, 28 Feb 2005 05:48:06 +0000 (GMT) (envelope-from tmclaugh@sdf.lonestar.org) Received: from compass.straycat.dhs.org (compass.straycat.dhs.org [192.168.1.48]) by straycat.dhs.org (8.13.0/8.13.0) with ESMTP id j1S5n13X031765 for ; Mon, 28 Feb 2005 00:49:01 -0500 (EST) From: Tom McLaughlin To: freebsd-threads@freebsd.org Content-Type: text/plain Date: Mon, 28 Feb 2005 00:48:24 -0500 Message-Id: <1109569704.782.50.camel@compass.straycat.dhs.org> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Subject: Mono crash when executing an extenal command X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2005 05:48:06 -0000 Hi, the backtrace listed at the end was collected on a -STABLE machine (20050219) using Mono 1.1.4[1]. Below is the C# code that caused it. It should just list the contents of the current directory. It does list them but crashes afterwards. ls-exec.cs --- using System.Diagnostics; class T { static void Main() { Process.Start ("ls"); } } --- Using Process.Start in C# to invoke an external command consistently causes Mono to crash. Can someone take a look at this? Is this a FreeBSD bug in libpthread or possibly a Mono on FreeBSD bug. In case of the latter would anyone be able to fix it? I am C clueless here. Let me know if you have any questions. Thanks. Tom [1] Mono 1.1.4 port: http://tmclaugh.freeshell.org/files/mono/mono-devel-1.1.4.shar backtrace: [tom@europe-monodev mono]$ mcs ls-exec.cs [tom@europe-monodev mono]$ gdb /usr/local/bin/mono 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"... Program exited with code 02. (gdb) run ls-exec.exe Starting program: /usr/local/bin/mono ls-exec.exe Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1 (LWP 100180)] 0x2836b27c in _lock_acquire (lck=0x823dd80, lu=0x81b0048, prio=0) at /usr/src/lib/libpthread/sys/lock.c:182 182 /usr/src/lib/libpthread/sys/lock.c: No such file or directory. in /usr/src/lib/libpthread/sys/lock.c (gdb) hello-world_gtk-sharp.cs switches-fixed.cs ls-exec.cs switches-fixed.exe ls-exec.exe switches.cs mcs_crash.cs switches.exe mono.core (gdb) bt full #0 0x2836b27c in _lock_acquire (lck=0x823dd80, lu=0x81b0048, prio=0) at /usr/src/lib/libpthread/sys/lock.c:182 i = 0 lval = -1077942736 __func__ = "_lock_acquire" #1 0x2835e537 in mutex_lock_common (curthread=0x81b0000, m=0x28566188, abstime=0x0) at /usr/src/lib/libpthread/thread/thr_mutex.c:519 private = 0 ret = 0 #2 0x2835fb03 in __pthread_mutex_lock (m=0x28566188) at /usr/src/lib/libpthread/thread/thr_mutex.c:844 curthread = (struct pthread *) 0x81b0000 ret = 0 #3 0x080e8af9 in WaitForSingleObjectEx (handle=0x1e22, timeout=500, alertable=0) at handles-private.h:100 ret = 135133339 waited = 1 abstime = {tv_sec = 11180, tv_nsec = 11072} thr_ret = 0 apc_pending = 0 current_thread = 0x1e17 __PRETTY_FUNCTION__ = "WaitForSingleObjectEx" #4 0x080df8d6 in CreateProcess (appname=0x1, cmdline=0x8278fec, process_attrs=0x0, thread_attrs=0x0, inherit_handles=1, create_flags=1024, new_environ=0x0, cwd=0x0, startup=0xbfbfe7d0, process_info=0xbfbfe7c0) at processes.c:437 cmd = (gchar *) 0x82b8680 "/usr/local/bin/ksh" prog = (gchar *) 0x82b8720 "/usr/local/bin/ksh" full_prog = (gchar *) 0x82b8780 "'/usr/local/bin/ksh' -c 'ls'" args = (gchar *) 0x82b7860 "-c 'ls'" args_after_prog = (gchar *) 0x82b7860 "-c 'ls'" dir = (gchar *) 0x82b8700 "/home/tom/projects/mono" env = 11072 stored_dir = 10136 stored_prog = 11180 i = 1 ret = 1 stdin_handle = 0xbfbfe7c0 stdout_handle = 0x1 stderr_handle = 0x0 pid = 26334 tid = 0 process_handle = 0x1e22 thread_handle = 0x1e23 process_handle_data = (struct _WapiHandle_process *) 0xbfbfe768 #5 0x080b764c in ves_icall_System_Diagnostics_Process_Start_internal ( appname=0x0, cmd=0x8278fe0, dirname=0x81e6e30, stdin_handle=0x0, stdout_handle=0x0, stderr_handle=0x0, process_info=0xbfbfe8e8) at process.c:847 ret = 137067008 dir = (gunichar2 *) 0x0 startinfo = {cb = 68, lpReserved = 0x0, lpDesktop = 0x0, lpTitle = 0x0, dwX = 0, dwY = 0, dwXSize = 0, dwYSize = 0, dwXCountChars = 0, dwYCountChars = 0, dwFillAttribute = 0, dwFlags = STARTF_USESTDHANDLES, wShowWindow = 0, cbReserved2 = 0, lpReserved2 = 0x0, hStdInput = 0x0, hStdOutput = 0x1, hStdError = 0x2} procinfo = {hProcess = 0x1e22, hThread = 0x1e23, dwProcessId = 26334, dwThreadId = 0} shell_path = (gunichar2 *) 0x82ba1c0 env_vars = (gchar *) 0x0 free_shell_path = 0 newcmd = (gchar *) 0xbfbfe8e8 "" tmp = (gchar *) 0x82b7860 "-c 'ls'" #6 0x2863a27e in ?? () No symbol table info available. #7 0x00000000 in ?? () No symbol table info available. #8 0x08278fe0 in ?? () No symbol table info available. #9 0x081e6e30 in ?? () No symbol table info available. #10 0x00000000 in ?? () No symbol table info available. #11 0x00000001 in ?? () No symbol table info available. #12 0x00000002 in ?? () No symbol table info available. #13 0xbfbfe8e8 in ?? () No symbol table info available. #14 0x081a71e0 in ?? () No symbol table info available. #15 0x081a71c8 in ?? () No symbol table info available. #16 0x0829afc0 in ?? () No symbol table info available. #17 0x00000000 in ?? () No symbol table info available. #18 0x08275fa0 in ?? () No symbol table info available. #19 0x081eaf30 in ?? () No symbol table info available. #20 0xbfbfe87c in ?? () No symbol table info available. #21 0x2863a24c in ?? () No symbol table info available. #22 0xbfbfe914 in ?? () No symbol table info available. #23 0x28639725 in ?? () No symbol table info available. #24 0x00000000 in ?? () No symbol table info available. #25 0x081ebfc0 in ?? () No symbol table info available. #26 0x081e6e30 in ?? () No symbol table info available. #27 0x00000000 in ?? () No symbol table info available. #28 0x00000001 in ?? () No symbol table info available. #29 0x00000002 in ?? () No symbol table info available. #30 0xbfbfe8e8 in ?? () No symbol table info available. #31 0xbfbfe8c0 in ?? () No symbol table info available. #32 0x08070f7f in x86_magic_trampoline (eax=0, ecx=136232896, edx=136212016, esi=0, edi=1, ebx=2, code=0x81eaf30 "\200\236\033\b", m=0xbfbfe8c0) at tramp-x86.c:123 reg = 8 '\b' disp = 0 o = 0x1 addr = 0x8275fa0 __PRETTY_FUNCTION__ = "x86_magic_trampoline" Previous frame inner to this frame (corrupt stack?) (gdb) -- BSD# Project - Porting Mono to FreeBSD http://forge.novell.com/modules/xfmod/project/?bsd-sharp From owner-freebsd-threads@FreeBSD.ORG Mon Feb 28 06:38:19 2005 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 85C6A16A4CE; Mon, 28 Feb 2005 06:38:19 +0000 (GMT) Received: from creme-brulee.marcuscom.com (creme-brulee.marcuscom.com [24.172.16.118]) by mx1.FreeBSD.org (Postfix) with ESMTP id E1D2B43D1D; Mon, 28 Feb 2005 06:38:18 +0000 (GMT) (envelope-from marcus@FreeBSD.org) Received: from shumai.marcuscom.com (shumai.marcuscom.com [192.168.1.4]) j1S6cjPn008047; Mon, 28 Feb 2005 01:38:45 -0500 (EST) (envelope-from marcus@FreeBSD.org) From: Joe Marcus Clarke To: Daniel Eischen In-Reply-To: References: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-Hn0f0S21oQP4kDiFLSP4" Organization: FreeBSD, Inc. Date: Mon, 28 Feb 2005 01:38:14 -0500 Message-Id: <1109572694.39851.45.camel@shumai.marcuscom.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 FreeBSD GNOME Team Port cc: threads@FreeBSD.org Subject: Re: [PATCH] Increase default stack sizes for libc_r and libthr X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2005 06:38:19 -0000 --=-Hn0f0S21oQP4kDiFLSP4 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sun, 2005-02-27 at 23:45 -0500, Daniel Eischen wrote: > On Sun, 27 Feb 2005, Joe Marcus Clarke wrote: >=20 > > Here are patches to -CURRENT to increase default and initial thread > > stack sizes to those now in libpthread. All work was adapted from the > > libpthread changes, and compile and link tested. May I commit, or woul= d > > you guys like to do it? Thanks. > > > > http://www.marcuscom.com/downloads/libc_r.diff >=20 > The libc_r diffs look OK to me. So I may commit these? I'll copy mtm on the libthr patches just to make sure he sees them. Thanks. Joe >=20 --=20 Joe Marcus Clarke FreeBSD GNOME Team :: gnome@FreeBSD.org FreeNode / #freebsd-gnome http://www.FreeBSD.org/gnome --=-Hn0f0S21oQP4kDiFLSP4 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQBCIrxWb2iPiv4Uz4cRAnxuAJ93BjGpzhtAZ1315+PZ3woXQETWKgCgh8Os RJ81Pd23sDlxMARcsIWLljY= =Xq4F -----END PGP SIGNATURE----- --=-Hn0f0S21oQP4kDiFLSP4-- From owner-freebsd-threads@FreeBSD.ORG Mon Feb 28 06:39:35 2005 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 60E8816A4CE for ; Mon, 28 Feb 2005 06:39:35 +0000 (GMT) Received: from straycat.dhs.org (h0050da134090.ne.client2.attbi.com [24.60.174.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id BE5D243D4C for ; Mon, 28 Feb 2005 06:39:34 +0000 (GMT) (envelope-from tmclaugh@sdf.lonestar.org) Received: from compass.straycat.dhs.org (compass.straycat.dhs.org [192.168.1.48]) by straycat.dhs.org (8.13.0/8.13.0) with ESMTP id j1S6eT8m013160 for ; Mon, 28 Feb 2005 01:40:30 -0500 (EST) From: Tom McLaughlin To: freebsd-threads@freebsd.org In-Reply-To: <1109569704.782.50.camel@compass.straycat.dhs.org> References: <1109569704.782.50.camel@compass.straycat.dhs.org> Content-Type: text/plain Date: Mon, 28 Feb 2005 01:39:53 -0500 Message-Id: <1109572793.782.82.camel@compass.straycat.dhs.org> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Subject: Re: Mono crash when executing an extenal command X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2005 06:39:35 -0000 On Mon, 2005-02-28 at 00:48 -0500, Tom McLaughlin wrote: > Hi, the backtrace listed at the end was collected on a -STABLE machine > (20050219) using Mono 1.1.4[1]. Below is the C# code that caused it. > It should just list the contents of the current directory. It does list > them but crashes afterwards. > Here's also a second backtrace that appears slightly different. This C# better resembled that from the program where I first found the crash. (You guys are going to love Mono and me after a while... Or the opposite of that. ;) Thanks. Tom ls-exec_ProcessStartInfo.cs --- using System.Diagnostics; class T { static void Main() { ProcessStartInfo pi = new ProcessStartInfo (); pi.FileName = "ls"; pi.RedirectStandardOutput = true; pi.UseShellExecute = false; pi.Arguments = "-al"; Process.Start (pi); } } --- [tom@europe-monodev mono]$ mcs ls-exec_ProcessStartInfo.cs [tom@europe-monodev mono]$ gdb /usr/local/bin/mono mono.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 `mono'. Program terminated with signal 6, Aborted. Reading symbols from /usr/local/lib/libgthread-2.0.so.400...done. Loaded symbols for /usr/local/lib/libgthread-2.0.so.400 Reading symbols from /usr/local/lib/libgmodule-2.0.so.400...done. Loaded symbols for /usr/local/lib/libgmodule-2.0.so.400 Reading symbols from /usr/local/lib/libglib-2.0.so.400...done. Loaded symbols for /usr/local/lib/libglib-2.0.so.400 Reading symbols from /usr/local/lib/libiconv.so.3...done. Loaded symbols for /usr/local/lib/libiconv.so.3 Reading symbols from /lib/libm.so.3...done. Loaded symbols for /lib/libm.so.3 Reading symbols from /usr/lib/libpthread.so.1...done. Loaded symbols for /usr/lib/libpthread.so.1 Reading symbols from /lib/libc.so.5...done. Loaded symbols for /lib/libc.so.5 Reading symbols from /usr/local/lib/libintl.so.6...done. Loaded symbols for /usr/local/lib/libintl.so.6 Reading symbols from /libexec/ld-elf.so.1...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x2836a3cb in kse_thr_interrupt () at kse_thr_interrupt.S:2 2 kse_thr_interrupt.S: No such file or directory. in kse_thr_interrupt.S (gdb) bt full #0 0x2836a3cb in kse_thr_interrupt () at kse_thr_interrupt.S:2 No locals. #1 0x2835adde in _thr_sig_add (pthread=0x81b0000, sig=6, info=0x0) at /usr/src/lib/libpthread/thread/thr_sig.c:974 siginfo = {si_signo = 136715168, si_errno = 16777224, si_code = 674635894, si_pid = 674682044, si_uid = 136735360, si_status = -1077943988, si_addr = 0x2835c8c7, si_value = { sigval_int = 672944208, sigval_ptr = 0x281c5050}, si_band = 135962676, __spare__ = {-1077943988, 674613305, 1, 136735360, 672944208, 672895960, 674673066}} kmbx = (struct kse_mailbox *) 0x0 curthread = (struct pthread *) 0x1 restart = 0 suppress_handler = 0 fromproc = 0 sigfunc = (__sighandler_t *) 0 #2 0x2835b1f5 in _thr_sig_send (pthread=0x81b0000, sig=6) at /usr/src/lib/libpthread/thread/thr_sig.c:1106 curthread = (struct pthread *) 0x81b0000 kmbx = (struct kse_mailbox *) 0x0 #3 0x2835528d in _pthread_kill (pthread=0x81b0000, sig=6) at /usr/src/lib/libpthread/thread/thr_kill.c:60 curthread = (struct pthread *) 0x81b0000 ret = 0 #4 0x28354c5c in _raise (sig=1) at /usr/src/lib/libpthread/thread/thr_raise.c:46 ret = -1077943808 #5 0x28425b67 in abort () at /usr/src/lib/libc/stdlib/abort.c:69 act = {__sigaction_u = {__sa_handler = 0x1, __sa_sigaction = 0x1}, sa_flags = 672925696, sa_mask = {__bits = {4294967263, 4294967295, 4294967295, 4294967295}}} #6 0x281f90af in g_logv () from /usr/local/lib/libglib-2.0.so.400 No symbol table info available. #7 0x281f914d in g_log () from /usr/local/lib/libglib-2.0.so.400 No symbol table info available. #8 0x080e8b2a in WaitForSingleObjectEx (handle=0x1e4f, timeout=500, alertable=0) at wait.c:70 ret = 135133339 waited = 1 abstime = {tv_sec = 12260, tv_nsec = 12348} thr_ret = 382 apc_pending = 0 current_thread = 0x1e42 __PRETTY_FUNCTION__ = "WaitForSingleObjectEx" #9 0x080df8d6 in CreateProcess (appname=0x8, cmdline=0x81e8fb4, process_attrs=0x0, thread_attrs=0x0, inherit_handles=1, create_flags=1024, new_environ=0x0, cwd=0x0, startup=0xbfbfe7f8, process_info=0xbfbfe7e8) at processes.c:437 cmd = (gchar *) 0x82b8a10 "'/bin/ls'" prog = (gchar *) 0x82b8a90 "/bin/ls" full_prog = (gchar *) 0x82b8ac0 "'/bin/ls' -al" args = (gchar *) 0x82b8a80 "-al" args_after_prog = (gchar *) 0x82b8a80 "-al" dir = (gchar *) 0x82b7840 "/home/tom/projects/mono" env = 12348 stored_dir = 11244 stored_prog = 12260 i = 8 ret = 1 stdin_handle = 0xbfbfe7e8 stdout_handle = 0x8 stderr_handle = 0x1 pid = 26548 tid = 0 process_handle = 0x1e4f thread_handle = 0x1e50 process_handle_data = (struct _WapiHandle_process *) 0xbfbfe790 #10 0x080b764c in ves_icall_System_Diagnostics_Process_Start_internal ( appname=0x81e8fc0, cmd=0x81e8fa8, dirname=0x81e3e50, stdin_handle=0x17e, stdout_handle=0x17e, stderr_handle=0x17e, process_info=0xbfbfe910) at process.c:847 ret = 8 dir = (gunichar2 *) 0x1 startinfo = {cb = 68, lpReserved = 0x0, lpDesktop = 0x0, lpTitle = 0x0, dwX = 0, dwY = 0, dwXSize = 0, dwYSize = 0, dwXCountChars = 0, dwYCountChars = 0, dwFillAttribute = 0, dwFlags = STARTF_USESTDHANDLES, wShowWindow = 0, cbReserved2 = 0, lpReserved2 = 0x0, hStdInput = 0x0, hStdOutput = 0x8, hStdError = 0x2} procinfo = {hProcess = 0x1e4f, hThread = 0x1e50, dwProcessId = 26548, dwThreadId = 0} shell_path = (gunichar2 *) 0x82b77c0 env_vars = (gchar *) 0x0 free_shell_path = 382 newcmd = (gchar *) 0xbfbfe910 "" tmp = (gchar *) 0x81e7f30 "hn\033\b" #11 0x2863a336 in ?? () No symbol table info available. #12 0x081e8fc0 in ?? () No symbol table info available. #13 0x081e8fa8 in ?? () No symbol table info available. #14 0x081e3e50 in ?? () No symbol table info available. #15 0x00000000 in ?? () No symbol table info available. #16 0x00000008 in ?? () No symbol table info available. #17 0x00000002 in ?? () No symbol table info available. #18 0xbfbfe910 in ?? () No symbol table info available. #19 0x081a7200 in ?? () No symbol table info available. #20 0x081a71e8 in ?? () No symbol table info available. #21 0x08299f40 in ?? () No symbol table info available. #22 0x081e8fc0 in ?? () No symbol table info available. #23 0x08272fa0 in ?? () No symbol table info available. #24 0x081e7f30 in ?? () No symbol table info available. #25 0xbfbfe8a4 in ?? () No symbol table info available. #26 0x2863a304 in ?? () No symbol table info available. #27 0xbfbfe93c in ?? () No symbol table info available. #28 0x286397c5 in ?? () No symbol table info available. #29 0x081e8fc0 in ?? () No symbol table info available. #30 0x081e8fa8 in ?? () No symbol table info available. #31 0x081e3e50 in ?? () No symbol table info available. #32 0x00000000 in ?? () No symbol table info available. #33 0x00000008 in ?? () No symbol table info available. #34 0x00000002 in ?? () No symbol table info available. #35 0xbfbfe910 in ?? () No symbol table info available. #36 0xbfbfe8e8 in ?? () No symbol table info available. #37 0x08070f7f in x86_magic_trampoline (eax=136220608, ecx=136220584, edx=136199760, esi=0, edi=8, ebx=2, code=0x81e7f30 "hn\033\b", m=0xbfbfe8e8) at tramp-x86.c:123 reg = 8 '\b' disp = 136220608 o = 0x8
addr = 0x8272fa0 __PRETTY_FUNCTION__ = "x86_magic_trampoline" Previous frame inner to this frame (corrupt stack?) (gdb) -- BSD# Project - Porting Mono to FreeBSD http://forge.novell.com/modules/xfmod/project/?bsd-sharp From owner-freebsd-threads@FreeBSD.ORG Mon Feb 28 11:02:03 2005 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CEAE816A4DD for ; Mon, 28 Feb 2005 11:02:03 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 62C0F43D58 for ; Mon, 28 Feb 2005 11:02:03 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j1SB23Wi006803 for ; Mon, 28 Feb 2005 11:02:03 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.1/8.13.1/Submit) id j1SB22qM006797 for freebsd-threads@freebsd.org; Mon, 28 Feb 2005 11:02:02 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 28 Feb 2005 11:02:02 GMT Message-Id: <200502281102.j1SB22qM006797@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-threads@FreeBSD.org Subject: Current problem reports assigned to you X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2005 11:02:04 -0000 Current FreeBSD problem reports Critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2004/04/22] threads/65883threads libkse's sigwait does not work after fork o [2005/01/26] threads/76690threads fork hang in child for (-lc_r & -lthr) 2 problems total. Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2000/07/18] kern/20016 threads pthreads: Cannot set scheduling timer/Can o [2000/08/26] kern/20861 threads libc_r does not honor socket timeouts o [2001/01/20] threads/24472threads libc_r does not honor SO_SNDTIMEO/SO_RCVT o [2001/01/25] threads/24632threads libc_r delicate deviation from libc in ha o [2001/01/25] kern/24641 threads pthread_rwlock_rdlock can deadlock o [2001/11/26] bin/32295 threads pthread dont dequeue signals o [2002/02/01] threads/34536threads accept() blocks other threads o [2002/05/25] kern/38549 threads the procces compiled whith pthread stoppe o [2002/06/27] threads/39922threads [PATCH?] Threaded applications executed w o [2002/08/04] kern/41331 threads Pthread library open sets O_NONBLOCK flag o [2003/03/02] threads/48856threads Setting SIGCHLD to SIG_IGN still leaves z o [2003/03/10] threads/49087threads Signals lost in programs linked with libc o [2003/05/08] threads/51949threads thread in accept cannot be cancelled s [2004/03/15] kern/64313 threads FreeBSD (OpenBSD) pthread implicit set/un o [2004/08/26] threads/70975threads unexpected and unreliable behaviour when o [2004/09/14] threads/71725threads Mysql Crashes frequently giving Sock Erro o [2004/10/05] threads/72353threads Assertion fails in /usr/src/lib/libpthrea o [2004/10/07] threads/72429threads threads blocked in stdio (fgets, etc) are o [2004/10/21] threads/72953threads fork() unblocks blocked signals w/o PTHRE o [2004/11/25] threads/74370threads Cannot get lwp 0 registers in gdb o [2004/12/08] threads/74856threads dig/host broken w/ libthr o [2004/12/19] threads/75273threads FBSD 5.3 libpthread (KSE) bug o [2004/12/21] threads/75374threads pthread_kill() ignores SA_SIGINFO flag o [2005/01/04] threads/75795threads applications linked with -lc_r can't clos o [2005/01/26] threads/76694threads fork cause hang in dup()/close() function 25 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2000/05/26] kern/18824 threads gethostbyname is not thread safe o [2000/06/13] kern/19247 threads uthread_sigaction.c does not do anything o [2000/10/21] kern/22190 threads A threaded read(2) from a socketpair(2) f o [2001/09/09] threads/30464threads pthread mutex attributes -- pshared o [2002/05/02] threads/37676threads libc_r: msgsnd(), msgrcv(), pread(), pwri s [2002/07/16] threads/40671threads pthread_cancel doesn't remove thread from o [2004/07/13] threads/69020threads pthreads library leaks _gc_mutex o [2004/09/21] threads/71966threads Mlnet Core Dumped : Fatal error '_pq_inse o [2004/11/21] threads/74180threads KSE problem. Applications those riched ma o [2005/01/20] threads/76513threads libpthread is not working o [2005/01/29] threads/76821threads Add access to gdb unique thread id o [2005/02/01] threads/76938threads include/unistd.h: ttyname_r prototype mis 12 problems total. From owner-freebsd-threads@FreeBSD.ORG Mon Feb 28 13:48:46 2005 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2A43F16A4CE; Mon, 28 Feb 2005 13:48:46 +0000 (GMT) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id C313F43D55; Mon, 28 Feb 2005 13:48:45 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) j1SDmiBr007499; Mon, 28 Feb 2005 08:48:44 -0500 (EST) Date: Mon, 28 Feb 2005 08:48:44 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Joe Marcus Clarke In-Reply-To: <1109572694.39851.45.camel@shumai.marcuscom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) cc: threads@freebsd.org Subject: Re: [PATCH] Increase default stack sizes for libc_r and libthr X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Daniel Eischen List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2005 13:48:46 -0000 On Mon, 28 Feb 2005, Joe Marcus Clarke wrote: > On Sun, 2005-02-27 at 23:45 -0500, Daniel Eischen wrote: > > On Sun, 27 Feb 2005, Joe Marcus Clarke wrote: > > > > > Here are patches to -CURRENT to increase default and initial thread > > > stack sizes to those now in libpthread. All work was adapted from the > > > libpthread changes, and compile and link tested. May I commit, or would > > > you guys like to do it? Thanks. > > > > > > http://www.marcuscom.com/downloads/libc_r.diff > > > > The libc_r diffs look OK to me. > > So I may commit these? I'll copy mtm on the libthr patches just to make > sure he sees them. Thanks. I thought that's what I implied above ;-) -- Dan From owner-freebsd-threads@FreeBSD.ORG Mon Feb 28 17:12:41 2005 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D4DFF16A4CE; Mon, 28 Feb 2005 17:12:41 +0000 (GMT) Received: from rooster.cisco.com (hen.cisco.com [64.102.19.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id 547D343D4C; Mon, 28 Feb 2005 17:12:41 +0000 (GMT) (envelope-from marcus@FreeBSD.org) Received: from [64.102.192.53] (dhcp-64-102-192-53.cisco.com [64.102.192.53]) by rooster.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id j1SHCee17777; Mon, 28 Feb 2005 12:12:40 -0500 (EST) Message-ID: <42235108.4010000@FreeBSD.org> Date: Mon, 28 Feb 2005 12:12:40 -0500 From: Joe Marcus Clarke Organization: FreeBSD, Inc. User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Eischen References: In-Reply-To: X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: threads@FreeBSD.org Subject: Re: [PATCH] Increase default stack sizes for libc_r and libthr X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2005 17:12:41 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Daniel Eischen wrote: | On Mon, 28 Feb 2005, Joe Marcus Clarke wrote: | | |>On Sun, 2005-02-27 at 23:45 -0500, Daniel Eischen wrote: |> |>>On Sun, 27 Feb 2005, Joe Marcus Clarke wrote: |>> |>> |>>>Here are patches to -CURRENT to increase default and initial thread |>>>stack sizes to those now in libpthread. All work was adapted from the |>>>libpthread changes, and compile and link tested. May I commit, or would |>>>you guys like to do it? Thanks. |>>> |>>>http://www.marcuscom.com/downloads/libc_r.diff |>> |>>The libc_r diffs look OK to me. |> |>So I may commit these? I'll copy mtm on the libthr patches just to make |>sure he sees them. Thanks. | | | I thought that's what I implied above ;-) I wanted to be absolutely sure since I'm not a src committer by nature. ~ Thanks again. Joe | - -- Joe Marcus Clarke FreeBSD GNOME Team :: gnome@FreeBSD.org FreeNode / #freebsd-gnome http://www.FreeBSD.org/gnome -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCI1EIb2iPiv4Uz4cRAuxDAJkBr7cyuLjahBwZcxZNHGwNk0Cd1gCdGPIB 5x0EC6op+IwmxGQuYTbZADM= =mJNF -----END PGP SIGNATURE----- From owner-freebsd-threads@FreeBSD.ORG Tue Mar 1 15:23:15 2005 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 96EA516A4CE for ; Tue, 1 Mar 2005 15:23:15 +0000 (GMT) Received: from mail.mynet.cz (74.mynet.cz [217.11.249.74]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1D67643D2D for ; Tue, 1 Mar 2005 15:23:14 +0000 (GMT) (envelope-from jp@devnull.cz) Received: from axxem.hide.subzone.cz (subzone.osad.prg.mynet.cz [82.119.254.162]) by mail.mynet.cz (8.12.11/8.12.11) with ESMTP id j21FNH29008374 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO) for ; Tue, 1 Mar 2005 16:23:19 +0100 (CET) (envelope-from jp@devnull.cz) Date: Tue, 1 Mar 2005 16:23:04 +0100 (CET) From: Jan Pechanec X-X-Sender: jp@axxem.hide.subzone.cz To: freebsd-threads@freebsd.org Message-ID: <20050301155539.Q27541@axxem.hide.subzone.cz> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: 4.x: masking signals has no effect without signal handlers installed X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2005 15:23:15 -0000 hi all, I can see that masking signals under 4.10|11 has no effect unless I install respective signal handlers. Is it a bug, a feature or my mistake? The same program compiled under 5.3, tried with all three threads libraries, works as I would expect - masking has effect even without handlers. in this example run under 4.10|11, ^C terminates the program, compiled with: gcc -pthread -o pthread_sigmask pthread_sigmask.c if signal() call is commented out, ^C has no effect. How can I block all signals for particular thread without creating all sighandlers? Unfortunately using 5.3 is not possible for me now. regards, j. #include #include #include #include #define FOR_EVER (24*3600) void sig_int_handler(int sig) { printf("SIGINT catched\n"); } int main(void) { sigset_t set; /* if (signal(SIGINT, sig_int_handler) == SIG_ERR) { perror("signal"); exit(1); } */ sigfillset(&set); if (pthread_sigmask(SIG_SETMASK, &set, NULL) != 0) { printf("pthread_sigmask() error\n"); exit(1); } // for ( ; ; ) ; sleep(FOR_EVER); printf("alive again\n"); return 0; } -- Jan Pechanec From owner-freebsd-threads@FreeBSD.ORG Wed Mar 2 05:40:56 2005 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4E13E16A4CE for ; Wed, 2 Mar 2005 05:40:56 +0000 (GMT) Received: from straycat.dhs.org (h0050da134090.ne.client2.attbi.com [24.60.174.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7BEEF43D4C for ; Wed, 2 Mar 2005 05:40:55 +0000 (GMT) (envelope-from tmclaugh@sdf.lonestar.org) Received: from compass.straycat.dhs.org (compass.straycat.dhs.org [192.168.1.48]) by straycat.dhs.org (8.13.0/8.13.0) with ESMTP id j225fpqd016594 for ; Wed, 2 Mar 2005 00:41:52 -0500 (EST) From: Tom McLaughlin To: freebsd-threads@freebsd.org In-Reply-To: <1109551418.782.30.camel@compass.straycat.dhs.org> References: <1109551418.782.30.camel@compass.straycat.dhs.org> Content-Type: text/plain Date: Wed, 02 Mar 2005 00:41:19 -0500 Message-Id: <1109742079.777.15.camel@compass.straycat.dhs.org> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Subject: Re: Mono's XSP crashes on browser connection X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2005 05:40:56 -0000 Alright, people can ignore this Mono crash and just look at the mcs one in my other email. Both XSP and mcs are experiencing the same bug it looks like and the mcs code is much simpler and easier to illustrate. Sorry for the noise. I'm just trying to bang these out since I've been sitting on them so long. Thanks. Tom On Sun, 2005-02-27 at 19:43 -0500, Tom McLaughlin wrote: > Hi, I have a port for Mono's XSP web server for ASP.NET but it has never > worked from 1.0 to the latest version, 1.0.6. The crash has always been > the same. Finally I've had a chance to sit down with a machine and > generate a usable backtrace. The attached backtrace was generated on > -STABLE from February 19 using Mono 1.1.4 after connecting to the server > with a browser. (Mono 1.1.4 does not build on -CURRENT right now which > has become the version I'm focusing on for crashes since 1.2 will be out > in late April. The crash does occur on Mono 1.0.6 as well which is in > ports and does build on -CURRENT.) If needed, I can regenerate the > backtrace using -CURRENT once 1.1.4 builds. The xsp and mono-devel > ports can be found here: > > http://tmclaugh.freeshell.org/files/mono/ > > Thanks, > Tom > > > Backtrace: > > [tom@europe-monodev test]$ cd /usr/local/share/doc/xsp/test > [tom@europe-monodev test]$ gdb /usr/local/bin/mono > 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"... > (gdb) run /usr/local/lib/mono/1.0/xsp.exe --address 192.168.1.29 > Starting program: /usr/local/bin/mono /usr/local/lib/mono/1.0/xsp.exe > --address 192.168.1.29 > xsp > Listening on port: 8080 > Listening on address: 192.168.1.29 > Root directory: /usr/local/share/doc/xsp/test > Hit Return to stop the server. > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 4 (LWP 100105)] > 0x2836b27c in _lock_acquire (lck=0x8203700, lu=0x8428248, prio=0) > at /usr/src/lib/libpthread/sys/lock.c:182 > 182 /usr/src/lib/libpthread/sys/lock.c: No such file or directory. > in /usr/src/lib/libpthread/sys/lock.c > (gdb) bt full > #0 0x2836b27c in _lock_acquire (lck=0x8203700, lu=0x8428248, prio=0) > at /usr/src/lib/libpthread/sys/lock.c:182 > i = 0 > lval = -1083264012 > __func__ = "_lock_acquire" > #1 0x2835e537 in mutex_lock_common (curthread=0x8428200, m=0x285668e0, > abstime=0x0) at /usr/src/lib/libpthread/thread/thr_mutex.c:519 > private = 0 > ret = 0 > #2 0x2835fb03 in __pthread_mutex_lock (m=0x285668e0) > at /usr/src/lib/libpthread/thread/thr_mutex.c:844 > curthread = (struct pthread *) 0x8428200 > ret = 0 > #3 0x080e8af9 in WaitForSingleObjectEx (handle=0x1c98, timeout=500, > alertable=0) at handles-private.h:100 > ret = 135133339 > waited = 1 > abstime = {tv_sec = 1164, tv_nsec = 1056} > thr_ret = 0 > apc_pending = 0 > current_thread = 0x1c71 > __PRETTY_FUNCTION__ = "WaitForSingleObjectEx" > #4 0x080df8d6 in CreateProcess (appname=0x18, cmdline=0x876455c, > process_attrs=0x0, thread_attrs=0x0, inherit_handles=1, > create_flags=1024, > new_environ=0x0, cwd=0x0, startup=0xbf6eb594, > process_info=0xbf6eb584) > at processes.c:437 > cmd = (gchar *) 0x881ca00 "'/usr/local/bin/mcs'" > prog = (gchar *) 0x881ca40 "/usr/local/bin/mcs" > full_prog = ( > gchar *) 0x8809c00 > "'/usr/local/bin/mcs' /target:library /debug- /optimize+ /warn:1 /out: > \"/var/tmp/tom-temp-aspnet/854b17b2/14374.dll\" /r:\"System.dll\" /r: > \"System.Xml.dll\" /r:\"System.Data.dll\" /r:\"System.Web.dll\" /r: > \"Syst"... > args = ( > gchar *) 0x8809800 "/target:library /debug- /optimize+ /warn:1 /out: > \"/var/tmp/tom-temp-aspnet/854b17b2/14374.dll\" /r:\"System.dll\" /r: > \"System.Xml.dll\" /r:\"System.Data.dll\" /r:\"System.Web.dll\" /r: > \"System.Web.Services.dll\" "... args_after_prog = ( > gchar *) 0x8809800 "/target:library /debug- /optimize+ /warn:1 /out: > \"/var/tmp/tom-temp-aspnet/854b17b2/14374.dll\" /r:\"System.dll\" /r: > \"System.Xml.dll\" /r:\"System.Data.dll\" /r:\"System.Web.dll\" /r: > \"System.Web.Services.dll\" "... dir = (gchar *) 0x881ca20 > "/usr/local/share/doc/xsp/test" > env = 1056 > stored_dir = 88 > stored_prog = 1164 > i = 24 > ret = 1 > stdin_handle = 0xbf6eb584 > stdout_handle = 0x18 > stderr_handle = 0x0 > pid = 23635 > tid = 0 > process_handle = 0x1c98 > thread_handle = 0x1c99 > process_handle_data = (struct _WapiHandle_process *) 0xbf6eb52c > #5 0x080b764c in ves_icall_System_Diagnostics_Process_Start_internal ( > appname=0x875f9d8, cmd=0x8764550, dirname=0x8371700, > stdin_handle=0x0, > stdout_handle=0x0, stderr_handle=0x0, process_info=0xbf6eb6ac) > at process.c:847 > ret = 24 > dir = (gunichar2 *) 0x0 > startinfo = {cb = 68, lpReserved = 0x0, lpDesktop = 0x0, > lpTitle = 0x0, dwX = 0, dwY = 0, dwXSize = 0, dwYSize = 0, > dwXCountChars = 0, dwYCountChars = 0, dwFillAttribute = 0, > dwFlags = STARTF_USESTDHANDLES, wShowWindow = 0, cbReserved2 = 0, > lpReserved2 = 0x0, hStdInput = 0x0, hStdOutput = 0x18, hStdError = > 0x1a} > procinfo = {hProcess = 0x1c98, hThread = 0x1c99, dwProcessId = > 23635, > dwThreadId = 0} > shell_path = (gunichar2 *) 0x8824a00 > env_vars = (gchar *) 0x0 > free_shell_path = 0 > newcmd = (gchar *) 0xbf6eb6ac "" > tmp = (gchar *) 0x8760f90 "\020j\200\b" > #6 0x28d038f6 in ?? () > No symbol table info available. > #7 0x0875f9d8 in ?? () > No symbol table info available. > #8 0x08764550 in ?? () > No symbol table info available. > #9 0x08371700 in ?? () > No symbol table info available. > #10 0x00000000 in ?? () > No symbol table info available. > #11 0x00000018 in ?? () > No symbol table info available. > #12 0x0000001a in ?? () > No symbol table info available. > #13 0xbf6eb6ac in ?? () > No symbol table info available. > #14 0xbf6ebb0c in ?? () > No symbol table info available. > #15 0x0841a6c8 in ?? () > No symbol table info available. > #16 0x08808dc0 in ?? () > No symbol table info available. > #17 0x0875f9d8 in ?? () > No symbol table info available. > #18 0x08761e10 in ?? () > No symbol table info available. > #19 0x08760f90 in ?? () > No symbol table info available. > #20 0xbf6eb640 in ?? () > No symbol table info available. > #21 0x28d038c4 in ?? () > No symbol table info available. > #22 0xbf6eb6d8 in ?? () > No symbol table info available. > #23 0x28d02eb5 in ?? () > No symbol table info available. > #24 0x0875f9d8 in ?? () > No symbol table info available. > #25 0x08764550 in ?? () > No symbol table info available. > #26 0x08371700 in ?? () > No symbol table info available. > #27 0x00000000 in ?? () > No symbol table info available. > #28 0x00000018 in ?? () > No symbol table info available. > #29 0x0000001a in ?? () > No symbol table info available. > #30 0xbf6eb6ac in ?? () > No symbol table info available. > #31 0xbf6eb684 in ?? () > No symbol table info available. > #32 0x08070f7f in x86_magic_trampoline (eax=141949400, ecx=141968720, > edx=137828096, esi=0, edi=24, ebx=26, code=0x8760f90 "\020j\200\b", > m=0xbf6eb684) at tramp-x86.c:123 > reg = 8 '\b' > disp = 141949400 > o = 0x18 > addr = 0x8761e10 > __PRETTY_FUNCTION__ = "x86_magic_trampoline" > Previous frame inner to this frame (corrupt stack?) > (gdb) > -- BSD# Project - Porting Mono to FreeBSD http://forge.novell.com/modules/xfmod/project/?bsd-sharp From owner-freebsd-threads@FreeBSD.ORG Wed Mar 2 14:56:24 2005 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 87EF416A4CE for ; Wed, 2 Mar 2005 14:56:24 +0000 (GMT) Received: from mail.emict.com (brig.emict.com [212.90.172.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9900143D39 for ; Wed, 2 Mar 2005 14:56:20 +0000 (GMT) (envelope-from andrit@ukr.net) Received: from BORJA (unknown [203.199.120.221]) by mail.emict.com (Postfix) with ESMTP id EBCD733390 for ; Wed, 2 Mar 2005 16:56:09 +0200 (EET) Message-ID: <000e01c51f37$fb3dc980$090210ac@BORJA> From: "Andriy Tkachuk" To: Date: Wed, 2 Mar 2005 20:26:02 +0530 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: patch for threads/76690 - critical - fork hang in child for -lc_r X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2005 14:56:24 -0000 Hi folks. I spent some time on the problem in $subj and found some solution that seems to be working but i'm not sure about it's architectural correctness because libc was changed little bit ;) here it is: # diff -u -r lib lib.patched diff -u -r lib/libc/stdlib/malloc.c lib.patched/libc/stdlib/malloc.c --- lib/libc/stdlib/malloc.c Sun Feb 27 22:46:16 2005 +++ lib.patched/libc/stdlib/malloc.c Wed Mar 2 19:55:24 2005 @@ -74,7 +74,7 @@ */ # include "libc_private.h" # include "spinlock.h" - static spinlock_t thread_lock =3D _SPINLOCK_INITIALIZER; + spinlock_t thread_lock =3D _SPINLOCK_INITIALIZER; spinlock_t *__malloc_lock =3D &thread_lock; # define _MALLOC_LOCK() if (__isthreaded) = _SPINLOCK(&thread_lock); # define _MALLOC_UNLOCK() if (__isthreaded) = _SPINUNLOCK(&thread_lock); diff -u -r lib/libc_r/uthread/uthread_fork.c = lib.patched/libc_r/uthread/uthread_fork.c --- lib/libc_r/uthread/uthread_fork.c Fri Dec 10 09:06:45 2004 +++ lib.patched/libc_r/uthread/uthread_fork.c Wed Mar 2 20:10:49 2005 @@ -61,6 +61,8 @@ _thread_kern_sig_defer(); _pthread_mutex_lock(&_atfork_mutex); + extern spinlock_t thread_lock; + _SPINLOCK(&thread_lock); /* Run down atfork prepare handlers. */ TAILQ_FOREACH_REVERSE(af, &_atfork_list, atfork_head, qe) { @@ -70,6 +72,8 @@ /* Fork a new process: */ if ((ret =3D __sys_fork()) !=3D 0) { + _SPINUNLOCK(&thread_lock); + /* Run down atfork parent handlers. */ TAILQ_FOREACH(af, &_atfork_list, qe) { if (af->parent !=3D NULL) @@ -78,6 +82,8 @@ _pthread_mutex_unlock(&_atfork_mutex); } else { + _SPINUNLOCK(&thread_lock); + /* Close the pthread kernel pipe: */ __sys_close(_thread_kern_pipe[0]); __sys_close(_thread_kern_pipe[1]); The main problem with it is that after fork child inherits from the parent inconsist heap. So the obvious solution is to synchronyze the fork and heap manipulations. I didn't find the easyest way how to get the lock variable from malloc lib as to open this variable deleting static spec. So what do you think guys about this patch? Thanks, Andriy Tkachuk. From owner-freebsd-threads@FreeBSD.ORG Wed Mar 2 15:48:10 2005 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5199616A4CF for ; Wed, 2 Mar 2005 15:48:10 +0000 (GMT) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id C153443D5C for ; Wed, 2 Mar 2005 15:48:09 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) j22Fm8Ec028193; Wed, 2 Mar 2005 10:48:08 -0500 (EST) Date: Wed, 2 Mar 2005 10:48:08 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Andriy Tkachuk In-Reply-To: <000e01c51f37$fb3dc980$090210ac@BORJA> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) cc: threads@freebsd.org Subject: Re: patch for threads/76690 - critical - fork hang in child for -lc_r X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Daniel Eischen List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2005 15:48:10 -0000 On Wed, 2 Mar 2005, Andriy Tkachuk wrote: > Hi folks. > > I spent some time on the problem in $subj and found some > solution that seems to be working but i'm not sure about it's > architectural correctness because libc was changed little bit ;) This is already fixed in libpthread in both -current and -stable. Your patch also pollutes the application namespace with a global symbol thread_lock -- there is already a symbol in malloc.c that is there just for this purpose (__malloc_lock). See how libpthread uses __malloc_lock and reinitializes the spinlocks in thr_kern.c (_kse_single_thread()). Is there a reason you are still using libc_r? -- DE From owner-freebsd-threads@FreeBSD.ORG Wed Mar 2 23:18:08 2005 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EEB5916A4CE for ; Wed, 2 Mar 2005 23:18:08 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id C0B6F43D2F; Wed, 2 Mar 2005 23:18:08 +0000 (GMT) (envelope-from davidxu@freebsd.org) Received: from [127.0.0.1] (davidxu@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j22NI7N8038789; Wed, 2 Mar 2005 23:18:08 GMT (envelope-from davidxu@freebsd.org) Message-ID: <422649AF.5090606@freebsd.org> Date: Thu, 03 Mar 2005 07:18:07 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.7.2) Gecko/20041004 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom McLaughlin References: <1109551418.782.30.camel@compass.straycat.dhs.org> <1109742079.777.15.camel@compass.straycat.dhs.org> In-Reply-To: <1109742079.777.15.camel@compass.straycat.dhs.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-threads@freebsd.org Subject: Re: Mono's XSP crashes on browser connection X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2005 23:18:09 -0000 This is caused by a memory corrupted problem, there was some reports , but current I don't know what caused it, it is worth to disable GC code in mono and see if the problem still occurs ? David Xu Tom McLaughlin wrote: >Alright, people can ignore this Mono crash and just look at the mcs one >in my other email. Both XSP and mcs are experiencing the same bug it >looks like and the mcs code is much simpler and easier to illustrate. >Sorry for the noise. I'm just trying to bang these out since I've been >sitting on them so long. Thanks. > >Tom > > From owner-freebsd-threads@FreeBSD.ORG Wed Mar 2 23:57:54 2005 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3795716A4CE; Wed, 2 Mar 2005 23:57:54 +0000 (GMT) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id C11D643D1D; Wed, 2 Mar 2005 23:57:53 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) j22NvquZ019553; Wed, 2 Mar 2005 18:57:52 -0500 (EST) Date: Wed, 2 Mar 2005 18:57:52 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: David Xu In-Reply-To: <422649AF.5090606@freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) cc: freebsd-threads@freebsd.org Subject: Re: Mono's XSP crashes on browser connection X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Daniel Eischen List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2005 23:57:54 -0000 On Thu, 3 Mar 2005, David Xu wrote: > This is caused by a memory corrupted problem, there was some reports , > but current I don't know what caused it, it is worth to disable GC code in > mono and see if the problem still occurs ? IIRC, there were problems with mono GC'ing mutexes while they were still being referenced... Or something like that. -- DE From owner-freebsd-threads@FreeBSD.ORG Thu Mar 3 06:36:00 2005 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2572716A4CE for ; Thu, 3 Mar 2005 06:36:00 +0000 (GMT) Received: from mail.emict.com (brig.emict.com [212.90.172.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7642843D41 for ; Thu, 3 Mar 2005 06:35:59 +0000 (GMT) (envelope-from andrit@ukr.net) Received: from BORJA (unknown [203.199.120.221]) by mail.emict.com (Postfix) with ESMTP id 2B04333535 for ; Thu, 3 Mar 2005 08:35:56 +0200 (EET) Message-ID: <000b01c51fbb$4189ea30$090210ac@BORJA> From: "Andriy Tkachuk" To: References: Date: Thu, 3 Mar 2005 12:05:52 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: Re: patch for threads/76690 - critical - fork hang in child for -lc_r X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 06:36:00 -0000 > Is there a reason you are still using libc_r? I don't use it at all, but there was critical bug i threads-pr - so i just decided to fix it since i have had some time ) If this library is needless, why is it still there and this pr in criticals? From owner-freebsd-threads@FreeBSD.ORG Thu Mar 3 06:46:40 2005 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E829E16A4CE for ; Thu, 3 Mar 2005 06:46:40 +0000 (GMT) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 78E5A43D41 for ; Thu, 3 Mar 2005 06:46:40 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) j236kdgP003098; Thu, 3 Mar 2005 01:46:39 -0500 (EST) Date: Thu, 3 Mar 2005 01:46:39 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Andriy Tkachuk In-Reply-To: <000b01c51fbb$4189ea30$090210ac@BORJA> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) cc: threads@freebsd.org Subject: Re: patch for threads/76690 - critical - fork hang in child for -lc_r X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Daniel Eischen List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 06:46:41 -0000 On Thu, 3 Mar 2005, Andriy Tkachuk wrote: > > > Is there a reason you are still using libc_r? > > I don't use it at all, but there was critical bug > i threads-pr - so i just decided to fix it since i > have had some time ) Oh, OK. > If this library is needless, why is it still there > and this pr in criticals? libc_r is marked for deprecation, but still used by some archs (sparc64 & alpha). Also, some folks want to use nvidia drivers/openGL and these aren't thread-safe with anything but libc_r. -- DE From owner-freebsd-threads@FreeBSD.ORG Thu Mar 3 06:48:35 2005 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 70A6D16A4CE for ; Thu, 3 Mar 2005 06:48:35 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4514943D53; Thu, 3 Mar 2005 06:48:35 +0000 (GMT) (envelope-from davidxu@freebsd.org) Received: from [127.0.0.1] (davidxu@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j236mXqA014391; Thu, 3 Mar 2005 06:48:34 GMT (envelope-from davidxu@freebsd.org) Message-ID: <4226B32F.9050309@freebsd.org> Date: Thu, 03 Mar 2005 14:48:15 +0800 From: David Xu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andriy Tkachuk References: <000b01c51fbb$4189ea30$090210ac@BORJA> In-Reply-To: <000b01c51fbb$4189ea30$090210ac@BORJA> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: threads@freebsd.org Subject: Re: patch for threads/76690 - critical - fork hang in child for -lc_r X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 06:48:35 -0000 Andriy Tkachuk wrote: >>Is there a reason you are still using libc_r? >> >> > >I don't use it at all, but there was critical bug >i threads-pr - so i just decided to fix it since i >have had some time ) > >If this library is needless, why is it still there >and this pr in criticals? > > > Then commit it if the patch is right, do you have fully tested it ? David Xu From owner-freebsd-threads@FreeBSD.ORG Thu Mar 3 06:59:15 2005 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3D07616A4D0 for ; Thu, 3 Mar 2005 06:59:15 +0000 (GMT) Received: from mail.emict.com (brig.emict.com [212.90.172.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 92AD843D31 for ; Thu, 3 Mar 2005 06:59:14 +0000 (GMT) (envelope-from andrit@ukr.net) Received: from BORJA (unknown [203.199.120.221]) by mail.emict.com (Postfix) with ESMTP id 0AD8E33617 for ; Thu, 3 Mar 2005 08:59:11 +0200 (EET) Message-ID: <001a01c51fbe$81472d60$090210ac@BORJA> From: "Andriy Tkachuk" To: References: Date: Thu, 3 Mar 2005 12:29:07 +0530 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0017_01C51FEC.980DEEC0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: Re: patch for threads/76690 - critical - fork hang in child for -lc_r X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 06:59:15 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0017_01C51FEC.980DEEC0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit > This is already fixed in libpthread in both -current and -stable. > Your patch also pollutes the application namespace with a global > symbol thread_lock -- there is already a symbol in malloc.c that > is there just for this purpose (__malloc_lock). yea, i see - you right. i just didn't noticed that this one is already without static. thanks. Ok, now the libc don't changed, and updated patch see in attachment. Thanks, Andriy. ------=_NextPart_000_0017_01C51FEC.980DEEC0 Content-Type: application/octet-stream; name="libc_r-76690pr.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="libc_r-76690pr.patch" diff -r -u lib/libc_r/uthread/uthread_fork.c = lib.patched/libc_r/uthread/uthread_fork.c=0A= --- lib/libc_r/uthread/uthread_fork.c Fri Dec 10 09:06:45 2004=0A= +++ lib.patched/libc_r/uthread/uthread_fork.c Thu Mar 3 12:17:01 2005=0A= @@ -62,6 +62,9 @@=0A= =0A= _pthread_mutex_lock(&_atfork_mutex);=0A= =0A= + extern spinlock_t *__malloc_lock;=0A= + _SPINLOCK(__malloc_lock);=0A= +=0A= /* Run down atfork prepare handlers. */=0A= TAILQ_FOREACH_REVERSE(af, &_atfork_list, atfork_head, qe) {=0A= if (af->prepare !=3D NULL)=0A= @@ -70,6 +73,8 @@=0A= =0A= /* Fork a new process: */=0A= if ((ret =3D __sys_fork()) !=3D 0) {=0A= + _SPINUNLOCK(__malloc_lock);=0A= +=0A= /* Run down atfork parent handlers. */=0A= TAILQ_FOREACH(af, &_atfork_list, qe) {=0A= if (af->parent !=3D NULL)=0A= @@ -78,6 +83,8 @@=0A= _pthread_mutex_unlock(&_atfork_mutex);=0A= =0A= } else {=0A= + _SPINUNLOCK(__malloc_lock);=0A= +=0A= /* Close the pthread kernel pipe: */=0A= __sys_close(_thread_kern_pipe[0]);=0A= __sys_close(_thread_kern_pipe[1]);=0A= ------=_NextPart_000_0017_01C51FEC.980DEEC0-- From owner-freebsd-threads@FreeBSD.ORG Thu Mar 3 07:04:47 2005 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DB36916A4CE; Thu, 3 Mar 2005 07:04:47 +0000 (GMT) Received: from straycat.dhs.org (h0050da134090.ne.client2.attbi.com [24.60.174.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 457F643D2F; Thu, 3 Mar 2005 07:04:47 +0000 (GMT) (envelope-from tmclaugh@sdf.lonestar.org) Received: from compass.straycat.dhs.org (compass.straycat.dhs.org [192.168.1.48]) by straycat.dhs.org (8.13.0/8.13.0) with ESMTP id j2375ZGK015407; Thu, 3 Mar 2005 02:05:44 -0500 (EST) From: Tom McLaughlin To: David Xu In-Reply-To: <422649AF.5090606@freebsd.org> References: <1109551418.782.30.camel@compass.straycat.dhs.org> <1109742079.777.15.camel@compass.straycat.dhs.org> <422649AF.5090606@freebsd.org> Content-Type: text/plain Date: Thu, 03 Mar 2005 02:05:04 -0500 Message-Id: <1109833505.777.80.camel@compass.straycat.dhs.org> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit cc: freebsd-threads@freebsd.org Subject: Re: Mono's XSP crashes on browser connection X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 07:04:48 -0000 On Thu, 2005-03-03 at 07:18 +0800, David Xu wrote: > This is caused by a memory corrupted problem, there was some reports , > but current I don't know what caused it, it is worth to disable GC code in > mono and see if the problem still occurs ? > > David Xu > > Tom McLaughlin wrote: > > >Alright, people can ignore this Mono crash and just look at the mcs one > >in my other email. Both XSP and mcs are experiencing the same bug it > >looks like and the mcs code is much simpler and easier to illustrate. > >Sorry for the noise. I'm just trying to bang these out since I've been > >sitting on them so long. Thanks. > > > >Tom > > > > > Disabling garbage collection in Mono prevents the crash but after executing the external process the C# program does not continue on, it just sits there. So that isn't a viable option for regular use. Worse, mono ships with Boehm 6.2. I linked against 6.4 from ports (where threading support is not even enabled by default) and Mono is now failing to compile. Mono's mcs compiler hangs at the same spot on -STABLE and -CURRENT. Once Mono imports a later Boehm, FreeBSD is in for some serious problems. Tom -- BSD# Project - Porting Mono to FreeBSD http://forge.novell.com/modules/xfmod/project/?bsd-sharp From owner-freebsd-threads@FreeBSD.ORG Thu Mar 3 07:14:14 2005 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 91A3F16A4CE; Thu, 3 Mar 2005 07:14:14 +0000 (GMT) Received: from lakermmtao09.cox.net (lakermmtao09.cox.net [68.230.240.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id D6D1643D48; Thu, 3 Mar 2005 07:14:13 +0000 (GMT) (envelope-from mezz7@cox.net) Received: from mezz.mezzweb.com ([68.103.32.140]) by lakermmtao09.cox.net (InterMail vM.6.01.04.00 201-2131-118-20041027) with ESMTP id <20050303071411.WOKQ28448.lakermmtao09.cox.net@mezz.mezzweb.com>; Thu, 3 Mar 2005 02:14:11 -0500 To: "Tom McLaughlin" References: <1109551418.782.30.camel@compass.straycat.dhs.org> <1109742079.777.15.camel@compass.straycat.dhs.org> <422649AF.5090606@freebsd.org> <1109833505.777.80.camel@compass.straycat.dhs.org> Message-ID: Date: Thu, 03 Mar 2005 01:15:24 -0600 From: "Jeremy Messenger" Content-Type: text/plain; format=flowed; delsp=yes; charset=us-ascii MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <1109833505.777.80.camel@compass.straycat.dhs.org> User-Agent: Opera M2/7.54 (Linux, build 955) cc: David Xu cc: freebsd-threads@freebsd.org Subject: Re: Mono's XSP crashes on browser connection X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 07:14:14 -0000 On Thu, 03 Mar 2005 02:05:04 -0500, Tom McLaughlin wrote: > On Thu, 2005-03-03 at 07:18 +0800, David Xu wrote: >> This is caused by a memory corrupted problem, there was some reports , >> but current I don't know what caused it, it is worth to disable GC code >> in >> mono and see if the problem still occurs ? >> >> David Xu >> >> Tom McLaughlin wrote: >> >> >Alright, people can ignore this Mono crash and just look at the mcs one >> >in my other email. Both XSP and mcs are experiencing the same bug it >> >looks like and the mcs code is much simpler and easier to illustrate. >> >Sorry for the noise. I'm just trying to bang these out since I've been >> >sitting on them so long. Thanks. >> > >> >Tom >> > >> > >> > > Disabling garbage collection in Mono prevents the crash but after > executing the external process the C# program does not continue on, it > just sits there. So that isn't a viable option for regular use. > > Worse, mono ships with Boehm 6.2. I linked against 6.4 from ports > (where threading support is not even enabled by default) and Mono is now > failing to compile. Mono's mcs compiler hangs at the same spot on > -STABLE and -CURRENT. Once Mono imports a later Boehm, FreeBSD is in > for some serious problems. I bet if you grab mono/files/patch-libgc_include_private_gcconfig.h and merge in boehm port should solve the hang problem. It's untest, btw. In case if you are wondering why it need this patch, you can check this link. http://forge.novell.com/modules/xfmod/maillist/archbrowse.php/bsd-sharp-list/2005-February/000150.html?id=1498&prjname=bsd-sharp&mlname=list Cheers, Mezz > Tom -- mezz7@cox.net - mezz@FreeBSD.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gnome@FreeBSD.org From owner-freebsd-threads@FreeBSD.ORG Thu Mar 3 07:17:03 2005 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D645C16A4CE for ; Thu, 3 Mar 2005 07:17:03 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id B97B343D2F; Thu, 3 Mar 2005 07:17:03 +0000 (GMT) (envelope-from davidxu@freebsd.org) Received: from [127.0.0.1] (davidxu@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j237H16J031217; Thu, 3 Mar 2005 07:17:02 GMT (envelope-from davidxu@freebsd.org) Message-ID: <4226B9DC.7040405@freebsd.org> Date: Thu, 03 Mar 2005 15:16:44 +0800 From: David Xu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom McLaughlin References: <1109551418.782.30.camel@compass.straycat.dhs.org> <1109742079.777.15.camel@compass.straycat.dhs.org> <422649AF.5090606@freebsd.org> <1109833505.777.80.camel@compass.straycat.dhs.org> In-Reply-To: <1109833505.777.80.camel@compass.straycat.dhs.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-threads@freebsd.org Subject: Re: Mono's XSP crashes on browser connection X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 07:17:03 -0000 Tom McLaughlin wrote: >Disabling garbage collection in Mono prevents the crash but after >executing the external process the C# program does not continue on, it >just sits there. So that isn't a viable option for regular use. > > > Can you give me example code (executing external program) ? I don't know C# but want to try. >Worse, mono ships with Boehm 6.2. I linked against 6.4 from ports >(where threading support is not even enabled by default) and Mono is now >failing to compile. Mono's mcs compiler hangs at the same spot on >-STABLE and -CURRENT. Once Mono imports a later Boehm, FreeBSD is in >for some serious problems. > >Tom > > From owner-freebsd-threads@FreeBSD.ORG Thu Mar 3 07:30:19 2005 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8073C16A4CE for ; Thu, 3 Mar 2005 07:30:19 +0000 (GMT) Received: from mail.emict.com (brig.emict.com [212.90.172.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8194A43D1F for ; Thu, 3 Mar 2005 07:30:18 +0000 (GMT) (envelope-from andrit@ukr.net) Received: from BORJA (unknown [203.199.120.221]) by mail.emict.com (Postfix) with ESMTP id 73D9333649 for ; Thu, 3 Mar 2005 09:30:15 +0200 (EET) Message-ID: <005201c51fc2$d8676b60$090210ac@BORJA> From: "Andriy Tkachuk" To: References: <000b01c51fbb$4189ea30$090210ac@BORJA> Date: Thu, 3 Mar 2005 13:00:12 +0530 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_004F_01C51FF0.EF8D15A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: Re: patch for threads/76690 - critical - fork hang in child for-lc_r X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 07:30:19 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_004F_01C51FF0.EF8D15A0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit But if one wants to use pure user threads on his UP system, what he will chose if not libc_r ? And i have some test program with shows the better results for libc_r than for libpthreads. Take a look. The program is the 500 threads, each of them allocate memory in loop and then free it in another loop. Program outputs the time consumed for this two loops. See the results. > ./a.out m 1000 10 # 1000 iterations, malloc by 10 bytes memory chanks thread 0 created thread 1 created thread 2 created thread 3 created ... thread 499 created 0.000870 0.000544 0.000695 0.000594 0.000913 ... (after some time, say 10-20 seconds, there is stable picture: ) 0.001056 0.000756 0.000485 0.000476 0.000528 0.000479 0.000550 0.000481 0.000561 0.000541 0.000483 0.000558 0.000482 0.000561 0.000532 0.000479 0.000551 0.000484 0.000923 0.001180 0.000981 0.000492 0.000996 0.000536 0.000975 0.000534 this is for libc_r. Let's see what about lpthreads. > c++ -lpthread test2.cc > ./a.out m 1000 10 thread 0 created thread 1 created ... thread 498 created thread 499 created 0.001704 0.001707 0.001671 0.001683 0.001691 0.001664 0.001661 0.001683 0.001709 ... 0.001643 0.002018 0.001668 0.001672 0.001744 0.001689 0.001672 0.001682 0.001643 0.001687 0.001670 0.001692 0.001677 0.001732 0.001650 0.001685 0.001678 0.001685 1.303800 5.266314 5.268821 5.268158 5.268539 5.268644 5.268515 5.268963 5.269147 5.268968 5.268928 ... 5.341573 5.341051 5.341417 5.341327 5.341084 5.340510 5.340974 5.340914 5.341118 ... So what? The test2.cc is attached. (of course all was done on current: > uname -a FreeBSD fbsd 6.0-CURRENT FreeBSD 6.0-CURRENT #0: Tue Mar 1 16:03:09 IST 2005 ant@fbsd:/usr/obj/usr/src/sys/FBSD i386 ) > > Is there a reason you are still using libc_r? > > I don't use it at all, but there was critical bug > i threads-pr - so i just decided to fix it since i > have had some time ) > > If this library is needless, why is it still there > and this pr in criticals? ------=_NextPart_000_004F_01C51FF0.EF8D15A0 Content-Type: application/octet-stream; name="test2.cc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="test2.cc" #include =0A= #include =0A= #include =0A= #include =0A= #include =0A= =0A= using std::string;=0A= =0A= #define COUNT_THREADS 500=0A= =0A= pthread_t thread[COUNT_THREADS];=0A= =0A= char mode;=0A= int iters;=0A= int chanksz;=0A= =0A= void f()=0A= {=0A= struct timeval t1,t2;=0A= void* p[iters];=0A= string s;=0A= =0A= sleep(2);=0A= =0A= while (1)=0A= {=0A= =0A= gettimeofday(&t1, NULL);=0A= =0A= if (mode =3D=3D 's') {=0A= s =3D "";=0A= for (int i=3D0; i Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BD7A916A4CF; Thu, 3 Mar 2005 07:35:39 +0000 (GMT) Received: from straycat.dhs.org (h0050da134090.ne.client2.attbi.com [24.60.174.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2679743D5E; Thu, 3 Mar 2005 07:35:39 +0000 (GMT) (envelope-from tmclaugh@sdf.lonestar.org) Received: from compass.straycat.dhs.org (compass.straycat.dhs.org [192.168.1.48]) by straycat.dhs.org (8.13.0/8.13.0) with ESMTP id j237aa3d015871; Thu, 3 Mar 2005 02:36:37 -0500 (EST) From: Tom McLaughlin To: David Xu In-Reply-To: <4226B9DC.7040405@freebsd.org> References: <1109551418.782.30.camel@compass.straycat.dhs.org> <1109742079.777.15.camel@compass.straycat.dhs.org> <422649AF.5090606@freebsd.org> <1109833505.777.80.camel@compass.straycat.dhs.org> <4226B9DC.7040405@freebsd.org> Content-Type: text/plain Date: Thu, 03 Mar 2005 02:36:05 -0500 Message-Id: <1109835366.777.95.camel@compass.straycat.dhs.org> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit cc: freebsd-threads@freebsd.org Subject: Re: Mono's XSP crashes on browser connection X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 07:35:39 -0000 On Thu, 2005-03-03 at 15:16 +0800, David Xu wrote: > Tom McLaughlin wrote: > > >Disabling garbage collection in Mono prevents the crash but after > >executing the external process the C# program does not continue on, it > >just sits there. So that isn't a viable option for regular use. > > > > > > > Can you give me example code (executing external program) ? I don't know C# > but want to try. > Here you go. The second one yields a slightly different error but it more closely matches the code in the program where I first tracked down this bug. when using gdb with these examples do one of the following: $ gdb /usr/local/bin/mono mono.core -or- $ gdb /usr/local/bin/mono (gdb) run /path/to/foo.exe simple example: --------------- using System.Diagnostics; class T { static void Main() { Process.Start ("ls"); } } --------------- Second example: --------------- using System.Diagnostics; class T { static void Main() { ProcessStartInfo pi = new ProcessStartInfo (); pi.FileName = "ls"; pi.RedirectStandardOutput = true; pi.UseShellExecute = false; pi.Arguments = "-al"; Process.Start (pi); } } --------------- Thanks for taking a look at this. This bug is making creating ports a pain. The mcs compiler uses this when called with the /pkg flag. It's also keeping XSP and MonoDevelop out of the ports tree. Those are two of the programs I see most requested. Tom > >Worse, mono ships with Boehm 6.2. I linked against 6.4 from ports > >(where threading support is not even enabled by default) and Mono is now > >failing to compile. Mono's mcs compiler hangs at the same spot on > >-STABLE and -CURRENT. Once Mono imports a later Boehm, FreeBSD is in > >for some serious problems. > > > >Tom > > > > > -- BSD# Project - Porting Mono to FreeBSD http://forge.novell.com/modules/xfmod/project/?bsd-sharp From owner-freebsd-threads@FreeBSD.ORG Thu Mar 3 08:08:09 2005 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E4AF716A4CE for ; Thu, 3 Mar 2005 08:08:08 +0000 (GMT) Received: from mail.emict.com (brig.emict.com [212.90.172.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 647BC43D1D for ; Thu, 3 Mar 2005 08:08:07 +0000 (GMT) (envelope-from andrit@ukr.net) Received: from BORJA (unknown [203.199.120.221]) by mail.emict.com (Postfix) with ESMTP id C62EA3372A for ; Thu, 3 Mar 2005 10:07:53 +0200 (EET) Message-ID: <00a101c51fc8$1a9a7ea0$090210ac@BORJA> From: "Andriy Tkachuk" To: References: <000b01c51fbb$4189ea30$090210ac@BORJA> <005201c51fc2$d8676b60$090210ac@BORJA> <20050303075017.GA1063@crodrigues.org> Date: Thu, 3 Mar 2005 13:37:49 +0530 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_009E_01C51FF6.3102A540" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: Re: patch for threads/76690 - critical - fork hang in child for-lc_r X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 08:08:09 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_009E_01C51FF6.3102A540 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit numbers vary incredibly as compared with prev. libs. see attach. ----- Original Message ----- From: "Craig Rodrigues" To: "Andriy Tkachuk" Sent: Thursday, March 03, 2005 13:20 Subject: Re: patch for threads/76690 - critical - fork hang in child for-lc_r > On Thu, Mar 03, 2005 at 01:00:12PM +0530, Andriy Tkachuk wrote: > > this is for libc_r. Let's see what about lpthreads. > > > > > c++ -lpthread test2.cc > > Could you post the numbers you get if you use -lthr > > -- > Craig Rodrigues > rodrigc@crodrigues.org > > ------=_NextPart_000_009E_01C51FF6.3102A540-- From owner-freebsd-threads@FreeBSD.ORG Thu Mar 3 08:10:21 2005 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8025816A4CE for ; Thu, 3 Mar 2005 08:10:21 +0000 (GMT) Received: from mail.emict.com (brig.emict.com [212.90.172.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0D05543D41 for ; Thu, 3 Mar 2005 08:10:21 +0000 (GMT) (envelope-from andrit@ukr.net) Received: from BORJA (unknown [203.199.120.221]) by mail.emict.com (Postfix) with ESMTP id BBA1A33736 for ; Thu, 3 Mar 2005 10:10:16 +0200 (EET) Message-ID: <00ab01c51fc8$6fc81130$090210ac@BORJA> From: "Andriy Tkachuk" To: Date: Thu, 3 Mar 2005 13:40:13 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: Re: patch for threads/76690 - critical - fork hang in child for-lc_r X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 08:10:21 -0000 there are bursts of latency like: 0.000639 0.000625 0.000647 0.000625 163.864754 0.000654 0.000639 0.000631 136.146951 164.162206 0.000636 0.000632 0.000635 0.000625 > numbers vary incredibly as compared with prev. libs. > see attach. > > ----- Original Message ----- > From: "Craig Rodrigues" > To: "Andriy Tkachuk" > Sent: Thursday, March 03, 2005 13:20 > Subject: Re: patch for threads/76690 - critical - fork hang in child > for-lc_r > > > > On Thu, Mar 03, 2005 at 01:00:12PM +0530, Andriy Tkachuk wrote: > > > this is for libc_r. Let's see what about lpthreads. > > > > > > > c++ -lpthread test2.cc > > > > Could you post the numbers you get if you use -lthr > > > > -- > > Craig Rodrigues > > rodrigc@crodrigues.org > > > > > From owner-freebsd-threads@FreeBSD.ORG Thu Mar 3 08:15:51 2005 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5A8EC16A4CE for ; Thu, 3 Mar 2005 08:15:51 +0000 (GMT) Received: from mail.emict.com (brig.emict.com [212.90.172.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 056D743D1D for ; Thu, 3 Mar 2005 08:15:49 +0000 (GMT) (envelope-from andrit@ukr.net) Received: from BORJA (unknown [203.199.120.221]) by mail.emict.com (Postfix) with ESMTP id 7266533744 for ; Thu, 3 Mar 2005 10:15:46 +0200 (EET) Message-ID: <00e201c51fc9$343c1ed0$090210ac@BORJA> From: "Andriy Tkachuk" To: References: <000b01c51fbb$4189ea30$090210ac@BORJA> <005201c51fc2$d8676b60$090210ac@BORJA><20050303075017.GA1063@crodrigues.org> <00a101c51fc8$1a9a7ea0$090210ac@BORJA> Date: Thu, 3 Mar 2005 13:45:42 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: Re: patch for threads/76690 - critical - fork hang in child for-lc_r X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 08:15:51 -0000 sorry, attach was catted, probably it was too big (12K) > numbers vary incredibly as compared with prev. libs. > see attach. From owner-freebsd-threads@FreeBSD.ORG Thu Mar 3 08:16:10 2005 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0340716A4CF for ; Thu, 3 Mar 2005 08:16:10 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id E147843D1D; Thu, 3 Mar 2005 08:16:09 +0000 (GMT) (envelope-from davidxu@freebsd.org) Received: from [127.0.0.1] (davidxu@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j238G7Bb039509; Thu, 3 Mar 2005 08:16:08 GMT (envelope-from davidxu@freebsd.org) Message-ID: <4226C7B6.4060901@freebsd.org> Date: Thu, 03 Mar 2005 16:15:50 +0800 From: David Xu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andriy Tkachuk References: <000b01c51fbb$4189ea30$090210ac@BORJA> <005201c51fc2$d8676b60$090210ac@BORJA> In-Reply-To: <005201c51fc2$d8676b60$090210ac@BORJA> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: threads@freebsd.org Subject: Re: patch for threads/76690 - critical - fork hang in child for-lc_r X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 08:16:10 -0000 Hmm, libc_r and libpthread handle spinlock differently which malloc uses to protect itself, some real world benchmarks are better than this. David Xu Andriy Tkachuk wrote: >But if one wants to use pure user threads >on his UP system, what he will chose if not libc_r ? > >And i have some test program with shows >the better results for libc_r than for libpthreads. >Take a look. > >The program is the 500 threads, each of them allocate >memory in loop and then free it in another loop. >Program outputs the time consumed for this two loops. > >See the results. > > From owner-freebsd-threads@FreeBSD.ORG Thu Mar 3 08:44:46 2005 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2D42716A4CE for ; Thu, 3 Mar 2005 08:44:46 +0000 (GMT) Received: from mail.emict.com (brig.emict.com [212.90.172.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8E14D43D41 for ; Thu, 3 Mar 2005 08:44:43 +0000 (GMT) (envelope-from andrit@ukr.net) Received: from BORJA (unknown [203.199.120.221]) by mail.emict.com (Postfix) with ESMTP id 11B24337C3 for ; Thu, 3 Mar 2005 10:44:39 +0200 (EET) Message-ID: <010b01c51fcd$3d0dabb0$090210ac@BORJA> From: "Andriy Tkachuk" To: References: <000b01c51fbb$4189ea30$090210ac@BORJA> <005201c51fc2$d8676b60$090210ac@BORJA> <4226C7B6.4060901@freebsd.org> Date: Thu, 3 Mar 2005 14:14:30 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: Re: patch for threads/76690 - critical - fork hang in child for-lc_r X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 08:44:46 -0000 actually, this test prog was written after there were problems with multithreaded domestic application server, that was tested under load. this one is using intensively hash manipulations. it is develped for redhat 7.3 and tested there. it was interesting for me, how it will behaves on fbsd in linux emulation - it was fine (note: there is linix pthreads). then we wrote this test prog to investigate the threads with heap manipulations sumultaneousely. It was interesting for me to investigate the same in freebsd. that's how it was. :) > Hmm, libc_r and libpthread handle spinlock differently which malloc > uses to protect itself, some real world benchmarks are better than this. > > David Xu From owner-freebsd-threads@FreeBSD.ORG Thu Mar 3 09:26:29 2005 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C5EAA16A4CE; Thu, 3 Mar 2005 09:26:29 +0000 (GMT) Received: from mail.emict.com (brig.emict.com [212.90.172.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id D663443D46; Thu, 3 Mar 2005 09:26:28 +0000 (GMT) (envelope-from andrit@ukr.net) Received: from BORJA (unknown [203.199.120.221]) by mail.emict.com (Postfix) with ESMTP id 198293394D; Thu, 3 Mar 2005 11:26:25 +0200 (EET) Message-ID: <012901c51fd3$131e23b0$090210ac@BORJA> From: "Andriy Tkachuk" To: "David Xu" Date: Thu, 3 Mar 2005 14:56:21 +0530 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0126_01C52001.298C64D0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1165 cc: threads@freebsd.org Subject: Re: patch for threads/76690 - critical - fork hang in child for-lc_r X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 09:26:29 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0126_01C52001.298C64D0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit > > > Hmm, libc_r and libpthread handle spinlock differently which malloc > > > uses to protect itself, some real world benchmarks are better than > this. yes , you right, David. one have to check __isthreaded before firing _SPINLOCK. there will be nothing wrong, because static spinlock_t thread_lock = _SPINLOCK_INITIALIZER; initialyzed regardless __isthreaded in malloc.c but for optimization probably it is worth to add this check. Take a look on updated patch. btw: i don't see the unlock in child in libpthread. there must be two unlocks - in child & in parent, doesn't it? : # grep __malloc_lock -r libpthread libpthread/thread/thr_fork.c: _spinlock(__malloc_lock); libpthread/thread/thr_fork.c: if ((_kse_isthreaded() != 0) && (__malloc_lock != NULL)) { libpthread/thread/thr_fork.c: _spinunlock(__malloc_lock); # ------=_NextPart_000_0126_01C52001.298C64D0 Content-Type: application/octet-stream; name="libc_r-76690pr.patch2" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="libc_r-76690pr.patch2" diff -r -u lib/libc_r/uthread/uthread_fork.c = lib.patched/libc_r/uthread/uthread_fork.c=0A= --- lib/libc_r/uthread/uthread_fork.c Fri Dec 10 09:06:45 2004=0A= +++ lib.patched/libc_r/uthread/uthread_fork.c Thu Mar 3 14:50:06 2005=0A= @@ -68,8 +68,15 @@=0A= af->prepare();=0A= }=0A= =0A= + extern spinlock_t *__malloc_lock;=0A= + if (__isthreaded && __malloc_lock !=3D NULL)=0A= + _SPINLOCK(__malloc_lock);=0A= +=0A= /* Fork a new process: */=0A= if ((ret =3D __sys_fork()) !=3D 0) {=0A= + if (__isthreaded && __malloc_lock !=3D NULL)=0A= + _SPINUNLOCK(__malloc_lock);=0A= +=0A= /* Run down atfork parent handlers. */=0A= TAILQ_FOREACH(af, &_atfork_list, qe) {=0A= if (af->parent !=3D NULL)=0A= @@ -78,6 +85,9 @@=0A= _pthread_mutex_unlock(&_atfork_mutex);=0A= =0A= } else {=0A= + if (__isthreaded && __malloc_lock !=3D NULL)=0A= + _SPINUNLOCK(__malloc_lock);=0A= +=0A= /* Close the pthread kernel pipe: */=0A= __sys_close(_thread_kern_pipe[0]);=0A= __sys_close(_thread_kern_pipe[1]);=0A= ------=_NextPart_000_0126_01C52001.298C64D0-- From owner-freebsd-threads@FreeBSD.ORG Thu Mar 3 10:47:00 2005 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 24A8D16A4CE for ; Thu, 3 Mar 2005 10:47:00 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 049DB43D2F; Thu, 3 Mar 2005 10:47:00 +0000 (GMT) (envelope-from davidxu@freebsd.org) Received: from [127.0.0.1] (davidxu@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j23AkuU4057535; Thu, 3 Mar 2005 10:46:59 GMT (envelope-from davidxu@freebsd.org) Message-ID: <4226EB21.9090401@freebsd.org> Date: Thu, 03 Mar 2005 18:46:57 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.7.2) Gecko/20041004 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andriy Tkachuk References: <012901c51fd3$131e23b0$090210ac@BORJA> In-Reply-To: <012901c51fd3$131e23b0$090210ac@BORJA> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: threads@freebsd.org Subject: Re: patch for threads/76690 - critical - fork hang in child for-lc_r X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 10:47:00 -0000 Andriy Tkachuk wrote: >>>>Hmm, libc_r and libpthread handle spinlock differently which malloc >>>>uses to protect itself, some real world benchmarks are better than >>>> >>>> >>this. >> >> > >yes , you right, David. one have to check __isthreaded before >firing _SPINLOCK. there will be nothing wrong, because > >static spinlock_t thread_lock = _SPINLOCK_INITIALIZER; > >initialyzed regardless __isthreaded in malloc.c but >for optimization probably it is worth to add this check. >Take a look on updated patch. > >btw: i don't see the unlock in child in libpthread. there must be two >unlocks >- in child & in parent, doesn't it? : > ># grep __malloc_lock -r libpthread >libpthread/thread/thr_fork.c: _spinlock(__malloc_lock); >libpthread/thread/thr_fork.c: if ((_kse_isthreaded() != 0) && >(__malloc_lock != NULL)) { >libpthread/thread/thr_fork.c: _spinunlock(__malloc_lock); ># > > in libpthread, all spinlocks hold by current thread are reinitialized by _thr_spinlock_init() in thr_spinlock.c, so in child process, it is not needed to unlocked it again. After a fork(), in child process, current thread is a fresh thread which should never hold any lock. David Xu From owner-freebsd-threads@FreeBSD.ORG Thu Mar 3 14:32:42 2005 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2769916A4CE for ; Thu, 3 Mar 2005 14:32:42 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id CA36443D1F; Thu, 3 Mar 2005 14:32:41 +0000 (GMT) (envelope-from davidxu@freebsd.org) Received: from [127.0.0.1] (davidxu@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j23EWd6F091590; Thu, 3 Mar 2005 14:32:40 GMT (envelope-from davidxu@freebsd.org) Message-ID: <42272009.507@freebsd.org> Date: Thu, 03 Mar 2005 22:32:41 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.7.2) Gecko/20041004 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom McLaughlin References: <1109551418.782.30.camel@compass.straycat.dhs.org> <1109742079.777.15.camel@compass.straycat.dhs.org> <422649AF.5090606@freebsd.org> <1109833505.777.80.camel@compass.straycat.dhs.org> <4226B9DC.7040405@freebsd.org> <1109835366.777.95.camel@compass.straycat.dhs.org> In-Reply-To: <1109835366.777.95.camel@compass.straycat.dhs.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-threads@freebsd.org Subject: Re: Mono's XSP crashes on browser connection X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 14:32:42 -0000 Tom McLaughlin wrote: >On Thu, 2005-03-03 at 15:16 +0800, David Xu wrote: > > >>Tom McLaughlin wrote: >> >> >> >>>Disabling garbage collection in Mono prevents the crash but after >>>executing the external process the C# program does not continue on, it >>>just sits there. So that isn't a viable option for regular use. >>> >>> >>> >>> >>> >>Can you give me example code (executing external program) ? I don't know C# >>but want to try. >> >> >> > >Here you go. The second one yields a slightly different error but it >more closely matches the code in the program where I first tracked down >this bug. > >when using gdb with these examples do one of the following: > >$ gdb /usr/local/bin/mono mono.core >-or- >$ gdb /usr/local/bin/mono >(gdb) run /path/to/foo.exe > > >simple example: >--------------- >using System.Diagnostics; > >class T >{ > static void Main() > { > Process.Start ("ls"); > } >} >--------------- > > > >Second example: >--------------- >using System.Diagnostics; > >class T >{ > static void Main() > { > ProcessStartInfo pi = new ProcessStartInfo (); > pi.FileName = "ls"; > pi.RedirectStandardOutput = true; > pi.UseShellExecute = false; > pi.Arguments = "-al"; > Process.Start (pi); > } >} >--------------- > > >Thanks for taking a look at this. This bug is making creating ports a >pain. The mcs compiler uses this when called with the /pkg flag. It's >also keeping XSP and MonoDevelop out of the ports tree. Those are two >of the programs I see most requested. > > > I have digged deeply in mono source code, and found that it is trying to share pthread_mutex_t via shared memory segments, this is not supported by current FreeBSD thread library, also the author of mono is trying to avoid to share mutex between processes according to whether _POSIX_THREAD_PROCESS_SHARED is defined or not in source code, but he failed to respect this macro at many places, so the macro is rather bogus. These sampe programs blocked after excuting external program, because WIN32 process handle is not correctly waited in file mono-1.0.6/mono/io-layer/handles.c, function: _wapi_handle_timedwait_signal_handle(), if you replace mono_cond_timedwait() call with loop : while (!_wapi_handle_get_shared_segment (segment)->handles[idx].signalled) { sleep(1); printf("loop \n"); } you will find that the process will exit soon, but it will complain another problem, here is the log on my console: davidxu@tiger:/home/davidxu/tests> mono ./testls.exe shell_path=0x81197c0 wait on 1:3233, mutex=0x805a380 a.out d.core jointest.c nullcond.c sigwait.c thr_cancel.c aqueue.c d.cpp ktrace.out nullvector single thrcreate aqueue_c_r deque.cpp list2 nullvector.cpp single.c thrcreate.c aqueue_kse ex14 list2.cpp op_pp spinlock threadstack aqueue_linuxthreads ex14.c list3 op_pp.cpp spinlock.c threadstack.c aqueue_pthread examples list3.cpp pp stack.cpp threadstack.core aqueue_thr f2c malloc pp.c stack.h two aqueue_thread f2c.c malloc.c pp_thr stlstack two.c build.sh hello maxsize pp_thread stlstack.cpp typeinfo cancelstress hello.core maxsize.cpp resume_suspend strcspn_test typeinfo.cxx cancelstress.c hello.cpp mono.core resume_suspend.c strcspn_test.c userdefined_set cancelstress2 hello.o mutex_cancel rlimit string userdefined_set.cpp cancelstress2.c iconv mutex_cancel.c rlimit.c string.cxx userdefined_set.o concurr iconv.c mutex_sig sem strpbrk_test valgrind.core concurr.c iostream mutex_sig.c sem.c strpbrk_test.c vector cond iostream.cxx mutex_sig2 set t vector.cxx cond.c join.c mutex_sig2.c set.cpp test3.cpp vector2 condwait joinstress mutex_test sigfork testls.cs vector2.cpp condwait.c joinstress.c mutex_test.c sigfork.c testls.exe vector3 d jointest nullcond sigwait thr_cancel vector3.cpp setTRUE: 1 3233 loop2 return 2 mono in free(): error: modified (page-) pointer Abort (core dumped) --- I can write sharable mutex and condition variable for mono, but current I have no time, because sigwait panic and my kernel umtx can not work with stupid swapped out kernel stack, I saw other OSes do not swap out kernel stack but they still works very well. :=( hope this helps, David Xu From owner-freebsd-threads@FreeBSD.ORG Thu Mar 3 15:14:23 2005 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1551116A4CE; Thu, 3 Mar 2005 15:14:23 +0000 (GMT) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id A471843D2D; Thu, 3 Mar 2005 15:14:22 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) j23FELbe006151; Thu, 3 Mar 2005 10:14:21 -0500 (EST) Date: Thu, 3 Mar 2005 10:14:21 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Andriy Tkachuk In-Reply-To: <012901c51fd3$131e23b0$090210ac@BORJA> Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/Mixed; BOUNDARY="----=_NextPart_000_0126_01C52001.298C64D0" Content-ID: X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) cc: threads@freebsd.org cc: David Xu Subject: Re: patch for threads/76690 - critical - fork hang in child for-lc_r X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Daniel Eischen List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 15:14:23 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ------=_NextPart_000_0126_01C52001.298C64D0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: On Thu, 3 Mar 2005, Andriy Tkachuk wrote: > > > > Hmm, libc_r and libpthread handle spinlock differently which malloc > > > > uses to protect itself, some real world benchmarks are better than > > this. > > yes , you right, David. one have to check __isthreaded before > firing _SPINLOCK. there will be nothing wrong, because > > static spinlock_t thread_lock = _SPINLOCK_INITIALIZER; > > initialyzed regardless __isthreaded in malloc.c but > for optimization probably it is worth to add this check. > Take a look on updated patch. > > btw: i don't see the unlock in child in libpthread. there must be two > unlocks I told you in previous mail, _kse_single_thread() calls _thr_spinlock_init(). The malloc lock is not the only lock used in libc, so the safe way to make sure libc is in a clean state after a fork is to reinitialize all the locks used by libc, not just the malloc lock. libc really shouldn't try to use any locks unless __isthreaded is true, so after a fork() it shouldn't really matter what state the locks are in. -- DE ------=_NextPart_000_0126_01C52001.298C64D0 Content-Type: APPLICATION/OCTET-STREAM; NAME="libc_r-76690pr.patch2" Content-Transfer-Encoding: QUOTED-PRINTABLE Content-ID: Content-Description: Content-Disposition: ATTACHMENT; FILENAME="libc_r-76690pr.patch2" diff -r -u lib/libc_r/uthread/uthread_fork.c = lib.patched/libc_r/uthread/uthread_fork.c=0A= --- lib/libc_r/uthread/uthread_fork.c Fri Dec 10 09:06:45 2004=0A= +++ lib.patched/libc_r/uthread/uthread_fork.c Thu Mar 3 14:50:06 2005=0A= @@ -68,8 +68,15 @@=0A= af->prepare();=0A= }=0A= =0A= + extern spinlock_t *__malloc_lock;=0A= + if (__isthreaded && __malloc_lock !=3D NULL)=0A= + _SPINLOCK(__malloc_lock);=0A= +=0A= /* Fork a new process: */=0A= if ((ret =3D __sys_fork()) !=3D 0) {=0A= + if (__isthreaded && __malloc_lock !=3D NULL)=0A= + _SPINUNLOCK(__malloc_lock);=0A= +=0A= /* Run down atfork parent handlers. */=0A= TAILQ_FOREACH(af, &_atfork_list, qe) {=0A= if (af->parent !=3D NULL)=0A= @@ -78,6 +85,9 @@=0A= _pthread_mutex_unlock(&_atfork_mutex);=0A= =0A= } else {=0A= + if (__isthreaded && __malloc_lock !=3D NULL)=0A= + _SPINUNLOCK(__malloc_lock);=0A= +=0A= /* Close the pthread kernel pipe: */=0A= __sys_close(_thread_kern_pipe[0]);=0A= __sys_close(_thread_kern_pipe[1]);=0A= ------=_NextPart_000_0126_01C52001.298C64D0 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Content-ID: Content-Description: Content-Disposition: INLINE _______________________________________________ freebsd-threads@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-threads To unsubscribe, send any mail to "freebsd-threads-unsubscribe@freebsd.org" ------=_NextPart_000_0126_01C52001.298C64D0-- From owner-freebsd-threads@FreeBSD.ORG Thu Mar 3 15:15:48 2005 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D7F7D16A4E8 for ; Thu, 3 Mar 2005 15:15:48 +0000 (GMT) Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8B1A743D2F for ; Thu, 3 Mar 2005 15:15:48 +0000 (GMT) (envelope-from rodrigc@crodrigues.org) Received: from h00609772adf0.ne.client2.attbi.com ([66.30.114.143]) by comcast.net (rwcrmhc12) with ESMTP id <2005030315154601400hs0p7e>; Thu, 3 Mar 2005 15:15:47 +0000 Received: from h00609772adf0.ne.client2.attbi.com (localhost [127.0.0.1]) j23FFjsF002554 for ; Thu, 3 Mar 2005 10:15:46 -0500 (EST) (envelope-from rodrigc@h00609772adf0.ne.client2.attbi.com) Received: (from rodrigc@localhost)j23FFiN6002553 for freebsd-threads@freebsd.org; Thu, 3 Mar 2005 10:15:44 -0500 (EST) (envelope-from rodrigc) Date: Thu, 3 Mar 2005 10:15:44 -0500 From: Craig Rodrigues To: freebsd-threads@freebsd.org Message-ID: <20050303151544.GA2518@crodrigues.org> References: <1109551418.782.30.camel@compass.straycat.dhs.org> <1109742079.777.15.camel@compass.straycat.dhs.org> <422649AF.5090606@freebsd.org> <1109833505.777.80.camel@compass.straycat.dhs.org> <4226B9DC.7040405@freebsd.org> <1109835366.777.95.camel@compass.straycat.dhs.org> <42272009.507@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42272009.507@freebsd.org> User-Agent: Mutt/1.4.1i Subject: Re: Mono's XSP crashes on browser connection X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 15:15:49 -0000 On Thu, Mar 03, 2005 at 10:32:41PM +0800, David Xu wrote: > whether _POSIX_THREAD_PROCESS_SHARED is defined or not in > source code, but he failed to respect this macro at many places, so the > macro is rather bogus. Side note: Keep in mind, that according to the POSIX/Single Unix Specification standards, if a _POSIX_* macro is defined, but is -1, that means that the feature is unsupported. ( See: http://www.opengroup.org/onlinepubs/009695399/basedefs/unistd.h.html ). We define a lot of POSIX macros like this in . The convention on Linux's glibc is to only define a _POSIX macro if the feature is supported. Consequently, a lot of software written on Linux which assumes this convention will break on FreeBSD. The Linux glibc convention is IMHO more intuitive, but FreeBSD is more "standards" conformant. So the Mono code is not entirely doing the right thing with respect to checking _POSIX_THREAD_PROCESS_SHARED....but you mention that the Mono code isn't even consistent in checking this macro. Bleh. :) -- Craig Rodrigues rodrigc@crodrigues.org From owner-freebsd-threads@FreeBSD.ORG Thu Mar 3 19:01:37 2005 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 731CD16A4CE for ; Thu, 3 Mar 2005 19:01:37 +0000 (GMT) Received: from lakermmtao01.cox.net (lakermmtao01.cox.net [68.230.240.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id C6FA143D31 for ; Thu, 3 Mar 2005 19:01:36 +0000 (GMT) (envelope-from mezz7@cox.net) Received: from mezz.mezzweb.com ([68.103.32.140]) by lakermmtao01.cox.net (InterMail vM.6.01.04.00 201-2131-118-20041027) with ESMTP id <20050303190134.NCDV29182.lakermmtao01.cox.net@mezz.mezzweb.com>; Thu, 3 Mar 2005 14:01:34 -0500 Date: Thu, 03 Mar 2005 13:02:51 -0600 To: "Craig Rodrigues" References: <1109551418.782.30.camel@compass.straycat.dhs.org> <1109742079.777.15.camel@compass.straycat.dhs.org> <422649AF.5090606@freebsd.org> <1109833505.777.80.camel@compass.straycat.dhs.org> <4226B9DC.7040405@freebsd.org> <1109835366.777.95.camel@compass.straycat.dhs.org> <42272009.507@freebsd.org> <20050303151544.GA2518@crodrigues.org> From: "Jeremy Messenger" Content-Type: text/plain; format=flowed; delsp=yes; charset=us-ascii MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <20050303151544.GA2518@crodrigues.org> User-Agent: Opera M2/7.54 (Linux, build 955) cc: freebsd-threads@freebsd.org Subject: Re: Mono's XSP crashes on browser connection X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 19:01:37 -0000 On Thu, 3 Mar 2005 10:15:44 -0500, Craig Rodrigues wrote: > On Thu, Mar 03, 2005 at 10:32:41PM +0800, David Xu wrote: >> whether _POSIX_THREAD_PROCESS_SHARED is defined or not in >> source code, but he failed to respect this macro at many places, so the >> macro is rather bogus. David, thanks for dig it deeper! > Side note: > > Keep in mind, that according to the POSIX/Single Unix Specification > standards, if a _POSIX_* macro is defined, but > is -1, that means that the feature is unsupported. > ( See: > http://www.opengroup.org/onlinepubs/009695399/basedefs/unistd.h.html ). > > We define a lot of POSIX macros like this in . Do you need anyone to test your ttyname_r patch? I can try to test it with mono here on RELENG_5 and see how it goes. I don't know ttyname_r that much, but I can dig in web/google. Cheers, Mezz > The convention on Linux's glibc is to only define a _POSIX > macro if the feature is supported. Consequently, a lot of > software written on Linux which assumes this convention will break > on FreeBSD. > > The Linux glibc convention is IMHO more intuitive, > but FreeBSD is more "standards" conformant. > > So the Mono code is not entirely doing the right thing > with respect to checking _POSIX_THREAD_PROCESS_SHARED....but > you mention that the Mono code isn't even consistent in checking this > macro. Bleh. :) -- mezz7@cox.net - mezz@FreeBSD.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gnome@FreeBSD.org From owner-freebsd-threads@FreeBSD.ORG Thu Mar 3 19:18:25 2005 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7B9D716A4CE for ; Thu, 3 Mar 2005 19:18:25 +0000 (GMT) Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3ABD743D39 for ; Thu, 3 Mar 2005 19:18:25 +0000 (GMT) (envelope-from rodrigc@crodrigues.org) Received: from h00609772adf0.ne.client2.attbi.com ([66.30.114.143]) by comcast.net (rwcrmhc13) with ESMTP id <2005030319182401500l4ojse>; Thu, 3 Mar 2005 19:18:24 +0000 Received: from h00609772adf0.ne.client2.attbi.com (localhost [127.0.0.1]) j23JIE4n003483; Thu, 3 Mar 2005 14:18:19 -0500 (EST) (envelope-from rodrigc@h00609772adf0.ne.client2.attbi.com) Received: (from rodrigc@localhost)j23JIERT003482; Thu, 3 Mar 2005 14:18:14 -0500 (EST) (envelope-from rodrigc) Date: Thu, 3 Mar 2005 14:18:13 -0500 From: Craig Rodrigues To: Jeremy Messenger Message-ID: <20050303191813.GA3469@crodrigues.org> References: <1109551418.782.30.camel@compass.straycat.dhs.org> <1109742079.777.15.camel@compass.straycat.dhs.org> <422649AF.5090606@freebsd.org> <1109833505.777.80.camel@compass.straycat.dhs.org> <4226B9DC.7040405@freebsd.org> <1109835366.777.95.camel@compass.straycat.dhs.org> <42272009.507@freebsd.org> <20050303151544.GA2518@crodrigues.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i cc: freebsd-threads@freebsd.org Subject: Re: Mono's XSP crashes on browser connection X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 19:18:25 -0000 On Thu, Mar 03, 2005 at 01:02:51PM -0600, Jeremy Messenger wrote: > Do you need anyone to test your ttyname_r patch? I can try to test it with > mono here on RELENG_5 and see how it goes. I don't know ttyname_r that > much, but I can dig in web/google. If you want to test my ttyname_r patch that would be great. I don't think ttyname_r() is used much in Mono, but I could be wrong. As per Robert Watson's suggestion here: http://lists.freebsd.org/pipermail/freebsd-threads/2005-February/002869.html I e-mailed Kris and asked him if he could scan the ports tree and see what links against ttyname_r(), since my patch could potentially represent an ABI change. The old ttyname_r() should never have been exported from libc, since it was not standards compliant, and did not have a prototype exported in unistd.h. Thanks. -- Craig Rodrigues rodrigc@crodrigues.org From owner-freebsd-threads@FreeBSD.ORG Thu Mar 3 19:25:05 2005 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A369116A4CE for ; Thu, 3 Mar 2005 19:25:05 +0000 (GMT) Received: from lakermmtao11.cox.net (lakermmtao11.cox.net [68.230.240.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0DBAF43D4C for ; Thu, 3 Mar 2005 19:25:05 +0000 (GMT) (envelope-from mezz7@cox.net) Received: from mezz.mezzweb.com ([68.103.32.140]) by lakermmtao11.cox.net (InterMail vM.6.01.04.00 201-2131-118-20041027) with ESMTP id <20050303192504.FYQH29670.lakermmtao11.cox.net@mezz.mezzweb.com>; Thu, 3 Mar 2005 14:25:04 -0500 To: "Craig Rodrigues" References: <1109551418.782.30.camel@compass.straycat.dhs.org> <1109742079.777.15.camel@compass.straycat.dhs.org> <422649AF.5090606@freebsd.org> <1109833505.777.80.camel@compass.straycat.dhs.org> <4226B9DC.7040405@freebsd.org> <1109835366.777.95.camel@compass.straycat.dhs.org> <42272009.507@freebsd.org> <20050303151544.GA2518@crodrigues.org> <20050303191813.GA3469@crodrigues.org> Message-ID: Date: Thu, 03 Mar 2005 13:26:19 -0600 From: "Jeremy Messenger" Content-Type: text/plain; format=flowed; delsp=yes; charset=us-ascii MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <20050303191813.GA3469@crodrigues.org> User-Agent: Opera M2/7.54 (Linux, build 955) cc: freebsd-threads@freebsd.org Subject: Re: Mono's XSP crashes on browser connection X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 19:25:05 -0000 On Thu, 3 Mar 2005 14:18:13 -0500, Craig Rodrigues wrote: > On Thu, Mar 03, 2005 at 01:02:51PM -0600, Jeremy Messenger wrote: >> Do you need anyone to test your ttyname_r patch? I can try to test it >> with >> mono here on RELENG_5 and see how it goes. I don't know ttyname_r that >> much, but I can dig in web/google. > > If you want to test my ttyname_r patch that would be great. > I don't think ttyname_r() is used much in Mono, but I could be wrong. Read in PR again, Mono was the reason why PR was created. Tom and I work together in BSD#. ;-) I will test it soon as when RELENG_5 can be build. I keep get build fail for two days without your patch. > As per Robert Watson's suggestion here: > http://lists.freebsd.org/pipermail/freebsd-threads/2005-February/002869.html > > I e-mailed Kris and asked him if he could scan > the ports tree and see what links against ttyname_r(), > since my patch could potentially represent > an ABI change. The old ttyname_r() should never have been exported > from libc, since it was not standards compliant, and did not > have a prototype exported in unistd.h. I am glad that you took over and do the standard, a better one. Thanks for doing it! Cheers, Mezz > Thanks. -- mezz7@cox.net - mezz@FreeBSD.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gnome@FreeBSD.org From owner-freebsd-threads@FreeBSD.ORG Thu Mar 3 20:29:55 2005 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 828A416A4CE for ; Thu, 3 Mar 2005 20:29:55 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 65AD743D39 for ; Thu, 3 Mar 2005 20:29:55 +0000 (GMT) (envelope-from julian@elischer.org) Received: from [208.206.78.97] (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id E4FD47A403; Thu, 3 Mar 2005 12:29:54 -0800 (PST) Message-ID: <422773C2.8090607@elischer.org> Date: Thu, 03 Mar 2005 12:29:54 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050218 X-Accept-Language: en, hu MIME-Version: 1.0 To: Andriy Tkachuk References: <000b01c51fbb$4189ea30$090210ac@BORJA> In-Reply-To: <000b01c51fbb$4189ea30$090210ac@BORJA> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: threads@freebsd.org Subject: Re: patch for threads/76690 - critical - fork hang in child for -lc_r X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 20:29:55 -0000 the bug is still valid in 4.x Andriy Tkachuk wrote: >>Is there a reason you are still using libc_r? >> >> > >I don't use it at all, but there was critical bug >i threads-pr - so i just decided to fix it since i >have had some time ) > >If this library is needless, why is it still there >and this pr in criticals? >_______________________________________________ >freebsd-threads@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-threads >To unsubscribe, send any mail to "freebsd-threads-unsubscribe@freebsd.org" > > From owner-freebsd-threads@FreeBSD.ORG Thu Mar 3 23:37:04 2005 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 623DC16A4CF for ; Thu, 3 Mar 2005 23:37:04 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4685C43D2F; Thu, 3 Mar 2005 23:37:04 +0000 (GMT) (envelope-from davidxu@freebsd.org) Received: from [127.0.0.1] (davidxu@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j23Nb1Mo081072; Thu, 3 Mar 2005 23:37:03 GMT (envelope-from davidxu@freebsd.org) Message-ID: <42279FA0.2020007@freebsd.org> Date: Fri, 04 Mar 2005 07:37:04 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.7.2) Gecko/20041004 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeremy Messenger References: <1109551418.782.30.camel@compass.straycat.dhs.org> <1109742079.777.15.camel@compass.straycat.dhs.org> <422649AF.5090606@freebsd.org> <1109833505.777.80.camel@compass.straycat.dhs.org> <4226B9DC.7040405@freebsd.org> <1109835366.777.95.camel@compass.straycat.dhs.org> <42272009.507@freebsd.org> <20050303151544.GA2518@crodrigues.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-threads@freebsd.org Subject: Re: Mono's XSP crashes on browser connection X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 23:37:04 -0000 Jeremy Messenger wrote: > On Thu, 3 Mar 2005 10:15:44 -0500, Craig Rodrigues > wrote: > >> On Thu, Mar 03, 2005 at 10:32:41PM +0800, David Xu wrote: >> >>> whether _POSIX_THREAD_PROCESS_SHARED is defined or not in >>> source code, but he failed to respect this macro at many places, so >>> the >>> macro is rather bogus. >> > > David, thanks for dig it deeper! So my conclusion is mono can not be used on FreeBSD, because process sharable mutex and condition variable are not supported. it is possible writting a special version of mutex and condition variable for mono by using kernel umtx code, but now umtx is also broken by a FEATURE called swappable kernel stack, otherwise, someone can just pick up code from my private pthread library, http://people.freebsd.org/~davidxu/libthread.tgz in the library, mutex and condition variable structure can be put on shared memory segments, there is no pointer in the structure, only counter and some bit flags. David Xu From owner-freebsd-threads@FreeBSD.ORG Fri Mar 4 03:25:09 2005 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 745BE16A4CE for ; Fri, 4 Mar 2005 03:25:09 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5C1CD43D31; Fri, 4 Mar 2005 03:25:09 +0000 (GMT) (envelope-from davidxu@freebsd.org) Received: from [127.0.0.1] (davidxu@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j243P7dW013833; Fri, 4 Mar 2005 03:25:08 GMT (envelope-from davidxu@freebsd.org) Message-ID: <4227D501.8090706@freebsd.org> Date: Fri, 04 Mar 2005 11:24:49 +0800 From: David Xu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Elischer References: <000b01c51fbb$4189ea30$090210ac@BORJA> <422773C2.8090607@elischer.org> In-Reply-To: <422773C2.8090607@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: threads@freebsd.org Subject: Re: patch for threads/76690 - critical - fork hang in child for -lc_r X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2005 03:25:09 -0000 4.x does not have a __malloc_lock symbol exported, I had suggested to add __malloc_lock in FreeBSD 5 libpthread since I saw some broken applications call malloc in child process after fork() and before execv(). :) Julian Elischer wrote: > the bug is still valid in 4.x > > > Andriy Tkachuk wrote: > >>> Is there a reason you are still using libc_r? >>> >> >> >> I don't use it at all, but there was critical bug >> i threads-pr - so i just decided to fix it since i >> have had some time ) >> >> If this library is needless, why is it still there >> and this pr in criticals? > From owner-freebsd-threads@FreeBSD.ORG Fri Mar 4 05:24:49 2005 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 42FD916A4CE; Fri, 4 Mar 2005 05:24:49 +0000 (GMT) Received: from straycat.dhs.org (h0050da134090.ne.client2.attbi.com [24.60.174.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 30F4943D1D; Fri, 4 Mar 2005 05:24:48 +0000 (GMT) (envelope-from tmclaugh@sdf.lonestar.org) Received: from compass.straycat.dhs.org (compass.straycat.dhs.org [192.168.1.48]) by straycat.dhs.org (8.13.0/8.13.0) with ESMTP id j245PgYm031721; Fri, 4 Mar 2005 00:25:43 -0500 (EST) From: Tom McLaughlin To: David Xu In-Reply-To: <42279FA0.2020007@freebsd.org> References: <1109551418.782.30.camel@compass.straycat.dhs.org> <1109742079.777.15.camel@compass.straycat.dhs.org> <422649AF.5090606@freebsd.org> <1109833505.777.80.camel@compass.straycat.dhs.org> <4226B9DC.7040405@freebsd.org> <1109835366.777.95.camel@compass.straycat.dhs.org> <42272009.507@freebsd.org> <20050303151544.GA2518@crodrigues.org> <42279FA0.2020007@freebsd.org> Content-Type: text/plain Date: Fri, 04 Mar 2005 00:25:13 -0500 Message-Id: <1109913913.777.172.camel@compass.straycat.dhs.org> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit cc: freebsd-threads@freebsd.org Subject: Re: Mono's XSP crashes on browser connection X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2005 05:24:49 -0000 On Fri, 2005-03-04 at 07:37 +0800, David Xu wrote: > Jeremy Messenger wrote: > > > On Thu, 3 Mar 2005 10:15:44 -0500, Craig Rodrigues > > wrote: > > > >> On Thu, Mar 03, 2005 at 10:32:41PM +0800, David Xu wrote: > >> > >>> whether _POSIX_THREAD_PROCESS_SHARED is defined or not in > >>> source code, but he failed to respect this macro at many places, so > >>> the > >>> macro is rather bogus. > >> > > > > David, thanks for dig it deeper! > > So my conclusion is mono can not be used on FreeBSD, because process > sharable mutex and condition variable are not supported. it is possible > writting a special version of mutex and condition variable for mono by > using kernel umtx code, but now umtx is also broken by a FEATURE > called swappable kernel stack, otherwise, someone can just pick up > code from my private pthread library, > http://people.freebsd.org/~davidxu/libthread.tgz > in the library, mutex and condition variable structure can be put on > shared memory segments, there is no pointer in the structure, only > counter and some bit flags. David, what are the plans for libthread in the future? Is your library intended to replace libpthread, intended as an alternate source for introducing things into libpthread, or, well I don't know. My concern is the growing popularity of Mono on Linux and .NET in general. Mono also affects Gnome since most free software C# apps I've found use gtk#. The C# case I gave you is a fairly common thing to do and currently it prevents the XSP webserver for ASP.NET apps from being supported on FreeBSD and MonoDevelop which is an IDE geared towards Mono. (The Eclipse C# plugin is pants and while I'm happy with Vim for now, the FreeBSD Mono users want MonoDevelop.) As the current crop of apps mature I can see more things breaking. I'm not sure what other bugs lurk with Mono on FreeBSD yet since the Mono and the apps using it are not yet fully mature. Mono isn't popular in the *BSD world yet. I assume it will soon become fairly popular based on the entities supporting it either directly (Novell) or indirectly (Microsoft). Mono is currently supported on FreeBSD by Jeremy Messenger and myself. Both of us are learning as we go along. I'm looking to attract at least another port maintainer right now because maintaining the existing ports and adding new ones is a job in and of itself. Currently I have about 20 ports and a list of about 20 more that look promising. I could even use a C# programmer who can help me as I slowly get up to speed with the language. I can't attract more help with Mono being fairly unstable on FreeBSD. It's an odd circle with Mono. I can't attract help because there are so few apps in the ports tree. I can't get more apps in the ports tree because I can't attract help. In short, I don't want to see Mono a year or two from now barely limping along on FreeBSD like it has for so long. I don't want to see users turning away from FreeBSD because their favorite app from the Linux distro they use is not available. I don't want to be playing catchup with port availability a few years from now either. Alright, I need sleep now. Anything you can tell me about the possibility of seeing some of your libthread changes in FreeBSD would be great. Thanks. Tom -- BSD# Project - Porting Mono to FreeBSD http://forge.novell.com/modules/xfmod/project/?bsd-sharp From owner-freebsd-threads@FreeBSD.ORG Fri Mar 4 05:57:21 2005 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7558316A4CE for ; Fri, 4 Mar 2005 05:57:21 +0000 (GMT) Received: from mail.emict.com (brig.emict.com [212.90.172.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id D3E0243D1F for ; Fri, 4 Mar 2005 05:57:20 +0000 (GMT) (envelope-from andrit@ukr.net) Received: from BORJA (unknown [203.199.120.221]) by mail.emict.com (Postfix) with ESMTP id 7D51134742 for ; Fri, 4 Mar 2005 07:57:17 +0200 (EET) Message-ID: <027801c5207f$082e3ab0$090210ac@BORJA> From: "Andriy Tkachuk" To: References: Date: Fri, 4 Mar 2005 11:27:15 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: Re: patch for threads/76690 - critical - fork hang in child for-lc_r X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2005 05:57:21 -0000 yes, Daniel, thank you. i've already figured this out, thank to David Xu ) but in libc_r there is not some spinlock_init() i which locks are remembered (as far as i can see) , so i think, that in libc_r it is worth to explicitly unlock the __malloc_lock in child. yours, Andriy. ----- Original Message ----- From: "Daniel Eischen" To: "Andriy Tkachuk" Cc: "David Xu" ; Sent: Thursday, March 03, 2005 20:44 Subject: Re: patch for threads/76690 - critical - fork hang in child for-lc_r > On Thu, 3 Mar 2005, Andriy Tkachuk wrote: > > > > > > Hmm, libc_r and libpthread handle spinlock differently which malloc > > > > > uses to protect itself, some real world benchmarks are better than > > > this. > > > > yes , you right, David. one have to check __isthreaded before > > firing _SPINLOCK. there will be nothing wrong, because > > > > static spinlock_t thread_lock = _SPINLOCK_INITIALIZER; > > > > initialyzed regardless __isthreaded in malloc.c but > > for optimization probably it is worth to add this check. > > Take a look on updated patch. > > > > btw: i don't see the unlock in child in libpthread. there must be two > > unlocks > > I told you in previous mail, _kse_single_thread() calls > _thr_spinlock_init(). The malloc lock is not the only > lock used in libc, so the safe way to make sure libc > is in a clean state after a fork is to reinitialize all > the locks used by libc, not just the malloc lock. libc > really shouldn't try to use any locks unless __isthreaded > is true, so after a fork() it shouldn't really matter > what state the locks are in. > > -- > DE