This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: debugging SIGSEV on pclose


On Thu, Sep 08, 2011 at 06:20:26PM +0200, Marco atzeri wrote:
>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 ?

As I said, on Linux, if you call pclose twice in succession you get
a SEGV.  I am comfortable with Cygwin's behavior especially since you
seem to be seeing an actual program problem.

>>
>>>
>>>> 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

Well, one of them is in an execed process.  Some of the others are in
different processes.

cgf

--
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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]