So using the same simple test case, I still get the other crash as
well. If anyone read's this they might wonder what the "MATT inbuf"
junk is below. Well I added some debug statements to try and figure
out what is happening. It appears the the plugin on
ReverbEngine class is getting set with a bad/junk plugin.
At line 505 of reverb.C I added the following 2 lines:
printf("MATT plugin: %d", plugin);
printf("MATT inbuf:%d", plugin->total_in_buffers);
for(i = 0; i < plugin->total_in_buffers; i++)
It appears to crash trying to derefence plugin->total_in_buffers (or
at least according to my debug statements it does).
$ cinelerra
Cinelerra 2.1CV SVN 948 (C) 2006 Heroine Virtual Ltd.
Binary built via ebuild script in Gentoo linux.
Cinelerra is free software, covered by the GNU General Public License,
and you are welcome to change it and/or distribute copies of it under
certain conditions. There is absolutely no warranty for Cinelerra.
Mutex::lock: Success
MATT plugin: 149401664MATT inbuf:1MATT plugin: 149401664MATT
inbuf:1MATT plugin: 149107096MATT inbuf:1MATT plugin: 149107096MATT
inbuf:1MATT plugin: 149107096MATT inbuf:1MATT plugin: 149107096MATT
inbuf:1MATT plugin: 149107096MATT inbuf:1MATT plugin: 320signal_entry:
got SIGSEGV my pid=21818 execution table size=16:
vrender.C: run: 506
vrender.C: run: 414
vrender.C: process_buffer: 103
vrender.C: process_buffer: 113
vrender.C: run: 416
vrender.C: run: 427
vrender.C: run: 439
vrender.C: run: 477
vrender.C: run: 489
vrender.C: run: 493
vrender.C: run: 495
vrender.C: run: 504
vrender.C: run: 506
vrender.C: run: 414
vrender.C: process_buffer: 103
vrender.C: process_buffer: 113
signal_entry: lock table size=20
0x8bcc968 CWindowTool::input_lock CWindowTool::run
0x85ae4b8 BC_Synchronous::next_command BC_Synchronous::run
0x8c9b8b8 TransportQue::output_lock PlaybackEngine::run
0x8c9bee0 MainIndexes::input_lock MainIndexes::run 1
0x8d8a9f8 RotateEngine::input_lock RotateEngine::run
0x8e48370 (null) (null) *
0x8d078d0 ResourceThread::draw_lock ResourceThread::run
0x8bf0ef8 TransportQue::output_lock PlaybackEngine::run
0x8d35850 BC_Repeater::pause_lock BC_Repeater::run
0x85c0a20 AudioDevice::arm_lock AudioDevice::arm_buffer *
0x85c09e0 AudioDevice::arm_lock AudioDevice::arm_buffer *
0x8a33550 BC_WindowBase::event_condition BC_WindowBase::get_event
0x8b56fc0 BC_WindowBase::event_condition BC_WindowBase::get_event
0x8bf2550 BC_WindowBase::event_condition BC_WindowBase::get_event
0x8d36e58 BC_WindowBase::event_condition BC_WindowBase::get_event
0x8c16490 BC_WindowBase::event_condition BC_WindowBase::get_event
0x8c9dcc8 BC_WindowBase::event_condition BC_WindowBase::get_event
0x85c0a00 AudioDevice::play_lock AudioDevice::run 1 *
0x8e6f8c8 OSSThread::write_lock OSSThread::wait_write
0x85c0a20 AudioDevice::arm_lock AudioDevice::arm_buffer
BC_Signals::dump_buffers: buffer table size=0
BC_Signals::delete_temps: deleting 0 temp files
SigHandler::signal_handler total files=0
Aborted (core dumped)
I loaded this up in gdb and it confirms that it crashed on line (which
appears to validate my suspicion).
My question is why this is happening?
Help please?
thanks
-matt
On 10/28/06, m h <[EMAIL PROTECTED]> wrote:
Ok, simpler test case. Add reverb (concert hall sound effect) to
track and it crashes occasionally when played.
Heres the error:
cinelerra: pthread_mutex_lock.c:80: __pthread_mutex_lock: Assertion
`mutex->__data.__owner == 0' failed.
Aborted (core dumped)
The backtrace on the core file says this:
(gdb) bt
#0 0xffffe410 in __kernel_vsyscall ()
#1 0xb737c129 in raise () from /lib/libc.so.6
#2 0xb737d553 in abort () from /lib/libc.so.6
#3 0xb7375cbd in __assert_fail () from /lib/libc.so.6
#4 0xb74961be in pthread_mutex_lock () from /lib/libpthread.so.0
#5 0xb7a117d9 in Mutex::lock (this=0x8e622d0, location=0x0) at mutex.C:47
#6 0xb24e0bdc in ReverbEngine::run (this=0x8e622b0) at reverb.C:501
#7 0xb7a1ccd9 in Thread::entrypoint (parameters=0x8e622b0) at thread.C:48
#8 0xb7494167 in start_thread () from /lib/libpthread.so.0
#9 0xb740ab7e in clone () from /lib/libc.so.6
Line 501 of reverb.C is this:
input_lock.lock();
I guess I need to read up on pthread locking.
Anyway, can anyone help out here? Does this crash happen for other people?
Should I file another bug for this?
I'd like to help out and start understanding what's going on and
solving some of the crashes that I run into. But I'm at a loss right
now.
-matt
On 10/28/06, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
> http://bugs.cinelerra.org/show_bug.cgi?id=347
>
> ------- Additional Comments From [EMAIL PROTECTED] 2006-10-29 00:02 -------
> Here's backtrace info from the core dump:
>
> (gdb) bt
> #0 0xffffe410 in __kernel_vsyscall ()
> #1 0xb7395129 in raise () from /lib/libc.so.6
> #2 0xb7396553 in abort () from /lib/libc.so.6
> #3 0xb7a03d94 in signal_entry (signum=11) at bcsignals.C:182
> #4 <signal handler called>
> #5 0xb24f9e44 in ReverbEngine::run (this=0x8e63ce8) at reverb.C:505
> #6 0xb7a35cd9 in Thread::entrypoint (parameters=0x8e63ce8) at thread.C:48
> #7 0xb74ad167 in start_thread () from /lib/libpthread.so.0
> #8 0xb7423b7e in clone () from /lib/libc.so.6
>
> Line 505 looks like this (in reverb.C):
> for(i = 0; i < plugin->total_in_buffers; i++)
>
> I'm not familiar with the flow of the code but, I can only find one place
where
> total_in_buffers is set on the plugin.
>
> If anyone can shed some light on how to fix this I'd be very happy.
>
> thanks
>
>
>
> ------- You are receiving this mail because: -------
> You are the assignee for the bug, or are watching the assignee.
>
> _______________________________________________
> Cinelerra mailing list
> Cinelerra@skolelinux.no
> https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
>
_______________________________________________
Cinelerra mailing list
Cinelerra@skolelinux.no
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
