Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20181207211212.GJ23599@brightrain.aerifal.cx>
Date: Fri, 7 Dec 2018 16:12:12 -0500
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: aio_cancel segmentation fault for in progress write
 requests

On Fri, Dec 07, 2018 at 09:35:32PM +0100, Markus Wichmann wrote:
> On Fri, Dec 07, 2018 at 01:13:44PM -0600, A. Wilcox wrote:
> > So, my best theory is that running inside a debugger (gdb, valgrind)
> > makes it slow enough that it no longer races.
> 
> Two ideas to investigate further. 1: Produce a coredump ("ulimit -c
> unlimited"). That won't interfere with timing, but I have no clue if
> coredumps work with multithreading.
> 
> 2: Might I suggest installing a SIGSEGV handler? If you have libunwind,
> you can create a backtrace from inside the handler. And even if not, you
> can at least print the exception PC, which would help a ton already.
> 
> Only, don't return from that handler. Either _exit(), or better yet,
> restore the default handler, then kill yourself with SIGSEGV.

The signal handler will not work if the problem is stack overflow on
the io thread. It runs with all signals blocked, and would need a
sigaltstack to have space to run anyway, but there's nowhere to
install a sigaltstack for the io thread.

Rich

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.