You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@stdcxx.apache.org by Andrew Black <ab...@roguewave.com> on 2008/10/23 17:10:14 UTC

22.locale.numpunct.mt run hangs

Greetings all.

At this time, we have two build types which are producing hanging builds
in nightly testing.  These builds are thread-safe (32-bit archive)
builds with the eccp compiler on Redhat 5.  This hang is known to be
exhibited using the 4.2.x branch, and may be exhibited on other branches.

These hangs point at two issues in the code base.  First, there's the
obvious problem of the test in question hanging. Second, there's the
failure of the run utility to kill this particular test.  I've attached
the .out files for the test from the latest builds in question, but they
aren't telling me much.  When I manually sent a kill message to the
tests in question, it was sufficient to send a SIGTERM.

--Andrew Black

Re: 22.locale.numpunct.mt run hangs

Posted by Martin Sebor <ms...@gmail.com>.
Andrew Black wrote:
> Greetings all.
> 
> At this time, we have two build types which are producing hanging builds
> in nightly testing.  These builds are thread-safe (32-bit archive)
> builds with the eccp compiler on Redhat 5.  This hang is known to be
> exhibited using the 4.2.x branch, and may be exhibited on other branches.
> 
> These hangs point at two issues in the code base.  First, there's the
> obvious problem of the test in question hanging.

That is disconcerting.

> Second, there's the
> failure of the run utility to kill this particular test.

That could be because of the strict mode we're in with EDG eccp.
In this mode, many standard UNIX interfaces (such as signal names)
are not exposed through our strict headers (i.e., <signal.h>). So
it's possible that no signal is being sent...

> I've attached
> the .out files for the test from the latest builds in question, but they
> aren't telling me much.  When I manually sent a kill message to the
> tests in question, it was sufficient to send a SIGTERM.

Let me see if I can reproduce and debug it.

Martin

> 
> --Andrew Black
>