[mythtv] mythfilldatabas[16844]: segfault at a0 ip 00007fbc0dd7a8e2 sp 00007fbbfd4ec090 error 4 in libmythdb-0.24.so.0.24.0[7fbc0dcce000+13d000]

James Courtier-Dutton james.dutton at gmail.com
Sun Oct 31 00:35:06 UTC 2010


On 30 October 2010 22:39, James Courtier-Dutton <james.dutton at gmail.com> wrote:
> On 30 October 2010 20:58, Michael T. Dean <mtdean at thirdcontact.com> wrote:
>>  On 10/30/2010 03:14 PM, James Courtier-Dutton wrote:
>>>
>>
>> If it's #7714, the proper fix is a bit complex, and we'll probably just
>> include http://svn.mythtv.org/trac/changeset/24291 in 0.24 (like we did in
>> 0.23) since we don't have time to do (nor want the instability caused by the
>> changes required for) the proper fix before release.
>>
>
> It is similar to #7714, but I am using the latest SVN as of yesterday,
> so the bug fix in #7714 has already been applied.
> If the problem I am seeing is a race condition after the object has
> been destroyed, then I agree the real fix is probably more
> complicated.
> If the problem is a simple as out-of-mem then throwing an exception is
> probably the only sensible solution.
> I will try adding the "if (d)" and see if it hides the problem of the
> race condition.
>

The "if (d)" fixed the problem. It was not a out-of-memory problem,
because I have about 2Gig RAM free in a 4Gig RAM machine.
mythtv-backend is taking about 760M.

I think it is a much neater solution than
http://svn.mythtv.org/trac/changeset/24291

I am not exactly sure what "ClearSettingsCache" is for.
My if (d) makes this fail to call "ClearSettingsCache" if the object
has been destroyed and thus no segfault.
Do we actually want "ClearSettingsCache" to succeed, and therefore
require the object to not get destroyed until after the
"ClearSettingsCache" has happened?

Kind Regards

James


More information about the mythtv-dev mailing list