Return-Path: Delivered-To: apmail-incubator-stdcxx-dev-archive@www.apache.org Received: (qmail 46256 invoked from network); 10 Aug 2007 16:07:52 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 10 Aug 2007 16:07:52 -0000 Received: (qmail 43262 invoked by uid 500); 10 Aug 2007 16:07:50 -0000 Delivered-To: apmail-incubator-stdcxx-dev-archive@incubator.apache.org Received: (qmail 43250 invoked by uid 500); 10 Aug 2007 16:07:50 -0000 Mailing-List: contact stdcxx-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: stdcxx-dev@incubator.apache.org Delivered-To: mailing list stdcxx-dev@incubator.apache.org Received: (qmail 43239 invoked by uid 99); 10 Aug 2007 16:07:50 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 10 Aug 2007 09:07:50 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [208.30.140.160] (HELO moroha.quovadx.com) (208.30.140.160) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 10 Aug 2007 16:07:42 +0000 Received: from qxvcexch01.ad.quovadx.com ([192.168.170.59]) by moroha.quovadx.com (8.13.6/8.13.6) with ESMTP id l7AG7KMw008333 for ; Fri, 10 Aug 2007 16:07:20 GMT Received: from [10.70.3.113] ([10.70.3.113]) by qxvcexch01.ad.quovadx.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Aug 2007 10:06:39 -0600 Message-ID: <46BC8D5B.2@roguewave.com> Date: Fri, 10 Aug 2007 10:07:55 -0600 From: Martin Sebor Organization: Rogue Wave Software, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.2) Gecko/20070221 SeaMonkey/1.1.1 MIME-Version: 1.0 To: stdcxx-dev@incubator.apache.org Subject: Re: negative exit status in Windows builds References: <46B9ED37.3080008@roguewave.com> <7BDB2168BEAEF14C98F1901FD2DE6438C91417@epmsa009.minsk.epam.com> <46BA2631.8020605@roguewave.com> <7BDB2168BEAEF14C98F1901FD2DE6438C91479@epmsa009.minsk.epam.com> <46BC85DA.6050309@roguewave.com> <7BDB2168BEAEF14C98F1901FD2DE6438C9181A@epmsa009.minsk.epam.com> In-Reply-To: <7BDB2168BEAEF14C98F1901FD2DE6438C9181A@epmsa009.minsk.epam.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Aug 2007 16:06:39.0881 (UTC) FILETIME=[6F9A3F90:01C7DB68] X-Virus-Checked: Checked by ClamAV on apache.org Farid Zaripov wrote: >> -----Original Message----- >> From: Martin Sebor [mailto:sebor@roguewave.com] >> Sent: Friday, August 10, 2007 6:36 PM >> To: stdcxx-dev@incubator.apache.org >> Subject: Re: negative exit status in Windows builds >> >> Farid Zaripov wrote: >>>> -----Original Message----- >>>> From: Martin Sebor [mailto:sebor@roguewave.com] >>>> Sent: Wednesday, August 08, 2007 11:23 PM >>>> To: stdcxx-dev@incubator.apache.org >>>> Subject: Re: negative exit status in Windows builds >>>> >>>> STATUS_STACK_OVERFLOW can be mapped to SIGSTKFLT (used for this >>>> purpose on Linux). >>> But SIGSTKFLT is signals when the coprocessor experiences a stack >>> fault >>> (http://en.wikipedia.org/wiki/SIGSTKFLT) and we have program stack >>> overflow. >> What's the difference? > > The coprocessor stack is the memory inside coprocessor (set of the > registers) > and program stack is the part of the common RAM. I see. You're right, it probably wouldn't be appropriate to map STATUS_STACK_OVERFLOW on the main processor to a coprocessor error, even if it's not used anymore. Although by mapping to SIGSEGV we are losing a valuable piece of information about the failure. It would be nice if we could find a way to preserve it. FWIW, I haven't found much information on SIGSTKFLT on the net. The most informative description I came across is this one: SIGSTKFLT This signal is defined only by Linux. This signal showed up in the earliest versions of Linux, intended to be used for stack faults taken by the math coprocessor. This signal is not generated by the kernel, but remains for backward compatibility. http://book.chinaunix.net/special/ebook/addisonWesley/APUE2/0201433079/ch10lev1sec2.html Martin