Page MenuHomePhabricator

Valgrind warnings and a undefined double
Open, NormalPublic

Description

The attached valgrind file is what i get when i start the extra app with valgrind.
One of the problems seems to be that the double value which gets to the download_cb is uninitializied. which leads to the problem that Nan is displayed and valgrinds prints warnings about the double value not initializied. (the backtraces with _download_progress_cb in them)

bu5hm4n created this task.Jan 3 2017, 3:32 AM
bu5hm4n updated the task description. (Show Details)
stefan_schmidt triaged this task as Normal priority.Feb 10 2017, 7:03 AM

Could you re-run the tests and provide more information, my analysis is:

  • _download_progress_cb (extra_main.c:222) is called from _efl_ui_image_remote_copier_progress() (btw it's using a different struct, happens to be the same layout, but this is incorrect).
  • _efl_ui_image_remote_copier_progress() calls _efl_io_copier_progress_get() with the copier that originated the progress as event->object, thus that must be valid and an Efl.Io.Copier object.
  • _efl_io_copier_progress_get() simply set the pointers to the pd values. These are always valid as Eo starts pd as zeroed memory.
  • _efl_io_copier_source_size_apply() is called for sources that implements sizer interface, which HTTP does.
  • _efl_net_dialer_http_efl_io_sizer_size_get() for download will call _efl_net_dialer_http_request_content_length_get()
  • _efl_net_dialer_http_request_content_length_get() will simply return pd->request.content_length which is initialized to zero by Eo or when HTTP headers are done with the value returned by curl_easy_getinfo(pd->easy, CURLINFO_CONTENT_LENGTH_DOWNLOAD, &d);, with the return code being checked for errors -- in this case we had no error, thus d must be set to something valid.

What may happen is that total may be zero if the source doesn't report a size, for example a stream or an HTTP server that doesn't report Content-Length: XXXX. Could that be the reason for your problem, server not returning XXXX and total being 0?

Alternatively, could you check if initializing double d = -1.0;' inside efl_net_dialer_http.c:728 _efl_net_dialer_http_headers_done()` "solves" it?

I'm worried that curl is simply failing and returning success CURLE_OK... in that case I must hunt all curl_easy_getinfo() and always give initialized values :-/

okay, i checked with double d = -1.0; doesnt fix it :(

tested with https also happens with it ...

weird, how can that be? We do pass the expected pointer (double, checked the non-wrapped/dlopened shim header), code/enum seems to match, so how is it generating garbage?

One more test: get libcurl-dbg (or similar package, or compile from sources with -ggdb3) and put a print right after the curl_easy_getinfo() to force reading the value, see if it bitches about invalid memory and if it hints on the "X bytes after 0xaabbccdee written by curl"

zmike edited projects, added Restricted Project; removed efl.Jun 11 2018, 6:58 AM
zmike edited projects, added efl: networking; removed Restricted Project.Jun 11 2018, 9:33 AM
zmike added a subscriber: zmike.Jan 17 2019, 10:36 AM

@bu5hm4n is this still an issue?