Hi Marcel, On Thu, Nov 14, 2013, Marcel Holtmann wrote: > >> Following is an issue encountered and handled using bluez-5.10 on a > >> 32bit Tizen 2.0 IVI based distribution. > >> > >> If malloc returns a random NULL bluetoothd exits with core dumped. > >> In this case we do the following: > >> -start bluetoothd, > >> -at a random malloc call from any library (*lib*.so*), a random NULL will be returned by bluetoothd with a ld_preloaded library. > >> > >> ~# LD_PRELOAD=/root/lib_wrapper.so /usr/libexec/bluetooth/bluetoothd -E > >> > >> Analyzing the dump, it points directly to a DBUS_ERROR_NO_MEMORY > >> which, after handling, keeps bluetoothd from dumping and allowing > >> it to return the fatal error occurred as exit status, thus failing > >> gracefully. > >> > >> A fix proposal, handling the use-case is attached. > > > > Im afraid if we start treating all the out of memory cases we wont > > have time to do anything else, and quite frankly if this happens for > > real the least concern would be bluetoothd, so I believe we should > > just treat OOM cases as unrecoverable. Since this can happen with any > > dbus_error, I would probably suggest to wrap it perhaps we a > > g_dbus_error API that does assert in OOM. > > I am fine with fixing obvious ones. However long-term these tiny sized > memory allocation must just abort the program if we run out of memory. > Since there is no recovery from it anyway. Did you actually take a look at the patch? It's not exactly fixing any missing error checks but only modifying the behavior if the error is OOM by not doing a g_printerr call in that case. However, the main() function still does an error() call when connect_dbus() returns failure (even if it's -ENOMEM) so I don't really see how this particular patch would fix any obvious OOM handling issue. Johan -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
