Re: reentrant sprintf causes segmentation fault

[David Lawrence <dlaw at markforged dot com>]

Dear Craig,

Thank you very much for the explanation and pointer to the manual.
Indeed, the manual is quite clear on this topic and I'm embarrassed
that I missed it on my first reading. Sorry to waste your time with
this question :-)

Best regards,
David

On Fri, May 3, 2019 at 1:18 PM Craig Howland <howland@lgsinnovations.com> wrote:
>
> On 5/3/19 12:43 PM, David Lawrence wrote:
> > Dear newlib maintainers and friends,
> >
> > I am having some trouble with newlib on a bare-metal embedded system
> > that makes reentrant calls to sprintf. The reentrant call reliably
> > experiences a segmentation fault. I have tested with both newlib 2.4.0
> > and newlib 3.0.0, with both newlib-nano and regular newlib, to no
> > effect.
> >
> > ...
> >
> > Do I have a fundamental misunderstanding of newlib's capability to
> > support reentrant calls? Or does this seem like a legitimate bug? I
> > would appreciate any suggestions for workarounds, and I would be happy
> > to provide additional information or perform any further tests to
> > assist the maintainers with this possible issue.
> >
> > Best regards,
> >
> > David Lawrence
> David:
>       Reentrancy requires setup on your part, of which I see none in your
> supplied fragments.  Generate the manual and look at the reentrancy section.
> (You can also look at libc/reent/reent.tex, avoiding the need to make the manual
> but then being in source with formatting commands.)  It describes the 2 methods
> for handling it. In brief, you either need to directly call the reentrant forms
> of the functions with a per-thread structure, or you need to "context switch" by
> setting the global reentrancy pointer for each thread. (No, they do not need to
> be proper threads, but it gets the point across easily to use that term as an
> analogy.)  The second method is easier from the perspective of hiding reentrency
> from the main body of application code.  Both cases require you to define at
> least one of your own reentrancy structures in addition to the single default one.
>       A simple technique I have used in an application quite like yours is to
> have the interrupt handler save _impure_ptr, overwrite it with the ISR's own,
> print, then restore _impure_ptr.
>                  Craig