Hi Luiz, >> 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. Regards Marcel -- 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
