bugs in malloc

Rob Landley rob at landley.net
Thu Dec 10 01:47:18 UTC 2009


On Wednesday 09 December 2009 06:42:08 Sergio M. Ammirata, Ph.D. wrote:
> Rob,
>
> On 12/8/09 10:59 PM, "Rob Landley" <rob at landley.net> wrote:
> > On Tuesday 24 November 2009 06:14:36 Sergio M. Ammirata, Ph.D. wrote:
> >> If it helps, I am also experiences crashes in malloc. They did not occur
> >> in 0.9.28. Here is a sample backtrace:
> >
> > Is there any way we can reproduce this?  (How did you ./configure and
> > build vlc, and what test data are you running through it?)
>
> Yes, I can reproduce it consistently with a specific mpeg ts input file. It
> happens only a few seconds after the program starts.

Cool, no special hardware required.

> Compiling VLC to reproduce the error it is not as easy as giving you the
> configure script. You also need to have all the dependencies that I am
> using (x264, ffmpeg and other supporting libs).

Presumably if you built those from source you also have the 
./configure;make;install steps for those too?

> Then, the program needs to
> be executed with a set of parameters that tell it to transcode the stream
> to h264.

Shell script wrapper?

> I don't mind giving someone all this information and source files
> if it means fixing the issue.

Well, I can't do much if I can't reproduce this issue, and I haven't seen it 
when running gcc on things.  (I do fairly large compiles under uClibc and they 
seem to work so far.  But gcc isn't multi-threaded, and I suspect that's an 
important part of this.)

> I can also give someone full access to my build and test environment.

Lemme see if I can reproduce it here first.

> >> The crash happens in different parts of the application but it is always
> >> a malloc crash.
> >
> > Does Freeman's patch fix it for you?
>
> I did not try Freeman's patch because of the thread of emails that
> followed, which really irritated me.

I got used to Mike objecting that he doesn't understand (or see the importance 
of) other people's changes because he never personally encountered that bug, 
or that he encountered this in his private blackfin fork ages ago but never 
bothered to push the patch upstream.  I largely ignore it these days.

But then, I have a history of butting heads with him:

http://lists.uclibc.org/pipermail/uclibc/2009-November/043284.html
http://lists.uclibc.org/pipermail/uclibc/2009-November/043318.html
http://lists.uclibc.org/pipermail/uclibc/2009-November/043256.html
http://lists.uclibc.org/pipermail/uclibc/2009-October/043193.html

And so on, and so forth, back to at least 2006...

> The maintainers basically told him he
> was wrong in his assumptions and solution but they did not follow through
> with a "correct" fix.

No, Mike did.  Bernhard is maintainer, not Mike.  Don't let Mike discourage 
you, he's a developer who works on a private blackfin fork of uClibc as part of 
his day job.  Note that he has commit access to the development tree, yet 
still primarily works on a _private_ fork.  (Ponder that for a bit.)

If somebody else thinks they have a fix to a real problem you're seeing, _try_ 
it.  No matter what mike says.  If it's not the "correct" fix it can still help 
you limp along in the multi-year gaps between development releases.

I got your email about eglibc the other day.  I'm sorry your suppliers 
consider uClibc a dead project.  I agree its' development process is moribund 
and has been for years, but I'm interested in performing some necromancy on 
it.  (This week has been bad.)  Obviously waiting for it to get better hasn't 
worked, and is not an option if _I_ don't want to have to switch to eglibc.  
(Which is lgplv3.  Ew.)

> >> Regards,
> >
> > Rob
>
> Sergio

Rob
-- 
Latency is more important than throughput. It's that simple. - Linus Torvalds


More information about the uClibc mailing list