[mythtv] Updated patch for directshow filters with MythTV (for CoreAVC)
mark.buechler at gmail.com
Wed Feb 14 20:34:13 UTC 2007
Doesn't look like VirtualAlloc is failing, or at least it's not segfaulting
within that method:
VirtualAlloc(0x10000000, 762368, 0x00003000, 0x00000040)
Nothing in the while(str) loop is process and the function returns with:
VirtualAlloc(...) provides (0x10000000, 765952)
Does that look right? Can you think of any other place I should look?
On 2/13/07, Alan Nisota <alannisota at gmail.com> wrote:
> Alan Nisota wrote:
> > It appears that the VirtualAlloc is failing. This has nothing to do
> > with the # of CPUs but does have to do with your CPU type and compile
> > options. All I can say is compile with debug enabled, then startup
> > mythfrontend inside gdb and set a breakpoint at ext.c:445
> > Then step through and find out where it fails. If you get a
> > stack-trace before you get to the breakpoint, give me a 'bt' but I'd
> > be surprised if that were the case. The VirtualAlloc function changed
> > significantly between the 1.0 and 1.1 versions of my patch.
> I forgot to add, you'll get a break because of the clone() call
> (depending on your gdb options, this may not happen). Once you select a
> recording which starts CoreAVC you should get a break in VirtualAlloc
> (due to the breakpoint I told you to add). If you can get past that
> (which you probably can't based on the logs), you'll get a segmentation
> fault that looks like:
> Program received signal SIGSEGV, Segmentation fault.
> 0x100bd887 in ?? ()
> This is normal. you just need to 'continue'. This is a triggered
> segfault used to swap the compressed image with the uncompressed one,
> and is one of the nastier sides of PECompact2. The SEGV will be caught
> and handled properly by the relevant handler in this case so it is a red
> herring as far as crashes go.
> mythtv-dev mailing list
> mythtv-dev at mythtv.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the mythtv-dev