Andraz,
Thanks for the advice. Those tasks are a little above my skill level, but I
will do some research and give it a shot.
scott
-------------- Forwarded Message: --------------
From: "Scott C. Frase" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: [Fwd: Re: [CinCVS] constant hangs on HDV project]
Date: Thu, 8 Feb 2007 12:30:43 +0000
>
--- Begin Message ---
--- Begin Message ---
i suspect there is some kind of a race where circular reference is
created in cachebase.C
and in function get_oldest it runs around till some other thread does
something to the structure...
i'd put a simple loop catching algorithm there and see if it catches an
'endless' loop
bye
andraz
On Tue, 2007-02-06 at 20:28 -0500, Scott C. Frase wrote:
> Hannes,
> Well, this was instructive. I was grabbing and moving the wav file
> around quite a bit, perhaps 10 times. I replicated the hang. In order
> to find the hanging thread, I started gdb ("gdb cinelerra 5647"). I
> found the offending thread:
>
> Thread 65 (Thread -1520473168 (LWP 5674)):
> #0 0x0813fceb in CacheBase::get_oldest (this=0x8c04068) at
> cachebase.C:106
> #1 0x081f00bb in MWindow::age_caches (this=0xbfc5a288) at
> mwindow.C:1569
> #2 0x081f5e7b in MWindow::move_edits (this=0xbfc5a288, edits=0x8539b70,
> track=0x920f238, position=49.724958333333333, behaviour=1) at
> mwindowedit.C:830
> #3 0x08289ed6 in TrackCanvas::drag_stop (this=0xa9e1e7e0) at
> trackcanvas.C:575
> #4 0x0828a13d in TrackCanvas::drag_stop_event (this=0xa9e1e7e0) at
> trackcanvas.C:325
> #5 0xb7b73029 in BC_WindowBase::dispatch_drag_stop (this=0xa9e1e7e0) at
> bcwindowbase.C:1316
> #6 0xb7b7300e in BC_WindowBase::dispatch_drag_stop (this=0x8c44da0) at
> bcwindowbase.C:1311
> #7 0xb7b73122 in BC_WindowBase::dispatch_button_release
> (this=0x8c44da0) at bcwindowbase.C:1162
> #8 0xb7b778b1 in BC_WindowBase::dispatch_event (this=0x8c44da0) at
> bcwindowbase.C:787
> #9 0xb7b78739 in BC_WindowBase::run_window (this=0x8c44da0) at
> bcwindowbase.C:614
> #10 0xb7b88bb8 in Thread::entrypoint (parameters=0xbfc5a288) at
> thread.C:48
> #11 0x00da0b80 in start_thread () from /lib/libpthread.so.0
> #12 0x00c11dee in clone () from /lib/libc.so.6
>
> I then exited gdb and found that the process hang was still occurring.
> So I started up kdbg ("kdbg -p 5647 /usr/local/bin/cinelerra") and
> selected "View -> Threads". I then used an alternating combination of
> F8 and F10 to step in and out of the code. I found that kdbg hung at
> this line of code: MWindow.C:1561. It took a while, maybe five minutes
> for kdbg to free up. After the release, I continued for a bit, stepping
> in and out of the code, but since kdbg did exactly what you said it
> would do, I gave up and thought to report my results back to you.
>
> This is the snippet of hvirtual/cinelerra/mwindow.C code starting at
> line 1561:
>
> if(memory_usage > preferences->cache_size)
> {
> int target = 1;
> int oldest1 = audio_cache->get_oldest();
> int oldest2 = video_cache->get_oldest();
> if(oldest2 < oldest1) target = 2;
> int oldest3 = frame_cache->get_oldest();
> if(oldest3 < oldest1 && oldest3 < oldest2)
> target = 3;
> int oldest4 = wave_cache->get_oldest();
> if(oldest4 < oldest3 && oldest4 < oldest2 &&
> oldest4 < oldest1) target = 4;
> switch(target)
> {
> case 1: audio_cache->delete_oldest();
> break;
> case 2: video_cache->delete_oldest();
> break;
> case 3: frame_cache->delete_oldest();
> break;
> case 4: wave_cache->delete_oldest();
> break;
> }
> }
>
>
> I'm no big C programmer, but inferring from the if statement, it looks
> like I only go into this control structure if cin's memory usage is
> greater than the value stated in Preferences -> Cache Size. I have it
> set to the default value of 10MB.
>
> Is this a code bug or do I just need to set the Cache Size to something
> larger than 10MB?
>
> Did I do good?
> scott
>
>
> On Tue, 2007-02-06 at 21:06 +0100, Johannes Sixt wrote:
> > On Tuesday 06 February 2007 02:29, Scott C. Frase wrote:
> > > Thread 10 (Thread 2047089584 (LWP 6752)):
> > > #0 0x082a634c in WaveCacheItem::get_size (this=0x981d220) at
> > > wavecache.C:18
> > > #1 0x0813fded in CacheBase::get_memory_usage (this=0x8c04068) at
> > > cachebase.C:152
> > > #2 0x081eff7b in MWindow::age_caches (this=0xbfc5a288) at
> > > mwindow.C:1559
> > > #3 0x081f08d3 in MWindow::update_project (this=0xbfc5a288, load_mode=3)
> > > at mwindow.C:1852
> > > #4 0x081f301c in MWindow::load_filenames (this=0xbfc5a288,
> > > filenames=0x7a0413e8, load_mode=3, update_filename=0,
> > > reel_name=0x82eb360 "none",
> > > reel_number=-1, overwrite_reel=0) at mwindow.C:1133
> > > #5 0x081c8276 in LoadFileThread::run (this=0x8c68020) at loadfile.C:149
> > > #6 0xb7b88bb8 in Thread::entrypoint (parameters=0x8c68020) at
> > > thread.C:48
> > > #7 0x00da0b80 in start_thread () from /lib/libpthread.so.0
> > > #8 0x00c11dee in clone () from /lib/libc.so.6
> >
> > This is the interesting piece. Your last post also showed that a thread was
> > working in MWindow::age_caches().
> >
> > Next time, you have a hang can you please go to this thread and see which
> > function takes so long to finish? age_caches() has 4 calls to
> > get_memory_usage around line 1559.
> >
> > It's easiest if you use KDbg. Attach to the hanging process, Look up the
> > thread in the Thread window, then use Execute->Step Into and ->Step out; I
> > suspect that one of these functions takes long to complete; you will notice
> > it when Step Out takes a while to come back.
> >
> > Welcome to the Hacker's guilde! ;)
> >
> > -- Hannes
> >
> > _______________________________________________
> > Cinelerra mailing list
> > [email protected]
> > https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
>
>
> _______________________________________________
> Cinelerra mailing list
> [email protected]
> https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
_______________________________________________
Cinelerra mailing list
[email protected]
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
--- End Message ---
--- End Message ---
