[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