{"action":"created","issue":{"url":"https://api.github.com/repos/radarsat1/liblo/issues/69","repository_url":"https://api.github.com/repos/radarsat1/liblo","labels_url":"https://api.github.com/repos/radarsat1/liblo/issues/69/labels{/name}","comments_url":"https://api.github.com/repos/radarsat1/liblo/issues/69/comments","events_url":"https://api.github.com/repos/radarsat1/liblo/issues/69/events","html_url":"https://github.com/radarsat1/liblo/issues/69","id":379669890,"node_id":"MDU6SXNzdWUzNzk2Njk4OTA=","number":69,"title":"Potential race condition in lo_server_next_event_delay ?","user":{"login":"tuscland","id":556316,"node_id":"MDQ6VXNlcjU1NjMxNg==","avatar_url":"https://avatars3.githubusercontent.com/u/556316?v=4","gravatar_id":"","url":"https://api.github.com/users/tuscland","html_url":"https://github.com/tuscland","followers_url":"https://api.github.com/users/tuscland/followers","following_url":"https://api.github.com/users/tuscland/following{/other_user}","gists_url":"https://api.github.com/users/tuscland/gists{/gist_id}","starred_url":"https://api.github.com/users/tuscland/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/tuscland/subscriptions","organizations_url":"https://api.github.com/users/tuscland/orgs","repos_url":"https://api.github.com/users/tuscland/repos","events_url":"https://api.github.com/users/tuscland/events{/privacy}","received_events_url":"https://api.github.com/users/tuscland/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":3,"created_at":"2018-11-12T08:32:06Z","updated_at":"2018-11-30T21:38:47Z","closed_at":null,"author_association":"CONTRIBUTOR","body":"Hello,\r\n\r\nI am using a fairly recent code base (2 commits behind master).\r\nA user using TouchDesigner on a Mac Pro reported a crash which seems related to liblo. Looking at the crash, I infer that there is a race condition, though I may be wrong.\r\n\r\nThe crash is a segmentation fault in `lo_server_next_event_delay`:\r\n\r\n```\r\nException Type:  SIGSEGV\r\nException Codes: SEGV_MAPERR at 0x0\r\n\r\nThread 7 Crashed:\r\n0    0x00000001049b814d lo_server_next_event_delay (server.c:1876)\r\n1    0x00000001049b80cd lo_servers_wait (server.c:1448)\r\n2    0x00000001049b7d50 lo_server_wait (server.c:1350)\r\n\r\n```\r\n\r\nLooking at `server.c` at line 1876:\r\n```C\r\n    if (s->queued) {\r\n        lo_timetag now;\r\n        double delay;\r\n\r\n        lo_timetag_now(&now);\r\n->      delay = lo_timetag_diff(((queued_msg_list *) s->queued)->ts, now);\r\n```\r\n\r\n... while another thread runs `dispatch_method`.\r\n\r\nMy interpretation is that something is null. The server is running so it can't be `s`. If it was `s->queued->ts`, the crash would occur in `lo_timetag_diff`. So it must be `s->queued`, but the `if` statement before checks for this condition, so something must change between the condition and the crash location.\r\n\r\nI can see `dispatch_queued` modifies `s->queued` while `lo_servers_wait` read it (using `lo_server_next_event_delay`).\r\n\r\nI am not sure if this is the problem and how to solve it. \r\nAny idea?\r\n\r\nThanks for your help!"},"comment":{"url":"https://api.github.com/repos/radarsat1/liblo/issues/comments/443347502","html_url":"https://github.com/radarsat1/liblo/issues/69#issuecomment-443347502","issue_url":"https://api.github.com/repos/radarsat1/liblo/issues/69","id":443347502,"node_id":"MDEyOklzc3VlQ29tbWVudDQ0MzM0NzUwMg==","user":{"login":"tuscland","id":556316,"node_id":"MDQ6VXNlcjU1NjMxNg==","avatar_url":"https://avatars3.githubusercontent.com/u/556316?v=4","gravatar_id":"","url":"https://api.github.com/users/tuscland","html_url":"https://github.com/tuscland","followers_url":"https://api.github.com/users/tuscland/followers","following_url":"https://api.github.com/users/tuscland/following{/other_user}","gists_url":"https://api.github.com/users/tuscland/gists{/gist_id}","starred_url":"https://api.github.com/users/tuscland/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/tuscland/subscriptions","organizations_url":"https://api.github.com/users/tuscland/orgs","repos_url":"https://api.github.com/users/tuscland/repos","events_url":"https://api.github.com/users/tuscland/events{/privacy}","received_events_url":"https://api.github.com/users/tuscland/received_events","type":"User","site_admin":false},"created_at":"2018-11-30T21:38:47Z","updated_at":"2018-11-30T21:38:47Z","author_association":"CONTRIBUTOR","body":"Thank you for the pointers.\r\n\r\nOn macOS (CoreFoundation actually), runloop sources (ways to integrate with a run loop, more specifically here the main loop) are kind of lazy. The OS schedules calls to the loop in the most efficient manner. So, I am not guaranteed that `lo_server_recv_noblock` will be called as soon as there is something on the socket, which cause unwanted delays.\r\n\r\nI could try the mutex, but I remember the performance was not so great, obviously.\r\n\r\nAlso, I think I already tried to register the lo_server's socket with the main runloop source, but had problems of socket configuration compatibility between liblo and CoreFoundation.\r\n\r\nShall I close this issue, or is it still a valid use-case?"}}
{"actor":{"display_login":"tuscland"}}