[mythtv-users] everyday i have to make sure myth worked the day before

[Bruce Taber]

On 04/20/2011 08:32 PM, Tom Lichti wrote:
> On Wed, Apr 20, 2011 at 5:29 PM, Kevin Ross <kevin at familyross.net> wrote:
>> On 4/20/2011 6:47 AM, Tom Lichti wrote:
>>> I don't think it is the system, at least not in my case. I had been
>>> running:
>>> mythbackend --version
>>> Please attach all output as a file in bug reports.
>>> MythTV Version   : v0.25pre-1579-g786a95f
>>> MythTV Branch    : master
>>>
>>> until yesterday and I have never seen this socket problem. Yesterday I
>>> updated to current trunk:
>>>
>>> mythbackend --version
>>> Please attach all output as a file in bug reports.
>>> MythTV Version   : v0.25pre-1799-gb1a731e
>>> MythTV Branch    : master
>>>
>>> and I can reproduce this error at will, anytime. All I have to do is
>>> run the backend with default logging and then try and do anything from
>>> a frontend or mythweb, and it will deadlock instantly. I am currently
>>> running with -v socket and it is somewhat stable, enough that I can at
>>> least record and watch stuff (with only one frontend at a time though)
>>> but commflagging is segfaulting everytime.
>>
>> Since you have a version that worked, and a version that doesn't work,
>> and you can easily reproduce the problem, how about using git bisect to
>> find the exact change that introduced the problem?
> 
> I'd love to but, I've never been able to figure out how to do it. If I
> had step by step git instructions on how to compile a specific
> version, I'll give it a whirl. I used to do it all the time with SVN,
> but I don't know the equivalent in git.
> 
> Tom
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://www.mythtv.org/mailman/listinfo/mythtv-users
> 
Hi Tom,

I also have the problem and it seems relatively easy to reproduce. With
your earlier version as a starting point I am in the process of trying
to pinpoint the problem commit. I am not an expert at git but these seem
to be the steps to do what we need. I am sure someone will make any
necessary corrections if need be.

1. git bisect start
2. git bisect bad
3. git bisect good <your commit version from above>
4. git checkout <your commit version from above>
5. compile and run tests - most likely needs make distclean & configure
6. git bisect good or bad depending on test results
7. git bisect reset - once the bad commit is found

Not sure about the actual process as I am still compiling at the first
good point to verify that is a good version.

Bruce