On Thu, 28 Mar 2019 at 14:26, Jonny Grant <jg@xxxxxxxx> wrote: > > > > On 28/03/2019 11:52, Jonathan Wakely wrote: > > On Wed, 27 Mar 2019 at 23:47, Jonny Grant wrote: > >> I did wonder, as -fsanitize=address seems to inhibit the core dump that > >> is otherwise created by the abort() that appears to be called - is that > >> a known issue? > > > > Sorry for not thinking of this before you filed the bug report, but as > > I said there, the problem is probably not Asan but your settings. > > Check what ulimit -a shows for the max core file size, see what > > 'sysctl -a | grep kernel.core' shows and if appropriate check the > > MaxCrashReportsSize in /etc/abrt/abrt.conf > > > > So Asan isn't suppressing the core file, it's just making the address > > space larger (for the shadow memory it uses to track heap usage) and > > that causes a much larger core file, which your system then doesn't > > dump. > > > > Hi! > Thank you for your reply > > My system is on unlimited core size, so should be okay, 416G free..? > > Maybe at least the code that isn't outputting the core, could output the > reason. That's not done by GCC. > I wondered if Asan had overridden the abort() function? Maybe > Asan putting in an ABRT handler...? Nope, because if that was true I wouldn't get "Aborted (core dumped)" for asan-instrumented binaries, and I do get that, unless I change settings to disallow larger core files.
