On Wednesday 09 December 2009 06:42:08 Sergio M. Ammirata, Ph.D. wrote: > Rob, > > On 12/8/09 10:59 PM, "Rob Landley" <[email protected]> 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 _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
