GNOME Bugzilla – Bug 568760
nautilus freezes due to a bug in garray.c:322
Last modified: 2010-04-20 13:41:49 UTC
Under certain conditions garray.c:g_nearest_pow may enter an infinite loop. 316 static gint 317 g_nearest_pow (gint num) 318 { 319 gint n = 1; 320 321 while (n < num) 322 n <<= 1; 323 324 return n; 325 } when called with log_2(num) > 30 the while condition is never meet, thus producing an infinite loop. -- Program received signal SIGINT, Interrupt.
+ Trace 211779
Thread 3064772384 (LWP 6554)
Created attachment 127038 [details] [review] sanity check added
Created attachment 151338 [details] [review] Properly tested patch This patch adds the check to the loop - and also in a more maintainble shape (read: easier to understand for people unfamiliar with this bug). It also adds a testcase for the bug, so we're unlikely to introduce that bug again.
Looks good, please commit to the stable branch as well.
Committed. Master: http://git.gnome.org/browse/glib/commit/?id=7448eb71c3ac85a08c8f0fceaf9747e6298ae5c9 glib-2-22: http://git.gnome.org/browse/glib/commit/?h=glib-2-22&id=4eef1b6783393cdea71a8d7dabd8370184649078
Hey Sven, unfortunately, I am seeing your test fail (on x86_64): GLib-ERROR **: gmem.c:175: failed to allocate 2147483648 bytes aborting... ** ERROR:array-test.c:118:array_large_size: child process (14390) of test trap failed unexpectedly Aborted (core dumped)
(In reply to comment #5) > unfortunately, I am seeing your test fail (on x86_64): > > GLib-ERROR **: gmem.c:175: failed to allocate 2147483648 bytes > aborting... > ** > ERROR:array-test.c:118:array_large_size: child process (14390) of test trap > failed unexpectedly > Aborted (core dumped) Too bad. Is there a way to inject a custom allocation function into glib? Allocating 2GB of memory isn't that useful indeed. I'll check if I can reduce the test to something less memory-extensive (like using char in GArray instead of gpointer via GPtrArray -- this should reduce the allocation from 2GB to 256MB at least).
Created attachment 152311 [details] [review] Patch fixing the test case Here's a patch that should let the test pass, even if the memory allocation failed. Can you please test this patch, Matthias?
Yes, you can use g_mem_set_vtable to replace the malloc implementation. I'll test your patch anyway, thanks.
(In reply to comment #8) > Yes, you can use g_mem_set_vtable to replace the malloc implementation. > > I'll test your patch anyway, thanks. Any results?
nah, forgotten. sorry added to todo list now
doesn't build: array-test.c: In function ‘array_large_size’: array-test.c:118: error: void value not ignored as it ought to be make: *** [array-test.o] Error 1
Created attachment 152921 [details] [review] patch fixing the test case v2 Narf, sorry. This one should compile.
Thanks, this works.
The test fails for me because the timeout is too low. I suspect bug 610784 and bug 613060 fail because of that too. Maybe they should be marked as dups Can we make the timeout higher? After all if the test finishes before it won't keep waiting but continue. Also making it not allocate 2GB of memory as comment 6 and 8 suggest would be nice.
(In reply to comment #14) > The test fails for me because the timeout is too low. I suspect bug 610784 and > bug 613060 fail because of that too. Maybe they should be marked as dups > > Can we make the timeout higher? After all if the test finishes before it won't > keep waiting but continue. > > Also making it not allocate 2GB of memory as comment 6 and 8 suggest would be > nice. This works for me. Feel free to use the information from comment 6 and comment 8 to provide patches that run faster and that don't require as much memory…