stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Black (JIRA)" <j...@apache.org>
Subject [jira] Commented: (STDCXX-426) infinite loop in exec utility
Date Fri, 25 May 2007 16:30:16 GMT

    [ https://issues.apache.org/jira/browse/STDCXX-426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12499145
] 

Andrew Black commented on STDCXX-426:
-------------------------------------

I have a couple more notes on this issue that came out of the collaborative analysis Martin
and I made of this issue last night.

The first note regards the signal that is sent after the child process has terminated.  This
signal is being sent to the child process group.  The purpose is to ensure the termination
of grandchild processes.  The logic of the code that does this cleanup isn't particularly
clear, so I need to add some commentary to it.

Martin also suggested making a possible change to this section of the code.  That change was
to check if the process group exists (by sending signal 0 to it) prior to sending signals
to it.  I believe I considered this when crafting the loop, but discarded it.  Part of my
reason for doing so was because one of the exit conditions for the loop is when the kill signal
fails to send a message to the group.  My perception of the benefit of doing things this way
is that it reduces the number of system calls made when grandchild processes need to be harvested.

The second note regards the mechanics used to process the test suite output.  At this time,
the parser uses a simple finite state machine (FSM) to search through the output file, byte
by byte, to locate the output summary, starting at the beginning of the file.  However, this
processing method was changed in http://svn.apache.org/viewvc?view=rev&revision=515332
and http://svn.apache.org/viewvc?view=rev&revision=516188 .  Prior to the later commit,
the script was first seek()ing to a location near the end of the file prior to beginning the
search.  The problem with this method is that some tests produce output after the summary
totals have been printed out.  The earlier change adjusted the seek location to a point earlier
in the file to accommodate this trailing output, but no guarantees can be made about the amount
of trailing information.
A possibly 'better' way to perform this search would be to seek to the end of the file, then
parse backwards, looking for a marker that indicates you've reached the beginning of the summary,
then read forwards to parse the summary itself.

--Andrew Black

> infinite loop in exec utility
> -----------------------------
>
>                 Key: STDCXX-426
>                 URL: https://issues.apache.org/jira/browse/STDCXX-426
>             Project: C++ Standard Library
>          Issue Type: Bug
>          Components: Test Driver
>    Affects Versions: 4.2
>         Environment: gcc 3.4.6 on Red Hat Advanced Server 4, 12D (shared, wide, optimized,
thread-safe) build
>            Reporter: Mark Brown
>         Assigned To: Andrew Black
>            Priority: Critical
>             Fix For: 4.2
>
>         Attachments: strace.run-21.cwchar.log
>
>
> Copied from http://mail-archives.apache.org/mod_mbox/incubator-stdcxx-dev/200705.mbox/%3c4654A3FF.8020907@roguewave.com%3e
> -------- Original Message --------
> Subject: infinite loop in exec
> Date: Wed, 23 May 2007 14:28:47 -0600
> From: Martin Sebor <sebor@roguewave.com>
> Reply-To: stdcxx-dev@incubator.apache.org
> Organization: Rogue Wave Software
> To: stdcxx-dev@incubator.apache.org
> I'm running into an (almost?) infinite loop when running some
> of our tests under the exec utility on Linux (in a 12D build
> with gcc 3.4.6 on Red Hat Advanced Server 4, I haven't tried
> other configurations). The initial output of strace for one
> of the tests, 21.cwchar, is in the attached file. The test
> by itself runs fine to completion and doesn't produce any
> unusual output (no NULs).
> Andrew, when you have a chance, can you take a look at it?
> If that's not going to be soon let me know if I should open
> an issue.
> Martin

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message