Re: Huge numbers for incr passed to _sbrk

On Fri, Aug 24, 2018 at 2:16 PM, Michael Mamic <[email protected]>
wrote:

> I have fixed the bug now. It turns out that I was using uint32_t types for
> my sbrk implementation when I should have been using char* types. The
> official Newlib documentation uses caddr_t in its sample implementation of
> sbrk, which was confusing to me as that is a type I had never seen before.
> I had to browse through a forum from 1999 to figure out that caddr_t is
> just a typedef to char*.
>
> I think it would help all new users of Newlib if the documentation used
> char* instead of caddr_t, or at least had a sentence saying what caddr_t
> is.
>

The default typedef is in newlib/libc/include/sys/types.h. Some OSes
define it themselves.  caddr_t seems easy to find.  Which seems irrelevant
since sbrk() is prototped in sys/unistd.h as:

./sys/unistd.h:void *  _sbrk (ptrdiff_t __incr);

Looks like there are a fair number of incorrect types in the various sbrk
implementations in libgloss.

Where did you find your sbrk() starting point?

And was there not a mismatched prototype warning when you compiled it?

--joel




>
> On Thu, Aug 23, 2018 at 1:52 PM Bob Dunlop <[email protected]>
> wrote:
>
> >
> > On Thu, Aug 23 at 10:22, Michael Mamic wrote:
> > > A similar incr value of huge proportions is passed to sbrk when Lua is
> > > initialized. I need to find out why this is happening so I can adjust
> for
> > > it.
> >
> > Are the library and syscall implementation being compiled with the
> > same compiler flags and using a common header file for the function
> > prototype ?
> >
> > A mismatch in type or parameter passing conventions between caller and
> > callie could lead to these sorts of errors.  But then I'd have expected
> > just about every function to be affected.
> >
> > The value seen in the syscall 1431656813 converted to hex is 0x5555596D.
> > Now all those 5s make me think of stack or memory boundry guard values.
> >
> > --
> >         Bob Dunlop
> >
>