On 03/31/2016 08:48 PM, Yvan Roux wrote:
> No I'm using gcc trunk at revision 234447 (March 24th), I think you
> didn't look at the same part of guality testing (if you looked at
> lib/gcc-gdb-test.exp), I don't know well this part of the testsuite
> but my understanding is that this test is self
On 31 March 2016 at 21:27, Pedro Alves wrote:
> On 03/31/2016 08:01 PM, Yvan Roux wrote:
>> On 31 March 2016 at 20:54, Pedro Alves wrote:
>>> On 03/31/2016 07:46 PM, Yvan Roux wrote:
So, when I look in /proc/, the status of the 2 processes are:
example.exe : tracing stop
cat : zomb
On 03/31/2016 08:01 PM, Yvan Roux wrote:
> On 31 March 2016 at 20:54, Pedro Alves wrote:
>> On 03/31/2016 07:46 PM, Yvan Roux wrote:
>>> So, when I look in /proc/, the status of the 2 processes are:
>>> example.exe : tracing stop
>>> cat : zombie
>>> and the wait return value is 0
>>
>> I'm confus
On 31 March 2016 at 20:54, Pedro Alves wrote:
> On 03/31/2016 07:46 PM, Yvan Roux wrote:
>> So, when I look in /proc/, the status of the 2 processes are:
>> example.exe : tracing stop
>> cat : zombie
>> and the wait return value is 0
>
> I'm confused. What about the other two processes? Before
>
On 03/31/2016 07:46 PM, Yvan Roux wrote:
> So, when I look in /proc/, the status of the 2 processes are:
> example.exe : tracing stop
> cat : zombie
> and the wait return value is 0
I'm confused. What about the other two processes? Before
you said none of the 4 processes is actually killed. Was
On 31 March 2016 at 19:35, Pedro Alves wrote:
> On 03/31/2016 04:25 PM, Yvan Roux wrote:
>> Hi Pedro,
>>
>> On 31 March 2016 at 16:20, Pedro Alves wrote:
>
>> The regression is due to this part:
>>
>> +# Reap it.
>> +set res [catch "wait -i $program_id" wres]
>> +if {$exec_pid != -1}
On 03/31/2016 04:25 PM, Yvan Roux wrote:
> Hi Pedro,
>
> On 31 March 2016 at 16:20, Pedro Alves wrote:
> The regression is due to this part:
>
> +# Reap it.
> +set res [catch "wait -i $program_id" wres]
> +if {$exec_pid != -1} {
> + # We reaped the process, so cancel the pendi
On 31 March 2016 at 16:54, Pedro Alves wrote:
> On 03/30/2016 04:03 PM, Yvan Roux wrote:
>>
>> I not sure what's the best way to fix this issue without
>> re-introducing the pid race in GDB. I'm testing a solution which
>> first gather all the childs processes of the close_wait_program pid
>> inp
Hi Pedro,
On 31 March 2016 at 16:20, Pedro Alves wrote:
> On 03/30/2016 04:03 PM, Yvan Roux wrote:
>> Hi,
>>
>> https://lists.gnu.org/archive/html/dejagnu/2015-07/msg0.html
>>
>> this patch introduced a new failure related to GDB testing, but this
>> time in GCC guality part of the testsuite
On 03/30/2016 04:03 PM, Yvan Roux wrote:
>
> I not sure what's the best way to fix this issue without
> re-introducing the pid race in GDB. I'm testing a solution which
> first gather all the childs processes of the close_wait_program pid
> input (with a recursive call of pgrep -P) and then kill
On 03/30/2016 04:03 PM, Yvan Roux wrote:
> Hi,
>
> https://lists.gnu.org/archive/html/dejagnu/2015-07/msg0.html
>
> this patch introduced a new failure related to GDB testing, but this
> time in GCC guality part of the testsuite. When
> gcc/testsuite/gcc.dg/guality/example.c is executed we
On 31 March 2016 at 12:20, Ben Elliston wrote:
> On Thu, Mar 31, 2016 at 12:11:59PM +0200, Christophe Lyon wrote:
>
>> But since we currently have "|&cat", we do redirect stderr, so the
>> "and that standard error is not redirected" claude above is not
>> fulfilled. Do you know what happens in thi
On 30 March 2016 at 10:47, Ben Elliston wrote:
> On Wed, Mar 30, 2016 at 10:15:46AM +0200, Christophe Lyon wrote:
>
>> Well, I re-ran it, and I still have no evidence of using standard_wait.
>> Are you running native validations?
>
> Yes.
>
>> I remind you that we are using a cross-testing configu
On Thu, Mar 31, 2016 at 12:11:59PM +0200, Christophe Lyon wrote:
> But since we currently have "|&cat", we do redirect stderr, so the
> "and that standard error is not redirected" claude above is not
> fulfilled. Do you know what happens in this case?
No, but I would suggest that it is cleaner an
On 31 March 2016 at 12:03, Ben Elliston wrote:
> On Thu, Mar 31, 2016 at 11:11:14AM +0200, Christophe Lyon wrote:
>
>> It seems that the remote stdout/stderr are merged by tcl, rather
>> than dejagnu, since replacing "|&cat" in dejagnu with "2>/dev/null"
>> does not discard the remote stderr conte
On Thu, Mar 31, 2016 at 11:11:14AM +0200, Christophe Lyon wrote:
> It seems that the remote stdout/stderr are merged by tcl, rather
> than dejagnu, since replacing "|&cat" in dejagnu with "2>/dev/null"
> does not discard the remote stderr contents.
BTW, I just confirmed through careful reading of
On 31 March 2016 at 11:06, Maxim Kuvyrkov wrote:
> On Mar 30, 2016, at 6:36 PM, Christophe Lyon
> wrote:
>>
>> On 30 March 2016 at 15:44, Maxim Kuvyrkov wrote:
>>> Hi Ben,
>>> Hi Christophe,
>>>
>>> [TL;DR] Will it be a problem for dejagnu to merge test's stderr into stderr
>>> with an equival
On Mar 30, 2016, at 6:36 PM, Christophe Lyon wrote:
>
> On 30 March 2016 at 15:44, Maxim Kuvyrkov wrote:
>> Hi Ben,
>> Hi Christophe,
>>
>> [TL;DR] Will it be a problem for dejagnu to merge test's stderr into stderr
>> with an equivalent of bash's 2>&1 ?
>>
>> From my investigations of the sa
18 matches
Mail list logo
