[igt-dev] [PATCH i-g-t] runner/resultgen: Explain why json creation might have failed

[Petri Latvala]

On Tue, Jun 09, 2020 at 05:21:37PM +0300, Arkadiusz Hiler wrote:
> Sometimes creating the string representation fails. This usually happens
> when we have a huge logs (e.g.: something was spamming the dmesg) or the
> result generation was run on a very low-end system (e.g. embedded board
> with 256 megs of RAM).
> 
> Sadly json-c call returns us NULL and provides no explanation
> whatsoever. Let's fix a NULL pointer dereference in such cases and print
> a mesage that should help people make sense out of what have just
> happened.
> 
> Cc: Swati Sharma <swati2.sharma at intel.com>
> Cc: Petri Latvala <petri.latvala at intel.com>
> Signed-off-by: Arkadiusz Hiler <arkadiusz.hiler at intel.com>
> ---
>  runner/resultgen.c | 13 +++++++++++++
>  1 file changed, 13 insertions(+)
> 
> diff --git a/runner/resultgen.c b/runner/resultgen.c
> index add4aad5..e2e162b0 100644
> --- a/runner/resultgen.c
> +++ b/runner/resultgen.c
> @@ -1661,6 +1661,19 @@ bool generate_results(int dirfd)
>  	}
>  
>  	json_string = json_object_to_json_string_ext(obj, JSON_C_TO_STRING_PRETTY);
> +
> +	if (json_string == NULL) {
> +		fprintf(stderr, "resultgen: Failed to create json representation of the results.\n");
> +		fprintf(stderr, "           This usually means that the results are too big\n");
> +		fprintf(stderr, "           to fit in the memory as the text representation\n");
> +		fprintf(stderr, "           is being created.\n\n");
> +		fprintf(stderr, "           Either something was spamming the logs or your\n");
> +		fprintf(stderr, "           system is very low on free mem.\n");
> +
> +		close(resultsfd);
> +		return false;
> +	}
> +


There are some obvious arguments that can be made here so I'll tackle
them myself:

"Why not use the serializer function in json-c that directly outputs
to a file?"

That function is implemented with a call to
json_object_to_json_string_ext(). No gain here.

"Why not try to fall back to JSON_C_TO_STRING_PLAIN for a shorter
string result?"

A reasonable argument, but offers very little hope. If we reach this
case it's a heck of a long string as one of the logs and reducing the
overhead of the prettifying won't help much relatively.

An option to limit the disk space usage of a test is in the works and
that will help tackle the root cause of this happening. I assert that
no one really believes it's normal for a single test to log multiple
gigabytes.


Reviewed-by: Petri Latvala <petri.latvala at intel.com>