[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240913195418.GD10433@brightrain.aerifal.cx>
Date: Fri, 13 Sep 2024 15:54:19 -0400
From: Rich Felker <dalias@...c.org>
To: Lukas Zeller <luz@...n44.ch>
Cc: musl@...ts.openwall.com
Subject: Re: SIGSEGV/stack overflow in pthread_create - race condition?
On Fri, Sep 13, 2024 at 09:28:59PM +0200, Lukas Zeller wrote:
> Hi Rich,
>
> > On 13 Sep 2024, at 17:25, Rich Felker <dalias@...c.org> wrote:
> >
> > Why do you expect this is a race condition? The backtrace is not
> > sufficient to show it, but my default assumption would just be that
> > this is just a stack overflow in the application code, i.e. allocating
> > too much on the stack (in automatic storage local variables).
>
> Sorry, I might be mislead due to not really understanding the details.
>
> I thought of a race condition because it seems CPU execution time
> dependent - I can swap the SD card from an RPi2 where it never
> happens and libpagekit is in heavy use, and an Rpi3 or 4 where it
> happens in almost 100% of the startups of the pagekite app.
>
> But please see other message in reply to alice, I don't think this
> can be a regular stack overflow from the tests I did in the
> meantime.
Can you dump the disassembly (disasm command) at the point of crash?
That will show what's attempting to be accessed and what "type of
segfault" it is.
If there's an unpredictable crash, indeed it seems less likely to be
stack overflow. I don't see any way it could be a race condition on
musl's side but it could be one in the application/libpagekite code,
or it could be any sort of hardware or kernel fault.
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.
