The CinelerraCV Project (Linux Journal)

Posted Dec 7, 2009 21:57 UTC (Mon) by jra (subscriber, #55261)
Parent article: The CinelerraCV Project (Linux Journal)

In the age of valgrind, I don't understand why GUI projects still have reproducible crashes.....

Jeremy.

The CinelerraCV Project (Linux Journal)

Posted Dec 7, 2009 22:01 UTC (Mon) by BrucePerens (guest, #2510) [Link] (6 responses)

Yes, this sounds like wild pointers to me. Cinelerra is enormously memory-intensive, but it should be possible to instrument and debug. Valgrind should do it, Electric Fence might work on a machine with lots of RAM.

The CinelerraCV Project (Linux Journal)

Posted Dec 7, 2009 23:59 UTC (Mon) by elanthis (guest, #6227) [Link] (5 responses)

If nothign else, learning how to write quality code could do wonders. Well-written code is damn hard to crash.

The CinelerraCV Project (Linux Journal)

Posted Dec 8, 2009 0:48 UTC (Tue) by BrucePerens (guest, #2510) [Link] (4 responses)

Let's not be too fast here. Cinelerra is a huge, extremely functional, powerful program of the type that only a few years ago people said you could never get as Open Source. Good programmers write bugs too. If you want to know what the real problem is, instrument the code (on a system with lots of RAM and a fast CPU, I bet) and you'll be able to report back to us.

The CinelerraCV Project (Linux Journal)

Posted Dec 8, 2009 2:55 UTC (Tue) by madscientist (subscriber, #16861) [Link] (3 responses)

Heck, you don't have to instrument the code: most of the time all you have to do is run the thing in the debugger (assuming you have a debug build) full time. Then when it crashes you usually have all the info you need right there to figure out what happened, at least enough to get a good start. I ran Evolution for probably a year in the debugger, and we fixed a number of bugs in the OWA interface (and even some in Gnome itself) because of stack traces etc. obtained that way.

The CinelerraCV Project (Linux Journal)

Posted Dec 8, 2009 15:48 UTC (Tue) by mjthayer (guest, #39183) [Link] (2 responses)

> Heck, you don't have to instrument the code: most of the time all you have to do is run the thing in the debugger (assuming you have a debug build) full time.
This sort of thing can all be automated. Many distributions do that already, but things could still be improved a lot. At least Ubuntu disables it by default in releases to avoid swamping the bug system, they require a Launchpad account and I don't think they do it for all packages. I would have thought that this should always be the default, and that the traces should just be mailed to an e-mail address without requiring any login. That address should have the logic behind it for automatically filtering duplicates, spam and broken reports, and add valid reports to a database, keeping a duplicate count. Like kerneloops, but for userspace. It takes a bit of work, but it could be reused for virtually any software.

The CinelerraCV Project (Linux Journal)

Posted Dec 8, 2009 17:18 UTC (Tue) by madscientist (subscriber, #16861) [Link]

You're talking about automating collection of backtraces. That's useful. But I'm talking about actually invoking the problem application inside GDB; that is, instead of running "someprog", you run "gdb someprog" then "run" at the prompt.

The advantage of this is that when the process dies you are right there and can do live debugging. It's not so useful if you don't have any programming experience at all, but even if you have just a smidgen you can often poke around and look at variable values, etc. that give a LOT more information than just a backtrace. Even if you don't know programming, if you find a properly motivated developer he can give you lots of pointers and instruction over email or IRC or whatever; you'll be able to pick it up pretty quickly.

The CinelerraCV Project (Linux Journal)

Posted Dec 9, 2009 15:58 UTC (Wed) by mjthayer (guest, #39183) [Link]

Ubuntu upload an entire core dump by default, but that is rather bulky. I could imagine refining the process a bit - like accepting core dumps if a developer has looked at the stack trace for a given crash and decided that they would be interested in more information. Obviously being there with a running gdb when a crash occurs will let you obtain a lot more information, but that rather limits the surface of attack available to you. The advantage of the automatic backtrace thing is that you get information about a much wider range of crashes than you are ever likely to see yourself.