search

bdreager / PyClock

A digital clock for the terminal
MIT License
5 stars 3 forks source link

Terminal resize crashes curses on OSX #7

Closed bdreager closed 8 years ago

bdreager commented 8 years ago

Seen on El Capitan.

livibetter commented 8 years ago

I don't have OS X, but what's the thrown exception?

bdreager commented 8 years ago

There is no exception that I can find. The script just ends as if esc or q were pressed.

I've tested it a little and I think it might be because the output is on separate thread. I'm hoping to put it all on one thread eventually.

livibetter commented 8 years ago

On Fri, Jan 29, 2016 at 7:24 AM, Brandon Dreager notifications@github.com wrote:

There is no exception that I can find. The script just ends as if esc or q were pressed.

Is always reproducible? and How did you know it crash? Exit status?

bdreager commented 8 years ago

Is always reproducible?

Always. It's guaranteed to happen if the terminal is resized.

Exit status?

Just checked. Exit code is 0, so I guess it's not a crash. Really strange in that case.

livibetter commented 8 years ago

Wish I had OS X to have fun with this bug.

Is always reproducible?

Always. It's guaranteed to happen if the terminal is resized.

Probably in resizing stuff and may be causing something else to actually trigger the unexpected exit.

Exit status?

Just checked. Exit code is 0, so I guess it's not a crash. Really strange in that case.

It might still is a crash, I remember seeing exceptions are passed somewhere in the code, if that's the case.

bdreager commented 8 years ago

Probably in resizing stuff

It was actually a problem before any of the resize stuff was added, if that's what you mean. All the way back with 949f77525e1616be55f6cac400557f568529643e

Stopping and restarting the driver on window resize keeps the script from exiting, which is why I think it might be related to using a thread for output.

livibetter commented 8 years ago

On Fri, Jan 29, 2016 at 8:21 AM, Brandon Dreager notifications@github.com wrote:

It was actually a problem before any of the resize stuff was added, if that's what you mean. All the way back with 949f775

Stopping and restarting the driver on window resize keeps the script from exiting, which is why I think it might be related to using a thread for output.

I don't know much about threading, but it might be the time to bring in a big gun, some threading-supported debugger 1 to find out when and how this happens.

By the way, have you tried to comment out the try block in Driver's run? I am thinking there must be an exception, no way the process can exit with 0. Somehow, I am guessing that clock's stdscr has gone invalid. If we had ridiculously intensive logging for a small clock, we can see where goes wrong more, but that's just bonkers.

bdreager commented 8 years ago

By the way, have you tried to comment out the try block in Driver's run?

That did the trick: On window resize getch was returning something that keyname couldn't parse.

The fix is embarrassingly simple.

https://mail.python.org/pipermail/python-list/2002-November/123036.html

livibetter commented 8 years ago

By the way, have you tried to comment out the try block in Driver's run?

That did the trick: On window resize getch was returning something that keyname couldn't parse.

The fix is embarrassingly simple.

I regretted asking that, should have let you go for days, scratching head, pulling hairs till bald, trying to figure out how to use the debugger for the threads and finally came to determine the same cause.

Just kidding. Glad everything sorted out and we can move on.