Recursive SIGSEGV question

[Jonathan Wakely]

On Thu, 28 Mar 2019 at 14:26, Jonny Grant <jg@jguk.org> 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.