reentrant sprintf causes segmentation fault

Dave Nadler
Fri May 3 17:43:00 GMT 2019

David - If you're going to use FreeRTOS or similar, this might prove 

On 5/3/2019 1:25 PM, David Lawrence wrote:
> 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 <> 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

Dave Nadler, USA East Coast voice (978) 263-0097,, Skype

More information about the Newlib mailing list