-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
segfault on debian buster calling ping after disconnect #151
Comments
Hello! With specifying |
I compiled DBD::MariaDB 1.21 with MariaDB 10.3.8 client and run your example script under valgrind to check for any memory corruption and also under gdb to see any suspicious problems:
But I was not able to reproduce any crash. Can you please specify exact version of MariaDB client which is causing segfault? Also can you provide valgrind and gdb output (for backtrace) of crash? |
Yes, I just copied the same test code I used for mysql. It broke with DBD::MariaDB in the same way. |
I reproduced this several times using mariadb on debian buster using the mariadb debian packages provided for buster for mariadb both 10.3 and 10.4 I've rebooted the VM and now it's refusing to segfault on an empty database, I suspect that you won't see this problem on a freshly booted clean install, then. I'm going to continue trying to reproduce, once I get it to happen again, I'll throw strace and gdb at it |
Hi! Have you able to reproduce this issue under gdb/valgrind with DBD::MariaDB? |
I've managed to replicate it in GDB with DBD::mysql, but since reinstalling DBD::MariaDB I've not been able to get it to segfault, even when the mysql dbd client is, so it requires a specific combination of packages in buster that I had earlier and haven't replicated since reinstalling various mariadb and mysql servers and clients :( |
Valgrind seems to prevent it happening, I was able to get it to fail with DBD::MariaDB initially with standard mariadb on buster without valgrind, it may be possible with GDB but I'd have to rebuild buster from scratch to replicate, and that's not worth my time at the moment |
Valgrind may prevent segfaults, but it prints stacktrace of any memory corruptions which could lead to segfaults. So it is still useful. I was trying to reproduce your reported issue on Debian 9.11 but I was not able. Even valgrind does not report any suspicious memory access. So please provide whole reproducer, exact versions of MariaDB client, MariaDB server, DBI module, DBD::MariaDB module and test script which is causing it, together with stacktrace of crash (either from valgrind or gdb). Because currently it looks like a glitch in setup as DBD::MariaDB is already tested on Travis with about 200 configurations of MariaDB client and server versions and there is no crash or failed test... https://travis-ci.org/gooddata/DBD-MariaDB |
@hashbangperl: I tried to reproduce this issue on Debian 10 Buster with MariaDB 10.3.18, but without success. There is no memory corruption, no crash. |
I see regular segfaults in a script where database connection times out between database accesses. The script issues db requests fine, then sleeps for extended periods. In these sleep()s db connection times out (as one can expect). And once the script tries to reconnect to db or does a ping() I get a segfault on next INSERT. It's reproducible. I use DBD::MariaDB through Dancer::Plugin:Database. (I've checked that it uses DBD::MariaDB and not the MySQL DBD.) D::P::Database has an auto-reconnect feature that triggers the segfault. I tried to remedy this by issuing a ping() more regularly and before any "next database operation" - the result is segfaults triggered by this ping() or shortly after. First I usually get a "MySQL server has gone away" message, although it's only the connection and server is still live. Then immediately or on the next operation I get a segfault. Here's a snippet from my script logs:
I'm aware of how annoying and unhelpful this report is, but I hope even a small "I've seen it as well" is of any help. I'm too noobish with stacktraces etc. to provide any dumps or so... sorry. $ cat /etc/issue |
I'm seeing an increase of segfaults on long-standing db-connections since I've upgraded MariaDB (via apt upgrade) from I've reinstalled/recompiled DBD::MariaDB against changed libs of the same apt upgrade, so that should be in sync. Also MariaDB is quickly filling errors.log with notes of: MariaDB aborted connection. Got an error reading communication packets |
Could you please provide gdb backtrace of the crash? I tried different test scenarios on Debian Buster but I was not able to trigger segfault. |
At least from my side: sorry, no. This feels like ages ago and I can't rebuild the same stack. But what I can say is I'm using MariaDB since then, and on a similar stack, and the error didn't come to my attention again. |
@hashbangperl: Are you able to reproduce this problem? |
I'm closing this issue as nobody was able to reproduce it for more years. |
Replicated with both MariaDB 10.3 and 10.4.
Will reliably get a segfault 1 in 2 to 1 in 4 times, when calling ping on a db handle after calling disconnect on it with latest DBD::MariaDB and mariadb 10.3 or 10.4 on debian buster, likely to be same on debian stretch. This was with auto_reconnect flag set.
my $dbh = DBI->connect("dbi:mysql:$dbname;host=localhost",$user, $password);
$dbh->disconnect();
ok( ! $dbh->ping(), 'dbh is disconnected and did not segv');
done_testing();
The text was updated successfully, but these errors were encountered: