Skip to content
This repository

Fix freezing bug and more changes #36

Closed
wants to merge 4 commits into from

6 participants

Sumukh Sridhara Aristides Lourenco Charlie Stigler Steve Jhering henrik242
Sumukh Sridhara

As mentioned, the freezing bug has been adressed in this pull request. If you would like me to only include that one change, I can put up another pull request that only fixes that bug.

The other fixes:
Goes to 0.0.0.0 instead of 127.0.0.1.
This is in response to #34. Only one line of code was changed.

Quieted a bunch of NSLogs that seemed to be polluting the system log.

and others added some commits January 31, 2012
Sumukh Sridhara Updated the block to go to 0.0.0.0 instead of 127.0.0.1 347c46b
Sumukh Sridhara Fixed bug (freezing of screen after start of timer) 47e460f
Sumukh Sridhara Quieted some NSLogs.
Made some non-critical NSLogs quiet down by commenting them out. They
should be uncommented if you are debugging.
8c641bb
Aristides Lourenco

@Sumukh can you provide a binary to test while this in not pulled into the main repo?

Charlie Stigler
Collaborator

Thanks for the work on this, and the other commits seem like good ideas. But this particular commit is buggy and will cause some issues if we merge it.

Can somebody clarify for me what this "freezing bug" is and why it was fixed by this? I don't think I've ever experienced this, but if it is an issue we should figure out how to fix it properly. If this commit does fix anything, it is because it inadvertently breaks a piece of the code that contains a bug.

Problems with this commit:

  • By moving the setBadgeLabel call inside the if(numSeconds > 0 && numMinutes != 59) statement, you've made it so that the badge will fail to update when the block has 59 minutes remaining or when the method is called at the top of a minute.
  • The clause to clear the badge label when we aren't using badging has been moved to the wrong scope. That else statement previously matched the higher level if statement. This means this statement will never be executed, and therefore the badge label will not be cleared when badging is turned off.

If you know where it's freezing, let me know and we can look for ways to fix it. I don't think this commit is a good response.

Sumukh Sridhara

I agree. There's definitely more work to be put in here, it was more of a hack than a fix. (It isn't even 100% fixed by this commit either).

There's a bit more information on the bug in issue #15. I'm going try again with this fix and try and identify where it crashes.

Charlie Stigler
Collaborator

Sounds good. If this bug is related specifically to 10.7 Lion, that would explain why I haven't seen it--I only have access to, and thus only test with, a computer running 10.6 right now.

Without any testing, I have a feeling about what the issue is. In the commit you submitted, as I mentioned, the misplacement of brackets broke the badge-clearing. It prevented the statement "[[NSApp dockTile] setBadgeLabel: @""];" from ever being run. So it seems like this statement might have something to do with the freeze. We also know that the issue is OS-version-dependent, which means it was probably an Apple API bug introduced with 10.7. My guess is that for some reason, in 10.7 there are issues with setting the badge label to an empty string in some cases. I can't test this since my computer is running the wrong OS, but you could try switching that to setBadgeLabel: nil (an equivalent statement) to see if that's a quick workaround for the bug. If not, we'll need a more involved workaround.

Sumukh Sridhara

Went a bit overboard and set all the setBadgeLabels to nil. (It should set the label only in < 10.7, If you're on lion, this version won't even set the badge.)

So far no crashes. Binary available here: http://sumukh.me/bxa0

Charlie Stigler
Collaborator

Hm, cool then, looks like that was the issue! Could you try changing it so only the ones where it was previously setting the label to @"" (the empty string) are switched to nil, and testing it that way? It sounds like that might still fix the bug (assuming the bug is that the API incorrectly handles empty strings in setBadge), and that way we don't break existing functionality.

Sumukh Sridhara

Yup, here is the binary. Still allows the badge to show up and it seemed to work. http://sumukh.me/10wq
Will upload the source soon, but there's not all that much to imagine. It's basically
if(isLion) {
[[NSApp dockTile] setBadgeLabel: badgeString];
//and :nil in the places where it clears.
}

Steve

Thanks for this. Good job guys! Will do some testing and report back in the ticket. Cheers :)

Jhering

http://sumukh.me/10wq
it's a with Badge version.
This selfcontrol is still polluting system.log.
The size of the system.log is increasing seconds by seconds,whatever i use it blocking.


Mar 4 16:04:58 JheringdeMacBook-Pro SelfControl[425]: Seconds left > 0 38
Mar 4 16:04:58 JheringdeMacBook-Pro SelfControl[425]: On Lion: Set BadgeString to BadgeString 38
Mar 4 16:04:58 JheringdeMacBook-Pro SelfControl[425]: On Lion: Set BadgeString to BadgeString: 00:01
Mar 4 16:04:59 JheringdeMacBook-Pro SelfControl[425]: set string numSeconds < 0 37
Mar 4 16:04:59 JheringdeMacBook-Pro SelfControl[425]: Resetting Strikes
Mar 4 16:04:59 JheringdeMacBook-Pro SelfControl[425]: Seconds left > 0 37
Mar 4 16:04:59 JheringdeMacBook-Pro SelfControl[425]: On Lion: Set BadgeString to BadgeString 37
Mar 4 16:04:59 JheringdeMacBook-Pro SelfControl[425]: On Lion: Set BadgeString to BadgeString: 00:01
Mar 4 16:05:00 JheringdeMacBook-Pro SelfControl[425]: set string numSeconds < 0 36
Mar 4 16:05:00 JheringdeMacBook-Pro SelfControl[425]: Resetting Strikes
Mar 4 16:05:00 JheringdeMacBook-Pro SelfControl[425]: Seconds left > 0 36
Mar 4 16:05:00 JheringdeMacBook-Pro SelfControl[425]: On Lion: Set BadgeString to BadgeString 36
Mar 4 16:05:00 JheringdeMacBook-Pro SelfControl[425]: On Lion: Set BadgeString to BadgeString: 00:01
Mar 4 16:05:01 JheringdeMacBook-Pro SelfControl[425]: set string numSeconds < 0 35
Mar 4 16:05:01 JheringdeMacBook-Pro SelfControl[425]: Resetting Strikes
Mar 4 16:05:01 JheringdeMacBook-Pro SelfControl[425]: Seconds left > 0 35
Mar 4 16:05:01 JheringdeMacBook-Pro SelfControl[425]: On Lion: Set BadgeString to BadgeString 35
Mar 4 16:05:01 JheringdeMacBook-Pro SelfControl[425]: On Lion: Set BadgeString to BadgeString: 00:01
Mar 4 16:05:02 JheringdeMacBook-Pro SelfControl[425]: set string numSeconds < 0 34
Mar 4 16:05:02 JheringdeMacBook-Pro SelfControl[425]: Resetting Strikes
Mar 4 16:05:02 JheringdeMacBook-Pro SelfControl[425]: Seconds left > 0 34
Mar 4 16:05:02 JheringdeMacBook-Pro SelfControl[425]: On Lion: Set BadgeString to BadgeString 34
Mar 4 16:05:02 JheringdeMacBook-Pro SelfControl[425]: On Lion: Set BadgeString to BadgeString: 00:01
.
.
.
.

Mar 4 16:07:13 JheringdeMacBook-Pro SelfControl[425]: on leopard Setting Badge Label to Nothing after completion -96
Mar 4 16:07:13 JheringdeMacBook-Pro SelfControl[425]: WARNING: Block should have ended four seconds ago, starting scheckup
Mar 4 16:07:13 JheringdeMacBook-Pro SelfControl[425]: Resetting Strikes
Mar 4 16:07:13 JheringdeMacBook-Pro SelfControl[425]: Running Checkup
Mar 4 16:07:14 JheringdeMacBook-Pro scheckup[903]: WARNING: SelfControl rules do not appear to be loaded into ipfw.
Mar 4 16:07:14 JheringdeMacBook-Pro [0x0-0x2b02b].org.eyebeam.SelfControl[425]: 2012-03-04 16:07:14.052 scheckup[903:707] WARNING: SelfControl rules do not appear to be loaded into ipfw.
Mar 4 16:07:14 JheringdeMacBook-Pro scheckup[903]: INFO: Block cleared.
Mar 4 16:07:14 JheringdeMacBook-Pro [0x0-0x2b02b].org.eyebeam.SelfControl[425]: 2012-03-04 16:07:14.201 scheckup[903:707] INFO: Block cleared.
Mar 4 16:07:14 JheringdeMacBook-Pro [0x0-0x2b02b].org.eyebeam.SelfControl[425]: launchctl: Error unloading: org.eyebeam.SelfControl
Mar 4 16:07:14 JheringdeMacBook-Pro [0x0-0x2b02b].org.eyebeam.SelfControl[425]: -215
Mar 4 16:07:14 JheringdeMacBook-Pro SelfControl[425]: on leopard Setting Badge Label to Nothing after completion -97
Mar 4 16:07:15 JheringdeMacBook-Pro SelfControl[425]: on leopard Setting Badge Label to Nothing after completion -98
Mar 4 16:07:16 JheringdeMacBook-Pro SelfControl[425]: on leopard Setting Badge Label to Nothing after completion -99
Mar 4 16:07:17 JheringdeMacBook-Pro SelfControl[425]: on leopard Setting Badge Label to Nothing after completion -100
Mar 4 16:07:17 JheringdeMacBook-Pro SelfControl[425]: WARNING: Block should have ended four seconds ago, starting scheckup
Mar 4 16:07:17 JheringdeMacBook-Pro SelfControl[425]: Resetting Strikes
Mar 4 16:07:17 JheringdeMacBook-Pro SelfControl[425]: Running Checkup
Mar 4 16:07:18 JheringdeMacBook-Pro scheckup[908]: WARNING: SelfControl rules do not appear to be loaded into ipfw.
Mar 4 16:07:18 JheringdeMacBook-Pro [0x0-0x2b02b].org.eyebeam.SelfControl[425]: 2012-03-04 16:07:18.052 scheckup[908:707] WARNING: SelfControl rules do not appear to be loaded into ipfw.
Mar 4 16:07:18 JheringdeMacBook-Pro scheckup[908]: INFO: Block cleared.
Mar 4 16:07:18 JheringdeMacBook-Pro [0x0-0x2b02b].org.eyebeam.SelfControl[425]: 2012-03-04 16:07:18.198 scheckup[908:707] INFO: Block cleared.
Mar 4 16:07:18 JheringdeMacBook-Pro [0x0-0x2b02b].org.eyebeam.SelfControl[425]: launchctl: Error unloading: org.eyebeam.SelfControl
Mar 4 16:07:18 JheringdeMacBook-Pro [0x0-0x2b02b].org.eyebeam.SelfControl[425]: -215
Mar 4 16:07:18 JheringdeMacBook-Pro SelfControl[425]: on leopard Setting Badge Label to Nothing after completion -101
Mar 4 16:07:19 JheringdeMacBook-Pro SelfControl[425]: on leopard Setting Badge Label to Nothing after completion -102
Mar 4 16:07:20 JheringdeMacBook-Pro SelfControl[425]: on leopard Setting Badge Label to Nothing after completion -103

Jhering

When i quit it using cmd+q, the world is quiet.
As far as i run it ,no matter it is countdowning, it will polluting my system.log, never be end........

Sumukh Sridhara

Yes. This is a known issue. (I used it to troubleshoot). It keeps checking after its done until you see the selection window.

Temporary fix (Don't know if it will work): If the timer is done then you can click on it and it should stop.

I'll quiet it up soon. (within a day)

Charlie Stigler
Collaborator

I'll quiet the system logs. That way I can also look at making them debug-only or perhaps logging some of them to another log file if they're important to the bugs we experience often. Could we just make this a pull request on 127.0.0.1 --> 0.0.0.0 and the setBadge fix, so I can merge it now?

Sumukh Sridhara

Does that work? Let me know if you'd like me to make changes.

The compiled version with this commit: http://sumukh.me/p2yS

Jhering

The version here :
The compiled version with this commit: http://sumukh.me/p2yS

Countdown still hangs on OS X 10.7 Lion. But the version before which polluted logs had been fixed this bug. (Issue here #15
Binary here http://sumukh.me/10wq)

Why?

henrik242

Any chance of getting http://sumukh.me/10wq without the pollution in Console Log? Anyway, thanks for fixing the timer bug :)

Steve

Is the fix confirmed? Then as henrik242 suggests, log pollution should be dealt with and maybe bump version number and make a release?

henrik242

The timer bug is gone for me, at least. But I have another issue now (with http://sumukh.me/p2yS, which doesn't have the log pollution): When the block time is over, the timer box remains with the text "Block not a". When I restart the timer, another timer box appears, and the old block is still present: http://dl.dropbox.com/u/1087529/selfcontrol.png

henrik242

There's something weird about the ipfw entries now. I have 20-30 hosts in /etc/hosts that point to 0.0.0.0, but ipfw list only shows this:

01500 457 235526 count ip from any to any // BEGIN SELFCONTROL BLOCK
01501 0 0 allow ip from any to any via lo*
01502 0 0 deny ip from me to 0.0.0.0
01503 0 0 deny ip from me to 69.63.176.0/20
01504 0 0 deny ip from me to 0.0.7.209 dst-port 67
01505 449 230094 count ip from any to any // END SELFCONTROL BLOCK

henrik242

Sorry for all the spam, but I discovered what was wrong: The ipfw list is correct when selfcontrol is started. If I add a host afterwards (by clicking "add to blacklist"), the ipfw list ends up like the above.

henrik242

Oh well. I managed to get the timer to stop both with http://sumukh.me/10wq and http://sumukh.me/p2yS. I'm using a one-hour countdown, and in the cases where it stops, it's usually around 0:59:50.

(I really should be working instead of updating issues. But blocking github would block me from working. Catch 22!)

Charlie Stigler
Collaborator

This should (finally) be resolved in our new 1.4 release. Please update to that and open another ticket if problems are still occurring.

Charlie Stigler cstigler closed this July 12, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Showing 4 unique commits by 2 authors.

Jan 31, 2012
Sumukh Sridhara Updated the block to go to 0.0.0.0 instead of 127.0.0.1 347c46b
Feb 03, 2012
Sumukh Sridhara Fixed bug (freezing of screen after start of timer) 47e460f
Sumukh Sridhara Quieted some NSLogs.
Made some non-critical NSLogs quiet down by commenting them out. They
should be uncommented if you are debugging.
8c641bb
Mar 04, 2012
Sumukh Sridhara Testing. Timer = Nil. 0.0.0.0 Commented out NSlogs 6a5d6a9
Something went wrong with that request. Please try again.