2

I recently made the switch from Ubuntu to OSX. Now I cannot run RSpec tests anymore, even though it worked on Ubuntu.

The first testcase will always return:

Failure/Error: @match.save!
 ActiveRecord::StatementInvalid:
   Mysql2::Error: MySQL server has gone away: ROLLBACK TO SAVEPOINT active_record_1

Then every testcase thereafter:

Failure/Error: Unable to find matching line from backtrace
 Mysql2::Error:
   Can't connect to local MySQL server through socket '/tmp/mysql.sock' (61)

My database.yml just connects to the DB via socket /tmp/mysql.sock. Setting reconnect:truemakes no difference.

I installed mysql via homebrew. I also already re-installed it as mentioned here to make sure it's not a problem of the mysql installation.

I also increased the mysql max_allowed_packet as suggested here (I tried up to 4096M and verified the setting using show variables like 'max_allowed_packet', but still no success.

Setting use_transactional_fixtures:false as suggested here and using Database Cleaner did not help either.

Update

I narrowed the problem down to only affect test cases using before_save triggers in the model. When triggering an affected method in development mode the same problem occurs:

Mysql2::Error: Lost connection to MySQL server during query: UPDATE ...

Meanwhile I also removed the homebrew mysql server and installed the one from the official website - without any luck.

Here is the mysql error log, which looked similar for both mysql server versions (official+homebrew): Gist

Update II

Following is the problematic statement. I can also run it in isolation in the MySQL console and it will reliable crash the server:

UPDATE bets SET points = 2 WHERE betsession_id IN (1, 3, 5, 7, 10, 16, 31, 33, 35, 39, 42, 44, 49, 50, 56, 58, 61) AND match_id = 1583 AND (home_score = guest_score) AND (home_score = 2 OR home_score = 0);

I can strip it down to

UPDATE bets SET points = 2 WHERE (home_score = guest_score);

which sometimes crashes the server. Adding the AND (home_score = 0 OR home_score = 2) will however reliably lead to a crash. Any of the 2 WHERE conditions in isolation tend to work well. Is there some kind of internal memory buffer that I need to increase?

Community
  • 1
  • 1
emrass
  • 5,885
  • 3
  • 30
  • 57
  • Ps: I'm not altering the DB schema in my tests, so http://stackoverflow.com/questions/13161394/activerecord-error-savepoint-active-record-1-does-not-exist is not relevant for me. – emrass Jun 15 '14 at 09:38
  • have you tried increasing [net_read_timeout](https://dev.mysql.com/doc/refman/5.0/en/server-system-variables.html#sysvar_net_read_timeout)? – FuzzyTree Jun 20 '14 at 07:37
  • @FuzzyTree: I can try this at home, but am not too confident that it will help. (1) The result set is very small (only about 20 records for the test) and should return instantly. (2) From the documentation: `This timeout applies only to TCP/IP connections, not to connections made through Unix socket files` – emrass Jun 20 '14 at 13:35
  • @FuzzyTree net_read_timeout is set to the default of 30s. However, the operation fails instantly - without any wait time. Same problem when using TCP connection instead of socket. – emrass Jun 20 '14 at 22:15
  • Could you try to run `shell> telnet 3306`. If you are not able to login then your port is closed. Also check your DNS settings and following link: http://stackoverflow.com/questions/6770751/lost-connection-to-mysql-server-at-reading-initial-communication-packet-syste . It also could be a permission problem: http://stackoverflow.com/questions/16325607/cant-connect-to-local-mysql-server-through-socket-tmp-mysql-sock – GuyT Jun 23 '14 at 07:27
  • Thanks for your hints @GuyT - I can connect via TCP, port is open. The other 2 links were of no help, either :-( The server starts well and behaves as expected - except for the specific operation where the connection dies ... – emrass Jun 23 '14 at 19:29
  • 1
    Yep, did that @Unihedron - it's just a general page and not specific to the error. In addition I already know the statement that makes mysql crash, so the information there is of no help for me – emrass Jun 24 '14 at 12:04

1 Answers1

2

I can tell from the posted log it is an internal error which causes the connection to close and not a connection problem. So focus on the server itself and not the connection.

UPDATE: It seems like a bug in 5.6. Try Downgrading

Alireza
  • 4,683
  • 1
  • 21
  • 34
  • Thanks @Alireza - that's what I think as well. As mentioned - I tried Homebrew + official mysql.com version; both having the same issue. Maybe it's a library used in the build process? Any hint is greatly appreciated. Note that there's a 1 day grace period to assigning the bounty - so I could assign it even after it runs out in 3h. – emrass Jun 24 '14 at 08:08
  • Can you guess which test is failing and the command being executed? It seems to be a bug. – Alireza Jun 24 '14 at 08:38
  • If I recall correctly, it's an `UPDATE xy SET a = B WHERE id IN (c, d, e, ...)` statement. Nothing too fancy, really. I can post the actual statement when I'm at home in about 8h. I'm almost certain that this is not a general bug but limited to my machine. When at home I will try to run the statement sequence manually in the mysql client and see if that crashes the server as well. – emrass Jun 24 '14 at 09:19
  • That's even better for me cause I'll be at home too. – Alireza Jun 24 '14 at 09:24
  • 1
    But I still think it could be a general bug. – Alireza Jun 24 '14 at 09:24
  • Updated with the problematic statement in my question above. The statement is so common that I doubt it can be a general bug. Any ideas? Thanks! – emrass Jun 24 '14 at 19:53
  • Sorry but I think I didn't understand your update. You say it crashes the server even when run from the console? – Alireza Jun 24 '14 at 19:58
  • Yes - in contrast to "only in the application", which issues several statements in a sequence – emrass Jun 24 '14 at 20:16
  • Can you start removing the conditions one-by-one and see if maybe one of them is causing the error? – Alireza Jun 24 '14 at 20:23
  • I was able to narrow it down further - please have a look in the question. Any suggestion what to look at and I'll gladly assign the bounty as a big THANKS for your time and engagement. – emrass Jun 24 '14 at 20:24
  • I'm now just curious for the answer, not the bounty :) – Alireza Jun 24 '14 at 20:28
  • It seems to me like an overflow or something like that related to the data. Try putting an `AND 1=0` at the end of your query. Still crashing? – Alireza Jun 24 '14 at 20:29
  • Great attitude! :) Please see update above. When adding 1=0 -> no more crash! I think we are getting there ... Do you know which config setting to increase? – emrass Jun 24 '14 at 20:34
  • I think when adding `AND 1=0` the optimizer optimizes aways the whole WHERE statement - so that might be misleading. EXPLAIN .... then shows `impossible WHERE` – emrass Jun 24 '14 at 20:39
  • I'm trying to rule out the problem with your data. Will something like this still crash? `SELECT bets FROM table WHERE (home_score = guest_score);` – Alireza Jun 24 '14 at 20:47
  • Nope, no crash for the `SELECT * FROM bets WHERE ...` – emrass Jun 24 '14 at 20:54
  • Let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/56231/discussion-between-alireza-and-emrass). – Alireza Jun 24 '14 at 20:57
  • Problem now yet solved, unfortunately. Assigning the Bounty because it runs out and @Alireza invested a lot of time and effort to make some progress on getting this resolved. Thanks! – emrass Jun 24 '14 at 21:16
  • After all, you might have been right from the beginning. I downgraded from mysql 5.6.19 to 5.5.29 -> now it works without a flaw. If you put something like "This is a mysql error -> try downgrade to 5.5.x" in your answer, I will accept it. – emrass Jun 24 '14 at 22:43
  • I am so happy that it is solved and will put that in the answer. After all I actually did nothing much, just some pointers based on the logs. You solved the problem :) – Alireza Jun 25 '14 at 05:37