| delorie.com/archives/browse.cgi | search |
| X-Recipient: | archive-cygwin AT delorie DOT com |
| X-SWARE-Spam-Status: | No, hits=0.1 required=5.0 tests=AWL,BAYES_40,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,FRT_APPROV,RCVD_IN_DNSWL_LOW,TW_CG,T_TO_NO_BRKTS_FREEMAIL |
| X-Spam-Check-By: | sourceware.org |
| Message-ID: | <4E68EB4A.5040406@gmail.com> |
| Date: | Thu, 08 Sep 2011 18:20:26 +0200 |
| From: | Marco atzeri <marco DOT atzeri AT gmail DOT com> |
| User-Agent: | Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 |
| MIME-Version: | 1.0 |
| To: | cygwin AT cygwin DOT com |
| Subject: | Re: debugging SIGSEV on pclose |
| References: | <4E64BE96 DOT 5020107 AT gmail DOT com> <4E68CE13 DOT 6010106 AT gmail DOT com> <20110908142702 DOT GA28918 AT ednor DOT casa DOT cgf DOT cx> <4E68DB48 DOT 3050906 AT gmail DOT com> |
| In-Reply-To: | <4E68DB48.3050906@gmail.com> |
| X-IsSubscribed: | yes |
| Mailing-List: | contact cygwin-help AT cygwin DOT com; run by ezmlm |
| List-Id: | <cygwin.cygwin.com> |
| List-Subscribe: | <mailto:cygwin-subscribe AT cygwin DOT com> |
| List-Archive: | <http://sourceware.org/ml/cygwin/> |
| List-Post: | <mailto:cygwin AT cygwin DOT com> |
| List-Help: | <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs> |
| Sender: | cygwin-owner AT cygwin DOT com |
| Mail-Followup-To: | cygwin AT cygwin DOT com |
| Delivered-To: | mailing list cygwin AT cygwin DOT com |
On 9/8/2011 5:12 PM, Marco atzeri wrote:
> On 9/8/2011 4:27 PM, Christopher Faylor wrote:
>> On Thu, Sep 08, 2011 at 04:15:47PM +0200, Marco atzeri wrote:
>
>>> Question:
>>> is a mistake in pclose to assume that fh could be invalid
>>
>> I'm not sure what you're asking here. It's not a mistake to assume that
>> pclose is being passed a valid fp. Linux also crashes if the fp is
>> closed twice.
>
> Just as I noticed earlier on syscall.cc a defensive approuch
>
> -----------------------------------------------
> close_all_files (bool norelease)
> {
> cygheap->fdtab.lock ();
>
> semaphore::terminate ();
>
> fhandler_base *fh;
> HANDLE h = NULL;
>
> for (int i = 0; i < (int) cygheap->fdtab.size; i++)
> if ((fh = cygheap->fdtab[i]) != NULL)
> {
> ------------------------------------------------
using the same defensive approuch on pclose,
I see no more SEGFAULT, just some lost popen childs
that are closed on octave exit.
--- syscalls.cc~ 2011-08-02 20:19:18.000000000 +0200
+++ syscalls.cc 2011-09-08 16:31:03.109375000 +0200
@@ -4023,7 +4023,7 @@
{
fhandler_pipe *fh = (fhandler_pipe *) cygheap->fdtab[fileno(fp)];
- if (fh->get_device () != FH_PIPEW && fh->get_device () != FH_PIPER)
+ if ( !fh ||(fh->get_device () != FH_PIPEW && fh->get_device () !=
FH_PIPER))
{
set_errno (EBADF);
return -1;
Does it make sense ?
>
>>
>>> or something is just trashing cygheap->fdtab ?
>>
>> Who knows? strace should show if the fp is closed twice.
>>
>> cgf
>
> correct, it looks I have two close in excess for fd 5 and 6
>
> Thanks
> Marco
>
>
too fast, the mismatch are the pipe closure,
that are reported differently as opening
I see a double pipe closure
$ grep 'pipe:\[5\]' octave.strace
24 595 [main] sh 2840 fhandler_base::fixup_after_exec: here for
'/dev/fd/pipe:[5]'
35 103396815 [main] octave-3.4.2 3664 fhandler_base::close: closing
'/dev/fd/pipe:[5]' handle 0x46C
37 896 [main] gs 2840 fhandler_base::fixup_after_exec: here for
'/dev/fd/pipe:[5]'
48 93072 [main] sh 2840! fhandler_base::close: closing
'/dev/fd/pipe:[5]' handle 0x46C
31 2358333 [main] gs 2840 fhandler_base::close: closing
'/dev/fd/pipe:[5]' handle 0x46C
but I guess they are the two sides of the pipe
spawn_guts: 2840 = spawn_guts (/bin/sh, E:\cygwin2\bin\sh.exe -c
"/usr/bin/gs -dQUIET -dNOPAUSE -dBATCH -dSAFER -sDEVICE=png16m
-dTextAlphaBits=4 -dGraphicsAlphaBits=4 -r150x150 -dEPSCrop
-sOutputFile=plot.png -")
Marco
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
| webmaster | delorie software privacy |
| Copyright © 2019 by DJ Delorie | Updated Jul 2019 |