Menu
▾
▴
Re: [Blockbuster-devel] File Open Bug -- causing SM segfaults/ Move to first frame inconsistent behavior
|
From: Brian P. <br...@tu...> - 2003-09-02 15:35:42
|
Robert Ellison wrote:
>> With the new ability to open files from the GUI, I've noticed
>> segfaults while opening a new movie from within blockbuster. I can
>> trigger this fairly easily if I open a big movie and during the frame
>> preloads try to open another movie. GDB reports either pointers out
>> of range for the input buffers or a destRowStride or Res that's way
>> out of whack.
>>
>> Recommendation: Be sure that when opening a new movie to absolutely
>> kill all running threads that call getFrameBlock including other
>> threads with implicit dependencies. Delete the smBase object and try
>> to get the system into the same state as is prior to loading the first
>> movie.
>
>
> Hmmm, curious...
>
> The main program resets a lot when the FrameList changes; it grabs the
> mutex, clears the work queue, and then sets a flag that causes any
> pending threads to throw away their work when they're done (mostly
> because I didn't want to find myself in a situation where I destroyed
> threads and then couldn't recreate them for whatever reason).
>
> The theory is that the pending threads should be able to finish without
> harm, and that it's less destructive to let them finish than it would be
> to stop them. (Some of the file format libraries, like PNG, have
> explicit startup/shutdown operations that made me worry about what might
> happen if they got closed down early...
>
> Still, it's easy enough to try (replace a ClearImageCache() with a
> DestroyImageCache(), which kills threads, and CreateImageCache(), which
> creates more). I'll try to reproduce the problem, and see if this helps.
>
> The smBase object in the current code will be deleted when the frame
> list is deleted (more correctly, when every frame reference that uses it
> is deleted). That doesn't happen right now, as we try to open the new
> frame list (thus creating a bunch more frame references using the smBase
> object) before discarding the old (to make sure we don't end up in a
> state with no movie to display).
>
> Could modify this too (by including in the main loop the ability to open
> files any time the frame list is empty).
>
> I'll see what I can see, and then choose whatever seems to fix it. ;-)
>
> Quick question (hopefully): do you know for certain that smBase retains
> per-movie information based on the owning file, that is not logically
> separate for each frame? blockbuster allows you to specify multiple
> movies on the command line, the frames of which are logically
> concatenated for display, and all of which are opened with a single
> smBase object. Perhaps the better answer is to modify our own interface
> code in sm.C, to use a different smBase object for each separate file...
>
>> Also, I've noticed while playing with the GUI that when I change Zoom
>> factor and play the movie, then stop, then press the first frame
>> button blockbuster ignores the zoom setting, including the
>> shrink-to-fit value -- instead the frame is displayed at native size.
>
>
> It's a feature! :-) From movie.c:
>
>> case MOVIE_GOTO_START:
>> frameNumber = 0;
>> /* also reset panning */
>> xOffset = yOffset = 0;
>> izoom = 0;
>> if (canvas->ReportZoomChange != NULL) {
>> canvas->ReportZoomChange(canvas, 1.0);
>> }
>> break;
>
>
> The "go to start" function is written to restore the initial state of
> the movie display.
>
> If you'd like it to operate simply as a transport control, that's pretty
> easy to do (just pull out everything but the frameNumber setting). I
> suppose that makes sense; GOTO_START was written (I think) before there
> were other ways to reset the panning and zooming...
>
> I'll make that change too.
Yeah, that should definitely be fixed - I put that in early in the
project before we had other zoom controls as a temporary thing.
-Brian
|