After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 791229 - Crash under enchant_broker_list_dicts()
Crash under enchant_broker_list_dicts()
Status: RESOLVED NOTGNOME
Product: evolution
Classification: Applications
Component: Composer
unspecified
Other Linux
: Normal critical
: ---
Assigned To: evolution-mail-maintainers
Evolution QA team
Depends on:
Blocks:
 
 
Reported: 2017-12-04 23:51 UTC by mets_web
Modified: 2017-12-07 03:20 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
GDB dump (46.42 KB, text/plain)
2017-12-04 23:51 UTC, mets_web
Details
GDM dump 2 (20.88 KB, text/plain)
2017-12-05 11:45 UTC, mets_web
Details
enchnt.c (697 bytes, text/plain)
2017-12-05 15:12 UTC, Milan Crha
Details

Description mets_web 2017-12-04 23:51:06 UTC
Created attachment 364962 [details]
GDB dump

Creating or Replying to an email causes Segfault

GDB dump attached
Comment 1 Milan Crha 2017-12-05 07:46:02 UTC
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
Comment 2 mets_web 2017-12-05 11:43:41 UTC
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.
Comment 3 mets_web 2017-12-05 11:45:01 UTC
Created attachment 365020 [details]
GDM dump 2

GDB dump on access preferences menu
Comment 4 Milan Crha 2017-12-05 14:02:56 UTC
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.
Comment 5 mets_web 2017-12-05 14:14:42 UTC
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.
Comment 6 Milan Crha 2017-12-05 15:12:26 UTC
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.
Comment 7 mets_web 2017-12-05 16:03:21 UTC
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)
Comment 8 Milan Crha 2017-12-05 16:14:22 UTC
(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
Comment 9 mets_web 2017-12-05 16:27:01 UTC
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.
Comment 10 Milan Crha 2017-12-05 16:29:16 UTC
(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.
Comment 11 mets_web 2017-12-05 16:33:20 UTC
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
Comment 12 mets_web 2017-12-05 16:37:01 UTC
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)
Comment 13 Milan Crha 2017-12-05 16:39:38 UTC
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.
Comment 14 mets_web 2017-12-05 16:40:46 UTC
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 . . .
Comment 15 mets_web 2017-12-05 16:41:33 UTC
(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?
Comment 16 Milan Crha 2017-12-05 16:46:06 UTC
(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.)
Comment 17 mets_web 2017-12-05 18:46:39 UTC
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

Thread 1 (Thread 0x7ffff7fab740 (LWP 29423))

  • #0 raise
  • #1 abort
  • #2 __libc_message
  • #3 malloc_printerr
  • #4 _int_free
  • #5 g_strfreev
  • #6 enchant_broker_list_dicts
    at lib.c line 1176
  • #7 main
    at enchnt.c line 22

Comment 18 Eli Schwartz 2017-12-05 19:12:24 UTC
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. ;)
Comment 19 mets_web 2017-12-05 19:16:34 UTC
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/
Comment 20 Milan Crha 2017-12-06 11:52:11 UTC
(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?
Comment 21 mets_web 2017-12-06 13:00:39 UTC
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.
Comment 22 mets_web 2017-12-06 19:44:19 UTC
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)
Comment 23 Milan Crha 2017-12-06 23:28:52 UTC
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.
Comment 24 mets_web 2017-12-06 23:53:01 UTC
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.
Comment 25 mets_web 2017-12-07 03:18:02 UTC
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.
Comment 26 Eli Schwartz 2017-12-07 03:20:21 UTC
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. ;)