[mythtv] AC3 passthrough and timestretch problems

John P Poet jppoet at gmail.com
Sat May 3 01:31:37 UTC 2008


On Fri, May 2, 2008 at 6:46 PM, Mark Spieth <mark at digivation.com.au> wrote:
> >Oops.  Unfortunately, mythfrontend randomly segfaults with this patch
>  >applied.  I will re-test with your original patch.
>
>  its probably divide by 0. can you get a backtrace please. only for the
>  thread in error of course.
>
>  mark

I will attach the whole gdb.txt file, but I believe it died in this thread:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xae9feb90 (LWP 13691)]

frame-begin 0 0x4d49870c
0x4d49870c in memcpy () from /lib/libc.so.6

<snip>

Thread 7 (Thread 0xae9feb90 (LWP 13691)):

frame-begin 0 0x4d49870c
#0  0x4d49870c in memcpy () from /lib/libc.so.6
No symbol table info available.

frame-begin 1 0xb6a65033
#1  0xb6a65033 in ~ConfigurationWizard (this=0xabfe6008) at
../libmyth/mythconfigdialogs.h:127
No locals.

frame-begin 2 0xb6a66066
#2  0xb6a66066 in std::copy<Configurable**, Configurable**>
(__first=0xabfe6008, __last=0x83dbc88, __result=0x600) at
/usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/bits/stl_algobase.h:456
No locals.

frame-begin 3 0xb79cdcf4
#3  0xb79cdcf4 in NuppelVideoPlayer::StartPlaying (this=0x83c5570) at
NuppelVideoPlayer.cpp:3439
	output_video = 2943421692
	decoder_thread = 1536

frame-begin 4 0xb7a3ceb7
#4  0xb7a3ceb7 in OSD::parsePositionRects (this=0x82f0120,
container=0x0, element=@0x357b) at osd.cpp:1199
	dtmp = {d = {jd = 137890144}, t = {ds = 2904730416}}
	dtime = {static null = {static null = <same as static member of an
already seen type>, d = 0x81d7418, static shared_null = 0x81d7418}, d
= 0x82f0830, static shared_null = 0x81d7418}
	verbose_macro_tmp = <incomplete type>
	name = {static null = {static null = <same as static member of an
already seen type>, d = 0x81d7418, static shared_null = 0x81d7418}, d
= 0x2074ae9, static shared_null = 0x81d7418}
	rects = (class OSDTypePositionRectangle *) 0x0

frame-begin 5 0xb79d7bf3
#5  0xb79d7bf3 in __normal_iterator (this=0x0, __i=@0x357b) at
/usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/bits/stl_iterator.h:683
No locals.

frame-begin 6 0x0
#6  0x00000000 in ?? ()
No symbol table info available.



Here is the "simple" bt:

0  0x4d49870c in memcpy () from /lib/libc.so.6
#1  0xb6a65033 in ~ConfigurationWizard (this=0xabfe6008) at
../libmyth/mythconfigdialogs.h:127
#2  0xb6a66066 in std::copy<Configurable**, Configurable**>
(__first=0xabfe6008, __last=0x83dbc88, __result=0x600) at
/usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/bits/stl_algobase.h:456
#3  0xb79cdcf4 in NuppelVideoPlayer::StartPlaying (this=0x83c5570) at
NuppelVideoPlayer.cpp:3439
#4  0xb7a3ceb7 in OSD::parsePositionRects (this=0x82f0120,
container=0x0, element=@0x357b) at osd.cpp:1199
#5  0xb79d7bf3 in __normal_iterator (this=0x0, __i=@0x357b) at
/usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/bits/stl_iterator.h:683
#6  0x00000000 in ?? ()

I am not that good at reading BT results, so I hope this helps you.

John
-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gdb.txt.bz2
Type: application/x-bzip2
Size: 8578 bytes
Desc: not available
Url : http://mythtv.org/pipermail/mythtv-dev/attachments/20080502/44786fda/attachment.bin 


More information about the mythtv-dev mailing list