Hi Andraz, here's the gdb bt output for the interesting thread, which caused the crash during rendering:
Thread 163 (Thread 565124016 (LWP 9290)): #0 0xb741398c in memcpy () from /lib/tls/i686/cmov/libc.so.6 #1 0xb7ac0c25 in mpeg3io_read_data (buffer=0x0, bytes=2092344, fs=0xbdc628e0) at mpeg3io.c:107 #2 0xb7ac569c in mpeg3_read_toc (file=0xbfa7e008, atracks_return=0x21aea298, vtracks_return=0x21aea294) at mpeg3tocutil.c:158 #3 0xb7aba677 in mpeg3_get_file_type (file=0xbfa7e008, old_file=0x0, toc_atracks=0x21aea298, toc_vtracks=0x21aea294) at libmpeg3.c:293 #4 0xb7abae62 in mpeg3_open_copy ( path=0x21aeaf10 "/home/toby/.bcast/[EMAIL PROTECTED]", old_file=0x0, error_return=0x21aeb344) at libmpeg3.c:428 #5 0xb7abb19a in mpeg3_open ( path=0x21aeaf10 "/home/toby/.bcast/[EMAIL PROTECTED]", error_return=0x21aeb344) at libmpeg3.c:547 #6 0x081c0796 in FileMPEG::create_index (this=0xb93fbf60) at filempeg.C:529 #7 0x081c1217 in FileMPEG::open_file (this=0xb93fbf60, rd=1, wr=0) at filempeg.C:196 #8 0x0819f0ac in File::open_file (this=0xbd3f7e78, preferences=0x9f09e1d0, asset=0xbdc4df40, rd=1, wr=0, base_samplerate=-1, base_framerate=-1) at file.C:546 #9 0x0814512a in CICacheItem (this=0xb93f3cf0, cache=0x4572a190, edl=0x4576d090, asset=0x4578c808) at cache.C:367 #10 0x081459e8 in CICache::check_out (this=0x4572a190, asset=0x4578c808, edl=0x4576d090, block=1) at cache.C:79 #11 0x082d0648 in VModule::import_frame (this=0x457a06b8, output=0x457aa8f8, current_edit=0x4578f5c8, input_position=0, frame_rate=25, direction=0, use_opengl=0) at vmodule.C:131 #12 0x082d0fde in VModule::render (this=0x457a06b8, output=0x457aa8f8, start_position=0, direction=0, frame_rate=25, use_nudge=0, debug_render=0, use_opengl=0) at vmodule.C:521 #13 0x082cfe49 in VirtualVNode::read_data (this=0x457a2108, output_temp=0x457aa8f8, start_position=0, frame_rate=25, use_opengl=0) at virtualvnode.C:147 #14 0x082d0085 in VirtualVNode::render_as_module (this=0x457a2108, video_out=0x457a2b40, output_temp=0x457aa8f8, start_position=0, frame_rate=25, use_opengl=0) at virtualvnode.C:244 #15 0x082d0143 in VirtualVNode::render (this=0x457a2108, output_temp=0x457aa8f8, start_position=1125903123083272, frame_rate=25, use_opengl=0) at virtualvnode.C:166 #16 0x082cf47f in VirtualVConsole::process_buffer (this=0x457a1578, input_position=0) at virtualvconsole.C:152 #17 0x082d40b0 in VRender::process_buffer (this=0x4576cc58, input_position=0) at vrender.C:184 #18 0x082d41c8 in VRender::process_buffer (this=0x4576cc58, video_out=0x457a2b40, input_position=0, last_buffer=0) at vrender.C:97 #19 0x08249fc9 in PackageRenderer::do_video (this=0x21aefc0c) at packagerenderer.C:363 #20 0x0824abd8 in PackageRenderer::render_package (this=0x21aefc0c, package=0x44e26d08) at packagerenderer.C:580 #21 0x0828e4c8 in Render::render (this=0x9398940, test_overwrite=1, asset=0xdccd758, edl=0x9f4c0100, strategy=0) at render.C:776 #22 0x0828f275 in Render::run (this=0x9398940) at render.C:366 #23 0xb7b8384f in Thread::entrypoint (parameters=0x9398940) at thread.C:48 #24 0xb75f3240 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #25 0xb747229e in clone () from /lib/tls/i686/cmov/libc.so.6 Since I kept on working with MPEG2 footage under supervision of gdb, I was able to backtrack another crash, which occured during copy&paste editing. It also points to the same root cause: mpeg3io_read_*. Thread 26 (Thread -1531348048 (LWP 12960)): #0 0xb7a943c6 in mpeg3io_read_char (fs=0xbfa017e8) at mpeg3protos.h:682 #1 0xb7a9463f in mpeg3io_read_int32 (fs=0x1) at mpeg3protos.h:700 #2 0xb7a954ef in mpeg3demux_read_program (demuxer=0x357a008) at mpeg3demux.c:1429 #3 0xb7a9694a in mpeg3_read_next_packet (demuxer=0x357a008) at mpeg3demux.c:1786 #4 0xb7a99d4b in mpeg3_create_title (demuxer=0x357a008, toc=0x0) at mpeg3title.c:165 #5 0xb7a93096 in mpeg3_open_copy ( path=0xbfa03ba8 "/media/anim_dvd_background/tech_loops_pal.m2v", old_file=0x0, error_return=0xa4b92408) at libmpeg3.c:463 #6 0xb7a9319a in mpeg3_open ( path=0xbfa03ba8 "/media/anim_dvd_background/tech_loops_pal.m2v", error_return=0xa4b92408) at libmpeg3.c:547 #7 0x081c11ef in FileMPEG::open_file (this=0xbfa00be0, rd=1, wr=0) at filempeg.C:172 #8 0x0819f0ac in File::open_file (this=0xbfa00ab8, preferences=0x8554aa8, asset=0xbfa01dd0, rd=1, wr=0, base_samplerate=0, base_framerate=0) at file.C:546 #9 0x081e94c5 in MainIndexes::add_next_asset (this=0x92d5600, file=0x0, asset=0xbfa01dd0) at mainindexes.C:73 #10 0x08215492 in MWindow::paste_edls (this=0xbfe8fe54, new_edls=0xa4b939f4, load_mode=5, first_track=0x0, current_position=16.199999999999999, edit_labels=1, edit_plugins=1, overwrite=0) at mwindowedit.C:1433 #11 0x08215ccc in MWindow::insert (this=0xbfe8fe54, position=16.199999999999999, file=0xa4b93a5c, edit_labels=1, edit_plugins=1, parent_edl=0x0) at mwindowedit.C:594 #12 0x0821693c in MWindow::paste (this=0xbfe8fe54) at mwindowedit.C:1074 #13 0x081ec624 in Paste::handle_event (this=0x92f13d8) at mainmenu.C:712 #14 0xb7b1d28c in BC_MenuItem::dispatch_key_press (this=0x92f13d8) at bcmenuitem.C:287 #15 0xb7b1e587 in BC_MenuPopup::dispatch_key_press (this=0x92f1048) at bcmenupopup.C:133 #16 0xb7b1b7d3 in BC_Menu::dispatch_keypress (this=0x92f0c18) at bcmenu.C:117 #17 0xb7b1c071 in BC_MenuBar::keypress_event (this=0x92ec0f0) at bcmenubar.C:156 #18 0xb7b4305c in BC_WindowBase::dispatch_keypress_event (this=0x92ec0f0) at bcwindowbase.C:1092 #19 0xb7b43025 in BC_WindowBase::dispatch_keypress_event (this=0x92d60c8) at bcwindowbase.C:1089 #20 0xb7b48680 in BC_WindowBase::dispatch_event (this=0x92d60c8) at bcwindowbase.C:933 #21 0xb7b48fc8 in BC_WindowBase::run_window (this=0x92d60c8) at bcwindowbase.C:614 #22 0xb7b5b84f in Thread::entrypoint (parameters=0xbfe8fe54) at thread.C:48 #23 0xb75cc240 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #24 0xb744b32e in clone () from /lib/tls/i686/cmov/libc.so.6 Looks like there's a serious bug in mpeg3io when it comes to multiple concurrent MPEG2 files. FYI: All MPEG2 files have been created with cinelerra piping to mpeg2enc, (-f 8 -q 3 -b 8000 -n p -a 2 -o %) and multipled with mplex -f 8 (mp2 audio). Toby Andraž Tori wrote: > On Tue, 2006-12-05 at 08:47 +0100, Toby wrote: > >> Thanks for all your feedback ! >> >> Since I don't have any adjacent clips on my timeline, there shouldn't a >> problem >> with gaps. Furthermore, I used a build newer than r952 for the creation, so >> snapping should have worked. >> >> Meanwhile, I figured out how to get my project rendered: I had to render >> all >> full size background tracks into an intermediate file and place this single, >> non-MPEG2 footage, instead of the background MPEG2 material. Then, >> rendering worked fine. Looks like reducing the number of concurrent MPEG2 >> files, from 7 to 6, helped to get the job done. >> >> Since playing with gdb indicated that the crash might happen somewhere >> inside >> libmpeg3 while reading a frame, I'm wondereing whether there's a problem >> with >> MPEG program streams including NAV packages ? >> > > you should use "thread apply all bt" in gdb to find where the crush > really is happening. > > bye > andraz > > > _______________________________________________ > 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
