Developer#134: New crash in r2134 (connection locking during keepalive)
| Type: | Crash | First reported: | 19 Apr 2010 |
| Status: |  Fixed |
Last modified: | 3 Jul 2011 |
| Occurrences: | 1 | Fixed: | In revision r3347 |
Thread 10 Crashed:
0 libSystem.B.dylib 0x00007fff8897f01e __semwait_signal_nocancel + 10
1 libSystem.B.dylib 0x00007fff8897ef20 nanosleep$NOCANCEL + 129
2 libSystem.B.dylib 0x00007fff889db902 usleep$NOCANCEL + 57
3 libSystem.B.dylib 0x00007fff889faeb8 abort + 93
4 libSystem.B.dylib 0x00007fff88912a75 free + 128
5 ...ogle.code.sequel-pro.mcpkit 0x0000000100383a5b mysql_close + 235
6 ...ogle.code.sequel-pro.mcpkit 0x00000001003860db mysql_reconnect + 539
7 ...ogle.code.sequel-pro.mcpkit 0x0000000100386d3b cli_advanced_command + 635
8 ...ogle.code.sequel-pro.mcpkit 0x0000000100366061 mysql_ping + 49
9 ...ogle.code.sequel-pro.mcpkit 0x000000010035af09 pingConnectionTask + 9
10 libSystem.B.dylib 0x00007fff889458b6 _pthread_start + 331
11 libSystem.B.dylib 0x00007fff88945769 thread_start + 13Comments
view a table
it seems that Sequel Pro was busy pinging the connection (for keepalive), while clicking on a table name caused a second ping to be fired (for checking if the connection is still alive)
this is possible because we don't lock the connection during the keepalive ping. maybe we should. (a keepalive ping usually doesn't take long. if it does, there's a problem anyway, and hangs are unavoidable)
this is possible because we don't lock the connection during the keepalive ping. maybe we should. (a keepalive ping usually doesn't take long. if it does, there's a problem anyway, and hangs are unavoidable)
Title changed to "New crash in r2134 (connection locking during keepalive)".