GNOME Bugzilla – Bug 729443
Segmentation fault on saving tag to OGG file
Last modified: 2014-05-04 09:42:34 UTC
Not sure when this regression occurred as I have not used easytag for some time. Anyway, there are certain ogg files that it does not want to edit, and it crashes instantly with a segmentation fault when I try to save the tags. I am unsure what it is about the files - initially I thought it was that the tags contained Chinese, Japanese, or Korean characters, but I have a few files that should be pure 7-bit ASCII that are also causing easytag to crash. It works fine with mp3 files. I'm currently running 2.2.1 in Arch Linux.
Thanks for taking the time to report this bug. Without a stack trace from the crash it's very hard to determine what caused it. Can you get us a stack trace? https://wiki.gnome.org/Community/GettingInTouch/Bugzilla/GettingTraces for more information on how to do so. Thanks in advance!
After rebuilding from source to get the debug symbols, this is what I get from gdb: GNU gdb (GDB) 7.7 Copyright (C) 2014 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 "x86_64-unknown-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. 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 easytag...(no debugging symbols found)...done. (gdb) run Starting program: /usr/bin/easytag warning: Could not load shared library symbols for linux-vdso.so.1. Do you need "set solib-search-path" or "set sysroot"? warning: File "/usr/lib/libstdc++.so.6.0.19-gdb.py" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load". To enable execution of this file add add-auto-load-safe-path /usr/lib/libstdc++.so.6.0.19-gdb.py line to your configuration file "/home/alex/.gdbinit". To completely disable this security protection add set auto-load safe-path / line to your configuration file "/home/alex/.gdbinit". For more information about this security protection see the "Auto-loading safe path" section in the GDB manual. E.g., run from the shell: info "(gdb)Auto-loading safe path" [Thread debugging using libthread_db enabled] Using host libthread_db library "/usr/lib/libthread_db.so.1". [New Thread 0x7fffeb0b5700 (LWP 16278)] [New Thread 0x7fffdbfa1700 (LWP 16280)] [New Thread 0x7fffdb7a0700 (LWP 16281)] [New Thread 0x7fffdaf9f700 (LWP 16282)] [Thread 0x7fffdaf9f700 (LWP 16282) exited] Program received signal SIGSEGV, Segmentation fault. 0x00007ffff4406c6a in strlen () from /usr/lib/libc.so.6 (gdb) thread apply all bt
+ Trace 233546
Thread 1 (Thread 0x7ffff7f8e900 (LWP 16274))
A debugging session is active. Inferior 1 [process 16274] will be killed. Quit anyway? (y or n) y
Thanks for the stack trace. However, that trace is missing line numbers, and those are quite important for solving this bug. Can you ensure that full debugging symbols are included, so that you get line numbers in the stack trace?
I thought they were. What do I need to do to enable full debug symbols?
You probably need to add "-g" or "-ggdb" to the CFLAGS and CXXFLAGS when compiling EasyTAG.
Alright, here is what I get now: GNU gdb (GDB) 7.7 Copyright (C) 2014 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 "x86_64-unknown-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. 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 ./easytag...done. (gdb) run Starting program: /home/alex/sources/easytag/src/easytag-2.2.1/easytag warning: Could not load shared library symbols for linux-vdso.so.1. Do you need "set solib-search-path" or "set sysroot"? warning: File "/usr/lib/libstdc++.so.6.0.19-gdb.py" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load". To enable execution of this file add add-auto-load-safe-path /usr/lib/libstdc++.so.6.0.19-gdb.py line to your configuration file "/home/alex/.gdbinit". To completely disable this security protection add set auto-load safe-path / line to your configuration file "/home/alex/.gdbinit". For more information about this security protection see the "Auto-loading safe path" section in the GDB manual. E.g., run from the shell: info "(gdb)Auto-loading safe path" [Thread debugging using libthread_db enabled] Using host libthread_db library "/usr/lib/libthread_db.so.1". [New Thread 0x7fffeb0b5700 (LWP 23367)] [New Thread 0x7fffdbfa1700 (LWP 23368)] [New Thread 0x7fffdb7a0700 (LWP 23369)] [New Thread 0x7fffdaf9f700 (LWP 23370)] [Thread 0x7fffdb7a0700 (LWP 23369) exited] Program received signal SIGSEGV, Segmentation fault. 0x00007ffff379ac6a in strlen () from /usr/lib/libc.so.6 (gdb) thread apply all bt
+ Trace 233547
Thread 1 (Thread 0x7ffff7f8d900 (LWP 23363))
A debugging session is active. Inferior 1 [process 23363] will be killed. Quit anyway? (y or n) y
Thanks! That suggests that the image description is unset, and that strlen() is being called on a NULL string. Do you have a copy of the file that causes EasyTAG to crash, which you could send me by private email?
Sent.
I just pushed a patch which fixes the problem for me, to the master and easytag-2-2 branches, as 7542ad103a7280d783de5379f9214d61472e92f9 and dc074036a1ec1217fdd1e9a942e7e120e7523b84. The fix will be in an upcoming 2.2.2 release, due in the next week or so, and you can apply the patch to your local version until then: https://git.gnome.org/browse/easytag/commit/?h=easytag-2-2&id=dc074036a1ec1217fdd1e9a942e7e120e7523b84