GNOME Bugzilla – Bug 791229
Crash under enchant_broker_list_dicts()
Last modified: 2017-12-07 03:20:21 UTC
Created attachment 364962 [details] GDB dump Creating or Replying to an email causes Segfault GDB dump attached
Thanks for a bug report. I do not see any such crash here. What is the version of evolution, please? As the below part of the backtrace shows, it's crashing under enchant library. What is the version of enchant, please? Could it be due to certain dictionary being used and/or installed? You can find which are enabled n Edit->Preferences->Composer Preferences->Spell Checking tab. You might need to install debugging information at least for evolution and enchant, to have usable backtrace with line numbers and such. > Thread 1 (Thread 0x7ffff7f6da00 (LWP 22854)): > #0 0x00007ffff2ae3fd1 in free () at /usr/lib/libc.so.6 > #1 0x00007ffff614e97a in g_strfreev () at /usr/lib/libglib-2.0.so.0 > #2 0x00007fffe897e67c in enchant_broker_list_dicts () at /usr/lib/libenchant.so.2
Hi Milan and thank you for your follow up. Evolution: 3.26.2 Enchant: International Ispell Version 3.1.20 (but really Enchant 2.1.2) It started within the last 3 days which is also when this version came into production on Arch. Interestingly it crashes when trying to access the Preferences dialogue and still seems to point to enchant based on the attached gdb2 output. I tried launching with --disable-eplugin yet this too crashes. Same with --disable-preview. As a simple try - I reinstalled Enchant & Aspell, no improvement. Some minor testing of enchant at the command line produces no errors. I do not see a debug version with symbols list available in the Arch or AUR repos. If you'll please advise how I can produce what more you may need.
Created attachment 365020 [details] GDM dump 2 GDB dump on access preferences menu
I'm sorry, but I do not know Arch Linux, but they surely have packages with debug information. Could be it evolution.dbg or similar? Enchant package as such, the latest release is 1.6.0, which is several years old: https://www.abisource.com/downloads/enchant/1.6.0/ That's at least the version Fedora uses. That evolution crashes also when entering the Edit->Preferences makes sense, a similar/the same code to get list of available dictionaries is used there. According to the backtrace, and it would really need the debug information, it shows that your /usr/lib/libenchant.so.2 crashed when it had been called with enchant_broker_list_dicts(). That other applications do not crash can be due to they are not calling this particular function. I'm afraid this is an issue of the Arch Linux enchant. Do you know where they got it from, please? I can have a look, if I'd have the sources of it.
Hi Milan, Thank you again. I did look for *.dbg releases so at the moment I'll continue to try to locate same. Informationally here are the repo details: https://www.archlinux.org/packages/?q=evolution https://www.archlinux.org/packages/extra/x86_64/enchant/ There's probably a separate repo with debugging versions, I'll just have to find it. You'll note that enchant version is much more recent than yours and likely the cause. The upstream source is direct from the Github repo which also has much more current releases than the 1.6.0 currently in use by Fedora. Here the Github link: https://github.com/AbiWord/enchant It sounds like we're definitely close to the culprit being changes on versions of Enchant release. I'll try to install something older and revert my findings.
Created attachment 365032 [details] enchnt.c (In reply to mets_web from comment #5) > Here the Github link: > https://github.com/AbiWord/enchant I tried with enchant 2.1.2, but no luck, no crash here. Could you try with this attachment, where the first line contains a command to compile and run it, please? It can be that certain dictionary is causing the crash.
Thanks for trying the newer release. Shame it wasn't that easy. Results of your request: [mtompkins@nuc2 Git]$ mkdir tmp [mtompkins@nuc2 Git]$ cd tmp/ [mtompkins@nuc2 tmp]$ nano enchnt.c [mtompkins@nuc2 tmp]$ gcc `pkg-config --cflags --libs enchant` enchnt.c -g -O0 -o enchnt && ./enchnt *** Error in `./enchnt': free(): invalid pointer: 0x000055c968e1a4b0 *** Aborted (core dumped)
(In reply to mets_web from comment #7) > Thanks for trying the newer release. Shame it wasn't that easy. No problem, except it works fine for me, but crashes for you. > *** Error in `./enchnt': free(): invalid pointer: 0x000055c968e1a4b0 *** > Aborted (core dumped) Nice, thus it's in enchant itself or in one of the dictionaries you've installed, nothing what evolution would fix on its own (except of not calling that particular function, but that's not an option). I see that your enchant contains some patch, which looks related: https://git.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/enchant Having debug symbols installed you might get better idea where exactly it crashed. Or try to update enchant to 2.1.2-2, which contains that fix: https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/enchant&id=9dcc59d738816453bb9311468a2ce8415b123748
I can push that patch through easiest - will do and revert. Understood RE: Evolution itself. Based on that if you believe proper to close this ticket I'll understand.
(In reply to mets_web from comment #9) > I can push that patch through easiest - will do and revert. It depends whether you have enchant with that patch included installed or not. > Understood RE: Evolution itself. Based on that if you believe proper to > close this ticket I'll understand. I already closed it, but feel free to update this bug report. I'll try to help where I'll be able to.
Informationally (and sadly) I do have the patch - I'm current with 2.1.2-2 [1.6 is still used by gnucash apparently) [mtompkins@nuc2 tmp]$ pacaur -Q | grep enchant enchant 2.1.2-2 enchant1.6 1.6.1-3
Adding this as a reference: [mtompkins@nuc2 tmp]$ enchant-lsmod zemberek (Zemberek Provider) hspell (Hspell Provider) aspell (Aspell Provider) voikko (Voikko Provider) myspell (Myspell Provider) hunspell (Hunspell Provider) hspell (Hspell Provider) voikko (Voikko Provider) aspell (Aspell Provider)
Mine list is shorter (and without duplicates): $ enchant-lsmod hspell (Hspell Provider) hunspell (Hunspell Provider) aspell (Aspell Provider) Those duplicates on your machine are suspicious.
Agreed and was hoping you'd be so kind as to compare. I'm trying to pare back the providers. Duplicates are going to be a little harder to mitigate I'm expecting . . .
(In reply to mets_web from comment #14) > Agreed and was hoping you'd be so kind as to compare. I'm trying to pare > back the providers. Duplicates are going to be a little harder to mitigate > I'm expecting . . . Actually the dupes might make sense in retrospect - 2 versions of enchant installed?
(In reply to mets_web from comment #15) > Actually the dupes might make sense in retrospect - 2 versions of enchant > installed? Yes, maybe it's the reason. It would make sense. (Though I'd expect enchant-2-lsmod or anything like that.)
Compiled enchant 2.1.2-2 with debug symbols (I believe). Ran your test and captured result: (Also ran through Evolution with similar) Starting program: /home/mtompkins/Git/tmp/enchnt [Thread debugging using libthread_db enabled] Using host libthread_db library "/usr/lib/libthread_db.so.1". Program received signal SIGABRT, Aborted. 0x00007ffff762b8a0 in raise () from /usr/lib/libc.so.6
+ Trace 238228
Thread 1 (Thread 0x7ffff7fab740 (LWP 29423))
Seems to be caused by legacy enchant1.6 packages co-installed for ancient software that hasn't been ported to enchant 2 and cannot be compiled with the system enchant 2 library at all. As the plugins are stored in the same unversioned libdir as the primary enchant version, this is probably not very healthy for enchant itself. ;)
Thanks @Eli. Adding a reference to the AUR:GNUCash comments here as it is the legacy enchant cause at the moment. https://aur.archlinux.org/packages/gnucash/
(In reply to mets_web from comment #17) > Compiled enchant 2.1.2-2 with debug symbols (I believe). Thanks, it looks much better. I guess the error it prints after this, when you "continue" in gdb, is about freeing already freed memory or anything like that. Could you run the test application under valgrind, which will eventually show where the memory had been freed, please? The command is like this: $ G_SLICE=always-malloc valgrind --num-callers=30 ./enchnt (In reply to mets_web from comment #19) > Adding a reference to the AUR:GNUCash comments here as it is the legacy > enchant cause at the moment. Does it also mean that if you uninstall gnucash, thus also the older enchant, then the crash will be gone?
Will do at my first opportunity. ATM I'm compiling WebKitGTK (takes hours) trying to remove the dependency on the older enchant for GNUCash in hopes that it simply removes the legacy from the equation.
Output from valgrind [mtompkins@nuc2 enchant]$ SLICE=always-malloc valgrind --num-callers=30 ./enchnt ==3043== Memcheck, a memory error detector ==3043== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==3043== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info ==3043== Command: ./enchnt ==3043== ==3043== Invalid free() / delete / delete[] / realloc() ==3043== at 0x4C2E14B: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==3043== by 0x4E3D67B: enchant_broker_list_dicts (in /usr/lib/libenchant.so.2.1.2) ==3043== by 0x108847: main (enchnt.c:22) ==3043== Address 0x1fff0003a0 is on thread 1's stack ==3043== in frame #1, created by enchant_broker_list_dicts (???:) ==3043== ==3043== Invalid free() / delete / delete[] / realloc() ==3043== at 0x4C2E14B: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==3043== by 0x5876979: g_strfreev (in /usr/lib/libglib-2.0.so.0.5400.0) ==3043== by 0x4E3D67B: enchant_broker_list_dicts (in /usr/lib/libenchant.so.2.1.2) ==3043== by 0x108847: main (enchnt.c:22) ==3043== Address 0x1b is not stack'd, malloc'd or (recently) free'd ==3043== ==3043== Invalid read of size 8 ==3043== at 0x4E3D690: enchant_broker_list_dicts (in /usr/lib/libenchant.so.2.1.2) ==3043== by 0x108847: main (enchnt.c:22) ==3043== Address 0x1002001b60 is 0 bytes inside a block of size 80 in arena "core" ==3043== ==3043== Invalid read of size 1 ==3043== at 0x4E3D694: enchant_broker_list_dicts (in /usr/lib/libenchant.so.2.1.2) ==3043== by 0x108847: main (enchnt.c:22) ==3043== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==3043== ==3043== ==3043== Process terminating with default action of signal 11 (SIGSEGV): dumping core ==3043== Access not within mapped region at address 0x0 ==3043== at 0x4E3D694: enchant_broker_list_dicts (in /usr/lib/libenchant.so.2.1.2) ==3043== by 0x108847: main (enchnt.c:22) ==3043== If you believe this happened as a result of a stack ==3043== overflow in your program's main thread (unlikely but ==3043== possible), you can try to increase the size of the ==3043== main thread stack using the --main-stacksize= flag. ==3043== The main thread stack size used in this run was 8388608. ==3043== ==3043== HEAP SUMMARY: ==3043== in use at exit: 190,956 bytes in 660 blocks ==3043== total heap usage: 3,906 allocs, 3,249 frees, 493,543 bytes allocated ==3043== ==3043== LEAK SUMMARY: ==3043== definitely lost: 32 bytes in 1 blocks ==3043== indirectly lost: 0 bytes in 0 blocks ==3043== possibly lost: 1,352 bytes in 18 blocks ==3043== still reachable: 189,572 bytes in 641 blocks ==3043== of which reachable via heuristic: ==3043== newarray : 1,784 bytes in 17 blocks ==3043== suppressed: 0 bytes in 0 blocks ==3043== Rerun with --leak-check=full to see details of leaked memory ==3043== ==3043== For counts of detected and suppressed errors, rerun with: -v ==3043== ERROR SUMMARY: 5 errors from 4 contexts (suppressed: 0 from 0) Segmentation fault (core dumped)
So it looks like one of the dictionaries is returning nonsense, or a memory which was not allocated properly. Interestingly, the line numbers from backtrace at coment #17 do not match the sources I've downloaded and you seem to have lost debuginfo again. If you happen to have debuginfo and make a similar bactrace as that at the comment #17, then you can do in gdb: (gdb) f 6 (gdb) p g_module_name (provider->enchant_private_data) (gdb) p (*provider->identify) (provider) (gdb) p (*provider->describe) (provider) where the "f 6", switches context to the frame 6, which is the one with enchant_broker_list_dicts() call, where the 'provider' variable is available. You'll see which provider causes the trouble, though I briefly checked the code and I do not see any obvious issue in those built-in providers. I do not know whether it'll help, especially because I tend to agree with Eli's comment #18.
I came across this sed use while trying to build webkitgtk: sed -i s,enchant_dict_free_suggestions,enchant_dict_free_string_list,g \ Source/WebCore/platform/text/enchant/TextCheckerEnchant.cpp so my guess is that is the culprit somewhere in the v1.x series. I'm still trying to compile a 2.x series that can be used in Gnucash to confirm if this is remedied later. Thank you again for trying so hard to help overcome this. I'll revert more findings as I stumble across and advise on the gdb when I can.
So I can confirm that after a truly remarkable amount of compiling and effort, the cause was indeed the legacy enchant1.6. Once removed evolution is functioning as expected. Thank you again, everyone, for helping with this issue.
Contextual context stuff: The bugreport filed to Arch's bugtracker: https://bugs.archlinux.org/task/56597 ==> closed, our packages work fine elsewhere indicating the issue is specific to the OP's environment, e.g. enchant1.6/gnucash The enchant1.6 package now expects plugins in /usr/lib/enchant1.6/, see https://aur.archlinux.org/packages/enchant1.6/ and https://aur.archlinux.org/cgit/aur.git/tree/makefile_1.6.patch?h=enchant1.6 Try updating enchant1.6 and seeing if enchant consumers like evolution work now. ;)