godot: ERROR: store_buffer: Condition ' !p_src ' is true when doing some operations.

Godot version: 3.2.beta.custom_build. 157246ae8 OS/device including version: Ubuntu 19.10 Issue description:

Using null buffer pointer in fwrite function is Undefinied Behaviour

size_t fwrite(
   const void *buffer,
   size_t size,
   size_t count,
   FILE *stream
);

and this cause this error

ERROR: store_buffer: Condition ' !p_src ' is true.
   At: drivers/unix/file_access_unix.cpp:278.

It can be easily silenced but probably this is not the best solution

Steps to reproduce:

  1. Download “FirstPersonStarter” from Template in Project Manager

https://github.com/godotengine/godot/blob/24e1039eb6fe32115e8d1a62a84965e9be19a2ed/scene/main/http_request.cpp#L358 2. Import GLTF File Katalog bez nazwy.zip

https://github.com/godotengine/godot/blob/dec10dd776fca2994277faa3a97b13e70317f784/core/io/resource_format_binary.cpp#L1538

About this issue

  • Original URL
  • State: closed
  • Created 5 years ago
  • Reactions: 1
  • Comments: 30 (12 by maintainers)

Commits related to this issue

Most upvoted comments

The fix is simple:

diff --git a/drivers/unix/file_access_unix.cpp b/drivers/unix/file_access_unix.cpp
index ec23df62d0..6ea55219bb 100644
--- a/drivers/unix/file_access_unix.cpp
+++ b/drivers/unix/file_access_unix.cpp
@@ -264,7 +264,7 @@ void FileAccessUnix::store_8(uint8_t p_dest) {

 void FileAccessUnix::store_buffer(const uint8_t *p_src, uint64_t p_length) {
        ERR_FAIL_COND_MSG(!f, "File must be opened before use.");
-       ERR_FAIL_COND(!p_src);
+       ERR_FAIL_COND(!p_src && p_length > 0);
        ERR_FAIL_COND(fwrite(p_src, 1, p_length, f) != p_length);
 }
 

Cf. #49394.

For what it’s worth, the errors are harmless, it’s just noise. It errors on code that tries to store a non-existent buffer of size 0… which doesn’t need to be an error, it will just not do anything.

get_body_size also works when running the same code and requesting the same file from the same server on the android exported version of the game

HTTPRequest.get_body_size() returns -1 instead of the actual file size.

This is expected with some file hosts such as GitHub because they don’t report the body size for files that were generated on-the-fly (such as ZIP archives). In this situation, you will get the body size if you try downloading the same file a second time in a short enough interval.

That’s generally true, but in my case these are the same specific files of which get_body_size() returns the actual size when exporting with Godot v3.2.3 but not when exporting with v3.3.

I am also having this same problem. It worked in version 3.2.3 and in version 3.3 the function get_body_size () always returns -1 in the same file and server that returned correctly in the version exported with 3.2.3. Does anyone have any fix or workaround for this? I used this function to show a progress bar.

var download_url = 'https://myawsserver.com/game.pck'
var download_destination = "user://game.pck"
download_request = HTTPRequest.new()
add_child(download_request)
# download_request.download_chunk_size = 65535;
download_request.download_file = download_destination
download_request.connect("request_completed", self, "_http_request_completed")
var error = download_request.request(download_url)

func _process(_delta):
  if download_request:
    var size = download_request.get_body_size()
    if size > 0:
      var done = float(download_request.get_downloaded_bytes()) / size

I have full access to the server (AWS) and the file. Is there any configuration that can solve this?

File is a pck with about 20Mb. File is downloaded correctly, buy progress bar stoped working

My code is the above one.

  • file is a godot game (only pck)
  • host is in a amazon instance (s3)
  • webserver is python tornado
  • http exported game and files are stored in the same place/server/instance
  • file is always downloaded correctly
  • get_body_size works when running from the engine editor

For me the error of httprequet.get_body_size () returning -1 always happens in version 3.3 (and 3.3.2)

This function returns the correct value in version 3.2.3 when downloading the same file, on the same server in the same game

but progress bar stoped working @dpensky

It’s probably not working because the server on the other end is responding with -1 as the content length.

If you could make a small repo to test that it would help narrow down the issue a lot!