[MPlayer-users] Re: Failed assertion on Solaris
Alban Bedel
albeu at free.fr
Tue Apr 23 20:50:02 CEST 2002
Hi Rémi Guyomarch,
on Tue, 23 Apr 2002 20:08:19 +0200 you wrote:
> [Automatic answer: RTFM (read DOCS, FAQ), also read DOCS/bugreports.html]
> On Tue, Apr 23, 2002 at 07:15:27PM +0200, Martin Olschewski wrote:
> ...
> > After building mplayer with debug support from the current cvs
> > snapshot, I got the following output when the movie has finished:
> >
> > playtree.c:468: failed assertion `iter->stack_size > 0'
>
> Hmmm, I've already seen that ...
>
> > The real problem is here, that realloc on sparc solaris systems does
> > not return NULL if it is called with size 0. Of course it frees the
> > memory, but it returns the old pointer.
>
> Nice catch ! On FreeBSD there's a different but similiar behaviour,
> from malloc(3) :
>
> [speaking about malloc() tunable options]
>
> V Attempting to allocate zero bytes will return a NULL pointer
> instead of a valid pointer. (The default behavior is to make a
> minimal allocation and return a pointer to it.) This option is
> provided for System V compatibility. This option is incompatible
> with the ``X'' option.
>
> The OpenBSD man page goes into more details, but it means the same
> thing :
> If size is zero and ptr is not a null pointer, the object it
> points to is freed and a new zero size object is returned.
>
> So it seems that the semantics of realloc(xx,0) isn't portable. Since
> Solaris is SysV, I'm wondering which platform does have this
> realloc(x,0) returns NULL behavior, beside Linux. In fact I'm
> wondering if it's not another Linuxism...
>
> Fortunately, on FreeBSD (but not on OpenBSD) I can change this
> behaviour both at runtime and at compile-time, but it's probably not
> the case on other platforms ...
>
> > Unfortunatelly I am not real sure if this is the only occasion where
> > mplayer relies on this behavier,
>
> No, it's not the only occasion. :-((
> For example, the playlist parser does make this bogus assumption and
> crash on my BSD box.
Sorry but I don't have all *nix man page and the linux one don't talk about
this portability issue :( But I found that linux realloc behave like this when
the environment var MALLOC_CHECK_ is set. I'll fix it.
Albeu
More information about the MPlayer-users
mailing list