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 616251 - segfault loading empty .tex file
segfault loading empty .tex file
Status: RESOLVED FIXED
Product: gedit
Classification: Applications
Component: general
git master
Other Linux
: Normal critical
: ---
Assigned To: Gedit maintainers
Gedit maintainers
Depends on:
Blocks:
 
 
Reported: 2010-04-20 06:25 UTC by Daiki Ueno
Modified: 2010-05-16 10:32 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
patch to fix GeditSmartCharsetConverter (3.83 KB, patch)
2010-04-20 06:25 UTC, Daiki Ueno 		none Details | Review

Description Daiki Ueno 2010-04-20 06:25:09 UTC 
Created attachment 159138 [details] [review]
patch to fix GeditSmartCharsetConverter

When GeditLaTeXPlugin is enabled, opening an empty .tex file causes segmentation fault:

 $ touch test.tex
 $ gedit test.tex
 (gedit:24492): GLib-GIO-CRITICAL **: g_converter_convert: assertion `outbuf_size > 0' failed
 zsh: segmentation fault (core dumped)  gedit test.tex

This is because encoding detection in GeditSmartCharsetConverter does not expect empty input.  I'll attach a patch with a testcase.
Comment 1 jessevdk@gmail.com 2010-04-20 08:09:40 UTC 
I'm wondering two things, maybe you can answer:

1) How come this only happens when the latex plugin is enabled. What special things does it do to 'interfere' with the file loading process?

2) The assertion seems to be on outbuf_size, but the check in the patch is on inbuf_size. Why is that?
Comment 2 Daiki Ueno 2010-04-20 08:15:52 UTC 
I have no idea on 1).  For 2), because outbuf_size is directly calculated from inbuf_size (outbuf_size = inbuf_size * 4) in try_convert() in gedit-smart-charset-converter.c.
Comment 3 Ignacio Casal Quinteiro (nacho) 2010-05-16 09:25:35 UTC 
Is this still a problem? Has this been fixed in the plugin?
Comment 4 jessevdk@gmail.com 2010-05-16 10:32:31 UTC 
Looking further into the problem, we found that this problem was occuring on empty files when the utf-8 encoding was not in the default list of auto-detected encodings. We have fixed this bug now both on master and on stable and will release a new stable version soon. Thanks for taking the time to report the bug!