Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Crashes with "API function called from within callback" #40

Closed
jcharaoui opened this issue Aug 30, 2019 · 7 comments
Closed

Crashes with "API function called from within callback" #40

jcharaoui opened this issue Aug 30, 2019 · 7 comments
Labels
bug Something isn't working regression

Comments

@jcharaoui
Copy link
Collaborator

jcharaoui commented Aug 30, 2019

I tagged 1.1.8 and readied a package for upload. Before sending the package to the archive I always test it. After a few minutes of streaming a MKV movie file, I get this crash:

transfer_blocking(): 8, API function called from within callback

This happened 3 times back to back with different video files.

The mount was configured with default settings (no cache).

@jcharaoui jcharaoui added the bug Something isn't working label Aug 30, 2019
@fangfufu
Copy link
Owner

fangfufu commented Aug 30, 2019

Could you give me access to that server and that MKV file, please? Could you also let me know which program you used to play that MKV file, please? Please feel free to send me an email at [email protected], if you don't fancy sending me anything in public.

I am going to investigate it later this evening.

@fangfufu
Copy link
Owner

fangfufu commented Aug 30, 2019

Okay, can you run it with -f, and give me the full log please? I can't reproduce it, but I have a good idea what might have caused it. The same file segment might have been requested twice by two different threads. Edit: The problem happens when a libcurl handle is added when a transfer task is already running! I had to dig into libcurl's source code to get what's going on! It is once again a multithreading problem!

@jcharaoui , could you reproduce this problem in the older version? I wonder why it didn't show up before.

@jcharaoui
Copy link
Collaborator Author

@fangfufu I'll send you a full log with -f ASAP. I'm positive this never happened with the current Debian version, 1.0.1. We'd have to bisect the repository to see which commit introduced the problem.

fangfufu added a commit that referenced this issue Aug 31, 2019
curl handles should NOT be added when there are transfers going on!!!
@fangfufu
Copy link
Owner

I believe I have solved the problem in commit d6fbcb4.

If you look at the code in v1.0.1, curl handles would not have been added when transfers are happening, due to the mutexes.

httpdirfs/src/network.c

Lines 271 to 273 in 527cad6

pthread_mutex_lock(&transfer_lock);
CURLMcode res = curl_multi_add_handle(curl_multi, curl);
pthread_mutex_unlock(&transfer_lock);

I removed those mutexes, because I thought they weren't needed. They only occasionally show up, because it is one of those concurrency bug...

@fangfufu
Copy link
Owner

Right, I am confident this is resolved. I have updated the changelog, Makefile, tagged a new version, and created a new release. Feel free to close the issue once you tested it out.

@fangfufu
Copy link
Owner

Okay, I cannot reproduce the exact bug in 1.1.8, even after the trying to use your server. However, I can confirm that 1.1.8 hangs when there are multiple simultaneous I/O requests. I basically ran three instances of pv $VIDEO_FILENAME > /dev/null, 1.1.8 hangs after like 5 minutes. 1.1.9 works fine.

Previously in order to test my code, I mounted Debian CD image server, ran one instance of cat $ISO_FILENAME > /dev/null, it worked fine. So I thought my code worked fine.

I guess in future we need to come up with a more comprehensive testing regime.

@fangfufu
Copy link
Owner

This bug is definitely resolved.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working regression
Projects
None yet
Development

No branches or pull requests

2 participants