From: shyouhei@... Date: 2016-09-23T10:28:46+00:00 Subject: [ruby-core:77369] [Ruby trunk Bug#12685][Feedback] malloc error: pointer being freed was not allocated Issue #12685 has been updated by Shyouhei Urabe. Status changed from Open to Feedback Yes, it sounds serious. But so far I'm not successful in reproducing the error. Can you show us a bit more detailed instruction how to actually see this bug on my machine? ---------------------------------------- Bug #12685: malloc error: pointer being freed was not allocated https://bugs.ruby-lang.org/issues/12685#change-60614 * Author: Eike Dierks * Status: Feedback * Priority: Normal * Assignee: * ruby -v: ruby 2.3.1p112 (2016-04-26 revision 54768) [x86_64-darwin15] * Backport: 2.1: UNKNOWN, 2.2: UNKNOWN, 2.3: UNKNOWN ---------------------------------------- ruby crashed - never seen that before - should never happen - looks serious to me I'm using ruby 2.3.1p112 (2016-04-26 revision 54768) [x86_64-darwin15] from macports I was running rails in dev mode. The bug happened while reloading a page (like we all do a thousand times a day) Error message in the shell was: (12416,0x70000071a000) malloc: *** error for object 0x1c7fdde49ddcc0: pointer being freed was not allocated See the dump attached. This might either be a very serious bug, or a bug in my hardware. I must admit that I did see a sign that might point to me having a faulty RAM. (a wrong rendering in a window's backing store) But that was in EyeTV (a wrong rendering in a window's backing store) (It is well known that EyeTV is a very buggy C++ software) So I assume that having these two bugs within two days might be more of an conincidence (and not caused by faulty ram) So this might be a false alarm, but maybe it is not: Please look at the backtrace, it crashed in: 6 libruby.2.3.0.dylib 0x0000000109da0b23 obj_free + 684 7 libruby.2.3.0.dylib 0x0000000109da049a gc_sweep_step + 473 8 libruby.2.3.0.dylib 0x0000000109d9f61a newobj_slowpath + 374 9 libruby.2.3.0.dylib 0x0000000109d9f484 newobj_slowpath_wb_protected + 20 10 libruby.2.3.0.dylib 0x0000000109d53177 ary_new + 66 11 libruby.2.3.0.dylib 0x0000000109d5d7fe flatten + 77 12 libruby.2.3.0.dylib 0x0000000109d5afd4 rb_ary_flatten_bang + While a faulty bit could crash it anywhere (and this must be a heavily exercised routine) Please forget about faulty bits and alpha particles (my machine is running perfectly stable) It might actually be a software bug in the gc. I fear this will be hard to reproduce, but maybe the stack trace might help you. I believe this to be a software bug in the gc (which is very serious) (please read the trace) ---Files-------------------------------- malloc_free_bug_backtrace.txt (43.9 KB) -- https://bugs.ruby-lang.org/ Unsubscribe: