On 24-8-2016 18:26, Adam C. Emerson wrote: > On 24/08/2016, Sage Weil wrote: > [snip] >> This is appealing, except: >> >>>> Note that using the system assert isn't a total disaster: system >>>> assert will trigger an abort, which will trigger the SIGABRT handler >>>> which *also* dumps a stack trace to the debug log. The problem is >>>> that it doesn't show the assertion condition and line number. > [snip] >> I think not getting the assertion condition and line number in the >> ceph log is a deal breaker. > > We should be able to get the condition and line number in the log, > they're passed to __assert_fail() so we could pass them to > ceph_assert_fail (see the commit that Casey linked to.) > > I can see arguments either way, the main one I would make AGAINST this > approach is that it makes portability/building more complicated. I'd go for the full deal. The big advantage of doing it yourself is that you are in full control. And certainly not dependent on any system code that does the trick slightly different. I had already a hard time getting FreeBSD and Linux in line over a simple thing as ENODATA == ENOATTR. And this sounds way much more complicated. It might be a lot of changes, but for the first step I guess you can sort of automate it with perl -pni.bak 's/assert\(/ceph_assert\(/g;' \ `find src -name \*.c -o -name \*.cc` and then get the refinements in when people pass by in files an know the priorities. --WjW -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
