No output logs in fw-download

[JohnGoogl]

Hi Team,
While checking fw-download case, for invalid file size case it failed as expected with respective log,
but, for valid file size case, its not showing any logs about command operation like success/failure.
And, after fw-download call for 'echo $?' command its printing '1' which tells non-positive with fw-download operation.

I tried with options like #progress(-p) #verbose(-v), but no luck in logs display. Any thoughts on this pls?

BR, Paul

[ikegami-t]

Could you please try the PR #2337 changes to make sure since the echo $? output 1 caused by the error return as below and also only the memory allocation error does not output any message? The change is just for the error message output so the error itself not resolved.

int main(int argc, char **argv)
{
...
	err = handle_plugin(argc - 1, &argv[1], nvme.extensions);
	if (err == -ENOTTY)
		general_help(&builtin);

	return err ? 1 : 0;

[Daniel Wagner]

I don't think it is a ENOMEM situation. And if so, then the print out of 'no mem' is highly likely to fail too, because printing also is involving allocation. I've just merged a feature which enables low level logging for all commands. So if you could try with the current libnvme and nvme-cli master and use -vvv we should hopefully see a bit more.

[ikegami-t]

Is it really memory allocated by the print API function? As far as checked the printf source code and strace logging seems not allocate the memory by the print function. But as you mentioned json print function allocates memory as mentioned so just fix the PR #2337 patch to not output as json print but only stderr print. Also as far as checked the command implementation if libnvme returned any error the error message output so for -vvv seems still no log message output I think. By the way looks we can debug the issue by using the strace command as strace nvme fw-download /dev/nvme0 ....

[Daniel Wagner]

You are likely not to observe any memory allocation with strace, because glibc uses buffers for streams.

[ikegami-t]

printf() and fprintf() call __vfprintf_internal() (seems implemented as vfprintf()) and vfprintf() uses the buffer as below so is this failed if a ENOMEM situation?
https://codebrowser.dev/glibc/glibc/stdio-common/vfprintf-internal.c.html#1554

  /* Set up the wrapping buffer.  */
  struct Xprintf (buffer_to_file) wrap;
  Xprintf (buffer_to_file_init) (buf: &wrap, fp: s);

Now I am thinking to close the PR #2337 but to make sure if possible I would like to confirm the detail if really highly likely to fail.

[Daniel Wagner]

How a C library implements these APIs is undefined. Embedded libc libraries usually try to hard to avoid to have dynamic allocation wherever possible. I haven't look at the glibc implementation (not it would help, their coding style is from another planet) but I would be very surprised if it would use a buffered implementation. So the question is, are you sure the buffer is not resized when we try to print 'no memory'?

A quick test shows we have a hidden allocation when using printf:

$ cat test.c
#include <stdio.h>

int main(int argc, char *argv[])
{
        printf("there you go\n");

        return 0;
}

$ memusage ./test
there you go

Memory usage summary: heap total: 1024, heap peak: 1024, stack peak: 0
         total calls   total memory   failed calls
 malloc|          1           1024              0
realloc|          0              0              0  (nomove:0, dec:0, free:0)
 calloc|          0              0              0
   free|          0              0
Histogram for block sizes:
 1024-1039            1 100% ==================================================

[Daniel Wagner]

@JohnGoogl could you share you command line and output. Also which version of nvme-cli are you using?

[Daniel Wagner]

No feedback. Let's close it. If it still a problem, reopen and please provide the info. Thanks.