on my gentoo machine, mytop 1.9.1 quits upon invocation with the following output:
# mytop
Useless use of private variable in void context at /usr/bin/mytop line 1001.
"my" variable $data masks earlier declaration in same scope at /usr/bin/mytop line 1035.
Errore di segmentazione
as far as I can understand, mytop is a Perl script (the tool is effectively readable via command vi /usr/bin/mytop), so I tried to update all perl subdependencies (as stated on https://wiki.gentoo.org/wiki/Perl), but that didn't solve the problem.
Then I also tried:
- downgrading to mytop 1.6-r4 (which is reported as stable on portage), same result: segmentation fault
- installing innotop 1.12.0 (which is a similar tool), same result: segmentation fault
Since the same problem pops out with two different tools, being suggested in comments to use a specific tool, I ran perl via gdb, then launched mytop backtracing the output with bt, here's the output:
# gdb /usr/bin/perl
GNU gdb (Gentoo 8.1 p1) 8.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://bugs.gentoo.org/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/perl...(no debugging symbols found)...done.
(gdb) run /usr/bin/mytop
Starting program: /usr/bin/perl /usr/bin/mytop
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/libthread_db.so.1".
Useless use of private variable in void context at /usr/bin/mytop line 1001.
"my" variable $data masks earlier declaration in same scope at /usr/bin/mytop line 1035.
Program received signal SIGSEGV, Segmentation fault.
0xb731511c in EVP_CIPHER_CTX_init () from /usr/lib/libcrypto.so.1.0.0
(gdb) bt
#0 0xb731511c in EVP_CIPHER_CTX_init () from /usr/lib/libcrypto.so.1.0.0
#1 0xb75563f6 in my_aes_decrypt () from /usr/lib/libmysqlclient.so.18
#2 0xb75521eb in ?? () from /usr/lib/libmysqlclient.so.18
#3 0xb75527c4 in ?? () from /usr/lib/libmysqlclient.so.18
#4 0xb75529ec in my_search_option_files () from /usr/lib/libmysqlclient.so.18
#5 0xb7553406 in my_load_defaults () from /usr/lib/libmysqlclient.so.18
#6 0xb7512e14 in mysql_read_default_options () from /usr/lib/libmysqlclient.so.18
#7 0xb751a56d in mysql_real_connect () from /usr/lib/libmysqlclient.so.18
#8 0xb78a013c in mysql_dr_connect () from /usr/lib/perl5/vendor_perl/5.24.3/i686-linux/auto/DBD/mysql/mysql.so
#9 0xb78a25ea in ?? () from /usr/lib/perl5/vendor_perl/5.24.3/i686-linux/auto/DBD/mysql/mysql.so
#10 0xb78a26c7 in mysql_db_login () from /usr/lib/perl5/vendor_perl/5.24.3/i686-linux/auto/DBD/mysql/mysql.so
#11 0xb78ade8c in ?? () from /usr/lib/perl5/vendor_perl/5.24.3/i686-linux/auto/DBD/mysql/mysql.so
#12 0xb7e92b04 in Perl_pp_entersub () from /usr/lib/libperl.so.5.24
#13 0xb7e8b043 in Perl_runops_standard () from /usr/lib/libperl.so.5.24
#14 0xb7e12a02 in Perl_call_sv () from /usr/lib/libperl.so.5.24
#15 0xb78cfd13 in XS_DBI_dispatch () from /usr/lib/perl5/vendor_perl/5.24.3/i686-linux/auto/DBI/DBI.so
#16 0xb7e92b04 in Perl_pp_entersub () from /usr/lib/libperl.so.5.24
#17 0xb7e8b043 in Perl_runops_standard () from /usr/lib/libperl.so.5.24
#18 0xb7e1a6cb in perl_run () from /usr/lib/libperl.so.5.24
#19 0x00400a67 in main ()
(gdb)
Almost the exact output comes when debugging innotop the same way, so upon suggestion from a friend in gentoo forum, I tried to rebuild from scratch perl, mysql and openssl (which all seemed to be involved in the segfault somehow), but that didn't help neither.
I think debugging via gdb's output might be resolutive, but I really don't know how to proceed (never had to deal with it before)
strace -f
to see who is segfaulting. Also, the last few messages indmesg
might also tell you which binary is segfaulting (probably easier to do this than usingstrace
if you haven't installed it yet, but you'll get less information).