[dpdk-stable] [PATCH] test: fix hang on FreeBSD

[dpdk-stable] [PATCH] test: fix hang on FreeBSD

[Radu Nicolau]

Fixes: af75078fece3 ("first public release")
Cc: stable@dpdk.org

Signed-off-by: Radu Nicolau <radu.nicolau@intel.com>
---
 test/test/test_debug.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/test/test/test_debug.c b/test/test/test_debug.c
index faf2cf5..56fadce 100644
--- a/test/test/test_debug.c
+++ b/test/test/test_debug.c
@@ -34,7 +34,8 @@ test_panic(void)
 		printf("Fork Failed\n");
 		return -1;
 	}
-	wait(&status);
+	sleep(1);
+	waitpid(pid, &status, WNOHANG);
 	if(status == 0){
 		printf("Child process terminated normally!\n");
 		return -1;
-- 
2.7.5

Re: [dpdk-stable] [PATCH] test: fix hang on FreeBSD

[Thomas Monjalon]

21/05/2018 13:35, Radu Nicolau:
> Fixes: af75078fece3 ("first public release")
> Cc: stable@dpdk.org
> 
> Signed-off-by: Radu Nicolau <radu.nicolau@intel.com>
> ---
> @@ -34,7 +34,8 @@ test_panic(void)
>  		printf("Fork Failed\n");
>  		return -1;
>  	}
> -	wait(&status);
> +	sleep(1);
> +	waitpid(pid, &status, WNOHANG);

Please give an explanation why you are adding this sleep.

Re: [dpdk-stable] [PATCH] test: fix hang on FreeBSD

[Radu Nicolau]

On 5/21/2018 1:30 PM, Thomas Monjalon wrote:
> 21/05/2018 13:35, Radu Nicolau:
>> Fixes: af75078fece3 ("first public release")
>> Cc: stable@dpdk.org
>>
>> Signed-off-by: Radu Nicolau <radu.nicolau@intel.com>
>> ---
>> @@ -34,7 +34,8 @@ test_panic(void)
>>   		printf("Fork Failed\n");
>>   		return -1;
>>   	}
>> -	wait(&status);
>> +	sleep(1);
>> +	waitpid(pid, &status, WNOHANG);
> Please give an explanation why you are adding this sleep.
>
To give a chance to the child process to complete before calling waitpid.

Re: [dpdk-stable] [PATCH] test: fix hang on FreeBSD

[Thomas Monjalon]

21/05/2018 14:58, Radu Nicolau:
> 
> On 5/21/2018 1:30 PM, Thomas Monjalon wrote:
> > 21/05/2018 13:35, Radu Nicolau:
> >> Fixes: af75078fece3 ("first public release")
> >> Cc: stable@dpdk.org
> >>
> >> Signed-off-by: Radu Nicolau <radu.nicolau@intel.com>
> >> ---
> >> @@ -34,7 +34,8 @@ test_panic(void)
> >>   		printf("Fork Failed\n");
> >>   		return -1;
> >>   	}
> >> -	wait(&status);
> >> +	sleep(1);
> >> +	waitpid(pid, &status, WNOHANG);
> > Please give an explanation why you are adding this sleep.
> >
> To give a chance to the child process to complete before calling waitpid.

One second in an unit test is a lot.

When I was asking for explanation, I mean usual explanations in commit message:
	- what is the issue
	- what is the root cause
	- what is the reasoning behind the fix

Re: [dpdk-stable] [dpdk-dev] [PATCH] test: fix hang on FreeBSD

[Stephen Hemminger]

On Mon, 21 May 2018 13:58:39 +0100
Radu Nicolau <radu.nicolau@intel.com> wrote:

> On 5/21/2018 1:30 PM, Thomas Monjalon wrote:
> > 21/05/2018 13:35, Radu Nicolau:  
> >> Fixes: af75078fece3 ("first public release")
> >> Cc: stable@dpdk.org
> >>
> >> Signed-off-by: Radu Nicolau <radu.nicolau@intel.com>
> >> ---
> >> @@ -34,7 +34,8 @@ test_panic(void)
> >>   		printf("Fork Failed\n");
> >>   		return -1;
> >>   	}
> >> -	wait(&status);
> >> +	sleep(1);
> >> +	waitpid(pid, &status, WNOHANG);  
> > Please give an explanation why you are adding this sleep.
> >  
> To give a chance to the child process to complete before calling waitpid.


Should not be necessary; waitpid does that.

Re: [dpdk-stable] [dpdk-dev] [PATCH] test: fix hang on FreeBSD

[Burakov, Anatoly]

On 21-May-18 12:35 PM, Radu Nicolau wrote:
> Fixes: af75078fece3 ("first public release")
> Cc: stable@dpdk.org
> 
> Signed-off-by: Radu Nicolau <radu.nicolau@intel.com>
> ---
>   test/test/test_debug.c | 3 ++-
>   1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/test/test/test_debug.c b/test/test/test_debug.c
> index faf2cf5..56fadce 100644
> --- a/test/test/test_debug.c
> +++ b/test/test/test_debug.c
> @@ -34,7 +34,8 @@ test_panic(void)
>   		printf("Fork Failed\n");
>   		return -1;
>   	}
> -	wait(&status);
> +	sleep(1);
> +	waitpid(pid, &status, WNOHANG);
>   	if(status == 0){
>   		printf("Child process terminated normally!\n");
>   		return -1;
> 

I'd be curious to see which specific problem you are addressing as well. 
FreeBSD hanging on abort is a known issue, and a workaround is already 
available:

http://dpdk.org/dev/patchwork/patch/40256/

FreeBSD doesn't really "hang" here, it just spends a looooooooooooooong 
time doing the core dump because FreeBSD, unlike Linux, doesn't ignore 
hugepage and zero-page anonymous memory for core dumps, resulting in it 
trying to dump the entire 128 gigabytes of VA space that we preallocate.

Setting resource limits will address the immediate issue, a more 
complete fix (some memory subsystem refactor) will be coming for 18.08.

-- 
Thanks,
Anatoly

Re: [dpdk-stable] [dpdk-dev] [PATCH] test: fix hang on FreeBSD

[Radu Nicolau]

On 5/21/2018 2:28 PM, Burakov, Anatoly wrote:
> On 21-May-18 12:35 PM, Radu Nicolau wrote:
>> Fixes: af75078fece3 ("first public release")
>> Cc: stable@dpdk.org
>>
>> Signed-off-by: Radu Nicolau <radu.nicolau@intel.com>
>> ---
>>   test/test/test_debug.c | 3 ++-
>>   1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/test/test/test_debug.c b/test/test/test_debug.c
>> index faf2cf5..56fadce 100644
>> --- a/test/test/test_debug.c
>> +++ b/test/test/test_debug.c
>> @@ -34,7 +34,8 @@ test_panic(void)
>>           printf("Fork Failed\n");
>>           return -1;
>>       }
>> -    wait(&status);
>> +    sleep(1);
>> +    waitpid(pid, &status, WNOHANG);
>>       if(status == 0){
>>           printf("Child process terminated normally!\n");
>>           return -1;
>>
>
> I'd be curious to see which specific problem you are addressing as 
> well. FreeBSD hanging on abort is a known issue, and a workaround is 
> already available:
>
> http://dpdk.org/dev/patchwork/patch/40256/
>
> FreeBSD doesn't really "hang" here, it just spends a 
> looooooooooooooong time doing the core dump because FreeBSD, unlike 
> Linux, doesn't ignore hugepage and zero-page anonymous memory for core 
> dumps, resulting in it trying to dump the entire 128 gigabytes of VA 
> space that we preallocate.
>
> Setting resource limits will address the immediate issue, a more 
> complete fix (some memory subsystem refactor) will be coming for 18.08.
>

So it seems my "fix" only hides the issue and doesn't actually fix 
anything - so I will remove it from patchwork