Re: [Tuxpaint-devel] Kaleidoscope crash

[Albert C. <aca...@gm...>]

On Dec 4, 2007 12:40 PM, Bill Kendrick <nb...@so...> wrote:
> On Thu, Nov 29, 2007 at 11:24:35PM -0500, Albert Cahalan wrote:

> > ==1937== Conditional jump or move depends on uninitialised value(s)
> > ==1937==    at 0x406B17B: (within /usr/lib/libSDL-1.2.so.0.11.1)
> > ==1937==    by 0x406BB09: (within /usr/lib/libSDL-1.2.so.0.11.1)
> > ==1937==    by 0x4037EF6: SDL_PumpEvents (in /usr/lib/libSDL-1.2.so.0.11.1)
> > ==1937==    by 0x4038406: SDL_PollEvent (in /usr/lib/libSDL-1.2.so.0.11.1)
> > ==1937==    by 0x804D7ED: mySDL_PollEvent (in /home/olpc/tuxpaint/tuxpaint)
> >
> > I guess I didn't have debug info in the build. Doing this
> > on the XO hardware is really hard because the CPU is slow.
> > Anyway, mySDL_PollEvent has a problem.
>
> I don't think it was really a problem, just valgrind pointing out that I had
> sent a pointer to an uninitialized "SDL_Event" struct... which was fine,
> because mySDL_PollEvent() would fill it in.

Nope, valgrind isn't that stupid. Read the message again.
The code is making a decision based on uninitialized data.

Pardon me if you're secretly an x86 expert and this is obvious...

The x86 has instructions similar to "if(x) goto y" in C.
It also has "if(x) y=z" instructions. Valgrind detected
that one of these was executed with "x" uninitialized.
These instructions generally come quite directly from
the high-level conditional tests in C. That includes the
"for" loop termination condition, the ?: operator, etc.

Remember that valgrind has a low-level view of things.
Valgrind tolerates copies of uninitialized data, allowing
you to memcpy a partly-initialized struct. This also means
that you can have dummy arguments to functions.
No alarm is raised until the code makes a decision
based on the data or passes the data into a system
call for something like disk IO.

Thus I'm fairly sure there is a real and serious problem.

> Anyway, this one is moot, because I've given up on the idea of record/playback
> in Tux Paint (for demo purposes).  I think it's easy enough to create a
> video ('screencast') and if folks out there demoing Tux Paint want to have
> an automated demo, they can do it using a video, rather than having Tux Paint
> 'play by itself.'

I always saw that as way more useful for automated
testing. It would be great to have Tux Paint test itself.
It could run through all the plug-ins, etc.

Of course, if nobody actually makes and runs a test
script, then the feature just isn't getting used.