avr-libc-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[avr-libc-dev] [bug #12557] Non-reentrancy in malloc affects fprintf, ss


From: anonymous
Subject: [avr-libc-dev] [bug #12557] Non-reentrancy in malloc affects fprintf, sscanf, etc...
Date: Tue, 5 Apr 2005 02:16:23 +0000
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

URL:
  <http://savannah.nongnu.org/bugs/?func=detailitem&item_id=12557>

                 Summary: Non-reentrancy in malloc affects fprintf, sscanf,
etc...
                 Project: AVR C Runtime Library
            Submitted by: None
            Submitted on: Mon 04/04/2005 at 22:16
                Category: Library
                Severity: 3 - Normal
                Priority: 5 - Normal
              Item Group: None
                  Status: None
                 Privacy: Private
        Percent Complete: 0%
             Assigned to: None
        Originator Email: address@hidden
             Open/Closed: Open

    _______________________________________________________

Details:

Hi,

I am currently using the runtime library that accompanies WinAVR with my own
pre-emptive RTOS. I have used fdevopen() to direct output  to a serial port
and an LCD. It is possible for a task that writes to the LCD to be preempted
by a task that writes to a serial port, and vice-versa, and either could
preempt a user input task that uses sscanf. This is all perfectly reasonable
and normal in an embedded system.

Looking at fdevopen(), vfprintf() and vfscanf(), I notice that they all
(indirectly) call malloc() (in the latter two cases, when using floating
point numbers). This appears to be somewhat problematical, as malloc() does
not appear to be reentrant. As far as I can determine, it appears to be
possible for one task that is partway through walking the freelist to be
preempted by another task that then alters the freelist, before resuming the
first task.

I hope that I am wrong, and do not have to implement a workaround*.

I would appreciate your opinion as to whether or not this is a genuine
issue.

Kind regards,
Tanya Cumpston

*(The workaround would consist of writing substitutes for the above stdio
routines, which attempt to secure a semaphore before calling the existing
library routines, then using #defines to redirect calls to the existing
library routines to the substitute routines.)




    _______________________________________________________

Carbon-Copy List:

CC Address                          | Comment
------------------------------------+-----------------------------
tcumpston --AT-- bigpond --DOT-- com | Originator Email




    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?func=detailitem&item_id=12557>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/





reply via email to

[Prev in Thread] Current Thread [Next in Thread]