May be erroneous free in the io_curl.c's read_from_buffer()

Submitted by mattli on Sun, 2014-04-27 01:39

Forums:

Hi,
I noticed a small chance of free problem in the "io_curl.c:
write_callback() relloc "s->curl.buf", memcpy after change the var "s->curl.buf_fill".
but other thread is checking "s->curl.buf_fill" var.
Is it may cause erroneous free in the read_from_buffer() in the code "free (s->curl.buf)"?

Matt.

jcf

Sun, 2014-04-27 06:30

After a quick look (which is all I have time for tonight) you may well be right, Matt. I'll take a more detailed look tomorrow.

In the meantime, if you wanted to look deeper:

  • Try running MOC under Valgrind with a cURL stream to see if it complains. Introducing a usleep(3) in write_callback() between the two relevant statements might improve the chance of triggering the problem.
  • Can you see whether this might cause MOC to play the same stream data more than once. If so, it might provide an answer to this long-running problem. (I suspect not as the decoder would not be receiving a valid stream, but it may be triggering repeated output by the decoder somehow.)

jcf

Sat, 2014-06-21 23:58

I am still working on this problem, and in the process of doing so I have identified several other race conditions which appear to account for a small collection of unsolved historic problems. I believe I know the fix for these, but getting it right is going to require a bit of work.

jcf

Mon, 2014-07-07 02:00

After much painstaking desk checking, I've determined that there is no data race here as both write_callback() and read_from_buffer() are only ever reached from io_read_thread() and therefore can never conflict because of being in the same thread. I would have liked "mattli" to double check my findings, but he has failed to respond to my e-mail. Thanks, however, to user "alex" who did take the time to check and agrees that my conclusion is correct.

The other potential data race conditions identified while debugging this one are still being investigated.