libdispatch-dev

Download

libdispatch-dev@lists.macosforge.org

April 2012

3 participants
2 discussions

Memory issues with libdispatch
by Aldrin Martoq Ahumada 30 Apr '12

30 Apr '12

Hi, I have been testing sample code from the wiki and found that libdispatch is alloc'ing a lot of memory without releasing it, both in OS X (Lion 10.7.3, Xcode 4.3.2) and Linux (manually compiled and installed). The code creates a SIGHUP signal source, with a handler that calls 100_000 writes to a logfile. The write to a log is queued in a serial queue. The first run shows normal memory usage (8-9 MiB both Linux and OS X). After sending a "kill -1 <pid>" memory usage increases 1-20MiB every time I send the SIGHUP signal. I have tried compiling with -fobj-arc and without it, but the result is the same. I removed the NSString usage in the br_log function, but the leak is not there: it is somewhere inside libdispatch. I tried both valgrind and Xcode Instruments, but no leaks are found. Thanks in advance, ---- ini ---- // // main.m // test02 // // Created by Aldrin Martoq on 4/29/12. // Copyright (c) 2012 __MyCompanyName__. All rights reserved. // #include <unistd.h> #import <Foundation/Foundation.h> #import <dispatch/dispatch.h> static FILE *log_file = NULL; static NSString *log_filename = @"/tmp/br.log"; static dispatch_queue_t log_queue; void br_log(NSString *format, ...) { @autoreleasepool { va_list ap; va_start(ap, format); NSString *s = [[NSString alloc] initWithFormat:format arguments:ap]; va_end(ap); if (log_file == NULL) { log_queue = dispatch_queue_create("cl.martoq.log_queue", NULL); log_file = fopen([log_filename cStringUsingEncoding:NSUTF8StringEncoding], "a"); NSLog(@"Log file created: %@", log_filename); } dispatch_async(log_queue, ^{ @autoreleasepool { const char *c = [s cStringUsingEncoding:NSUTF8StringEncoding]; fputs(c, log_file); fputs("\n", log_file); fflush(log_file); [s release]; } }); } } void br_setup() { signal(SIGHUP, SIG_IGN); dispatch_source_t sig_src = dispatch_source_create(DISPATCH_SOURCE_TYPE_SIGNAL, SIGHUP, 0, dispatch_get_main_queue()); dispatch_source_set_event_handler(sig_src, ^{ dispatch_async(dispatch_get_main_queue(), ^{ printf("Caught SIGHUP\n"); for (int i = 0; i < 100000; i++) { br_log(@"prueba: %d", i); } }); }); dispatch_resume(sig_src); } int main(int argc, const char * argv[]) { @autoreleasepool { // insert code here... NSLog(@"Hello, World!"); br_setup(); dispatch_main(); } return 0; } ---- fini ---- Aldrin Martoq A. http://aldrin.martoq.cl/

2 4

Question on race condition when using dispatch_group_notify_f
by Christopher Jones 02 Apr '12

02 Apr '12

To whom it may concern, I have found a race condition using the port of libdispatch from http://mark.heily.com/sites/mark.heily.com/files/libdispatch-f16-SRPMS.tgz. The race condition manifests when doing the equivalent of void run(void* iContext) { dispatch_group_t g = reinterpret_cast<dispatch_group_t>(iContext); dispatch_group_async_f(g, dispatch_get_global_queue(0, 0), g, do_work); dispatch_group_notify_f(g, dispatch_get_global_queue(0, 0), g, run); } The idea is to have a new 'run' task start up after the previous 'do_work' task has finished. However, with a system under heavy load I see that 'run' can be called before its instance of 'do_work' has finished. This happens because of a race condition in '_dispatch_group_wake' _dispatch_group_wake(dispatch_semaphore_t dsema) { struct dispatch_sema_notify_s *tmp; struct dispatch_sema_notify_s *head = (struct dispatch_sema_notify_s *)dispatch_atomic_xchg(&dsema->dsema_notify_head, NULL); ... while (head) { dispatch_async_f(head->dsn_queue, head->dsn_ctxt, head->dsn_func); _dispatch_release(head->dsn_queue); do { tmp = head->dsn_next; } while (!tmp && !dispatch_atomic_cmpxchg(&dsema->dsema_notify_tail, head, NULL)); free(head); head = tmp; } … } Under heavy load, the thread processing _dispatch_group_wake can be swapped out right after the first call to 'dispatch_async_f'. The task can then call 'run(void* iContext)' which can make it all the way to the end of that function thereby adding a new task to the tail of the dispatch_group. Once the '_dispatch_group_wake' thread reawakens, it now has a new entry in 'head->dsn_next' (since in dispatch_group_notify_f the 'head' and 'tail' refer to the same memory address for this problem). This new entry is processed which causes the 'run' to go off before the associated 'do_work' finishes. You can find a small test which can, usually, exhibit the error and cause an assert to fail http://dl.dropbox.com/u/11356841/raceCondition.cpp This test has succeeded in exhibiting the error for me when run on a 16 core (4CPUs with each CPU having 4 cores) machine under Scientific Linux 6 [which is derived from Red Hat Enterprise 6]. So my question is, is the idea of having dispatch_group_notify_f effectively call itself not a supported activity or is this a bug that should be fixed? Sincerely, Chris Dr Christopher Jones Fermi National Accelerator Laboratory cdj(a)fnal.gov

2 1