GNOME Bugzilla – Bug 352099
Crash on Text Editor (possible out-of-memory problem)
Last modified: 2010-04-04 15:05:10 UTC
What were you doing when the app crashed?: Trying to install a game Distribution: Fedora Core release 5.91 (FC6 Test2) Gnome Release: 2.15.4 2006-07-12 (Red Hat, Inc) BugBuddy Version: 2.15.0 Memmory status: size: 1685356544 vsize: 0 resident: 1685356544 share: 0 rss: 888475648 rss_rlim: 0 CPU usage: start_time: 1156024998 rtime: 0 utime: 2908 stime: 0 cutime:2546 cstime: 0 timeout: 362 it_real_value: 0 frequency: 0 Backtrace was generated from '/usr/bin/gedit' (no debugging symbols found) Using host libthread_db library "/lib/libthread_db.so.1". (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread -1208194640 (LWP 3943)] (no debugging symbols found) 0xb7fe8402 in __kernel_vsyscall ()
+ Trace 70733
Thread 1 (Thread -1208194640 (LWP 3943))
Thanks for taking the time to report this bug. This bug report isn't very useful because it doesn't describe the bug well. If you have time and can still reproduce the bug, please read http://bugzilla.gnome.org/bug-HOWTO.html and add a description of how to reproduce this bug. You'll also need to add a better stack trace if possibile; please see http://live.gnome.org/GettingTraces for more information about how to do so. Anyway, looking at the available stack trace it seems an out-of-memory problem to me.
*** Bug 356734 has been marked as a duplicate of this bug. ***
Moving over bug 356734 comment 2 from the closed duplicate: > Paolo Maggi, gedit developer: > The crash is due to an out-of-memory condition. > I'm not sure how we should manage these cases, we should probably try to > "convert to UTF-8" in an incremental way.
*** Bug 364476 has been marked as a duplicate of this bug. ***
*** Bug 368991 has been marked as a duplicate of this bug. ***
*** Bug 369346 has been marked as a duplicate of this bug. ***
*** Bug 369795 has been marked as a duplicate of this bug. ***
*** Bug 370479 has been marked as a duplicate of this bug. ***
*** Bug 372785 has been marked as a duplicate of this bug. ***
*** Bug 374101 has been marked as a duplicate of this bug. ***
I've been asked to give more informations about the bug I got (374101). It is for sure a "out of memory" bug. I received two XML files which I wanted to preview. The 1st one was 200 Mo, and it opened without problem. The second one was 800 Mo and it crashed (I have only 512 Mo RAM on my system). Regards.
*** Bug 374919 has been marked as a duplicate of this bug. ***
*** Bug 376664 has been marked as a duplicate of this bug. ***
I think too for the out of memory. 1/Open my Docs directory (FAT32) in nautilus 2/Open the pagefile.sys (2Go) with gedit 3/Crash I have 1Go of memory. I think the bug is proportionnal of you're amount of RAM. I'll try open différent files seize once i was return on Linux
gEdit 2.16.1 on Ubuntu 6.10 swelled to 300+ MB on this 386 MB RAM machine when something opened the crash report i had just uploaded here: http://librarian.launchpad.net/5119270/_usr_bin_python.1002.crash I'm switching to SciTE.
*** Bug 378226 has been marked as a duplicate of this bug. ***
*** Bug 378588 has been marked as a duplicate of this bug. ***
*** Bug 379217 has been marked as a duplicate of this bug. ***
*** Bug 379530 has been marked as a duplicate of this bug. ***
*** Bug 379962 has been marked as a duplicate of this bug. ***
*** Bug 380223 has been marked as a duplicate of this bug. ***
*** Bug 380465 has been marked as a duplicate of this bug. ***
*** Bug 380715 has been marked as a duplicate of this bug. ***
*** Bug 380745 has been marked as a duplicate of this bug. ***
I was installing files for my nvidia card, I have 1 gig of memory. is there anyway to resolve this issue?
*** Bug 380816 has been marked as a duplicate of this bug. ***
*** Bug 381422 has been marked as a duplicate of this bug. ***
*** Bug 381898 has been marked as a duplicate of this bug. ***
i was installing true combat elite on ubuntu edgy eft
*** Bug 381881 has been marked as a duplicate of this bug. ***
*** Bug 382266 has been marked as a duplicate of this bug. ***
*** Bug 382727 has been marked as a duplicate of this bug. ***
*** Bug 382829 has been marked as a duplicate of this bug. ***
*** Bug 383325 has been marked as a duplicate of this bug. ***
*** Bug 383417 has been marked as a duplicate of this bug. ***
*** Bug 384117 has been marked as a duplicate of this bug. ***
*** Bug 384314 has been marked as a duplicate of this bug. ***
Hi dear reporters, Thanks for taking the time to report this bug. Unfortunately, that stack traces are missing some elements that will help a lot to solve the problem, so it will be hard for the developers to fix that crash. Can you get us a stack trace with debugging symbols? Please see http://live.gnome.org/GettingTraces for more information on how to do so. (install debug packages of liglib2 and libgtk2) Thanks in advance! It will help us a lot
I was asked for more infos, is that ok ? I installed the debuginfo package... not sure it was the (only) thing to do. ------ Distribution: Fedora Core release 6 (Zod) Gnome Release: 2.16.0 2006-09-04 (Red Hat, Inc) BugBuddy Version: 2.16.0 System: Linux 2.6.18-1.2849.fc6 #1 SMP Fri Nov 10 12:45:28 EST 2006 i686 X Vendor: The X.Org Foundation X Vendor Release: 70101000 Selinux: Enforcing Accessibility: Disabled ----------- .xsession-errors --------------------- Error: No running window found Error: No running window found GLib-ERROR **: gmem.c:135: failed to allocate 998535286 bytes aborting... ** (bug-buddy:32536): WARNING **: Impossible de charger l'icône pour Ouvrir le dossier Error: No running window found libnm_glib_nm_state_cb: dbus returned an error. (org.freedesktop.DBus.Error.ServiceUnknown) The name org.freedesktop.NetworkManager was not provided by any .service files GLib-ERROR **: gmem.c:135: failed to allocate 998535286 bytes aborting... ** (bug-buddy:511): WARNING **: Impossible de charger l'icône pour Ouvrir le dossier -------------------------------------------------- Memory status: size: 1064759296 vsize: 0 resident: 1064759296 share: 0 rss: 591097856 rss_rlim: 0 CPU usage: start_time: 1165749113 rtime: 0 utime: 600 stime: 0 cutime:476 cstime: 0 timeout: 124 it_real_value: 0 frequency: 0 Backtrace was generated from '/usr/bin/gedit' Using host libthread_db library "/lib/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread -1208961328 (LWP 509)] 0x00dfe402 in __kernel_vsyscall ()
+ Trace 93001
Thread 1 (Thread -1208961328 (LWP 509))
Hi Cedric, it seems you didn't installed the libglib2 debug package (not sure how it is called on Fedora though), we need this one too to track this issue. thanks for your help
Sorry i didn't find them (the libglib2) because they're indeed not exactly same name on fedora. Here's the log with these installed at the moment : gedit-debuginfo, glib2-debuginfo, gtk2-engines-debuginfo and gtk2-debuginfo. Hope it'll help more... ----- Distribution: Fedora Core release 6 (Zod) Gnome Release: 2.16.0 2006-09-04 (Red Hat, Inc) BugBuddy Version: 2.16.0 System: Linux 2.6.18-1.2849.fc6 #1 SMP Fri Nov 10 12:45:28 EST 2006 i686 X Vendor: The X.Org Foundation X Vendor Release: 70101000 Selinux: Enforcing Accessibility: Disabled ----------- .xsession-errors --------------------- ** (bug-buddy:511): WARNING **: Impossible de charger l'icône pour Ouvrir le dossier XS[src/xmms-sid.c:xs_init:216]: xs_init() XS[src/xs_config.c:xs_init_configuration:164]: initializing configuration ... XS[src/xs_config.c:xs_read_configuration:265]: loading from config-file ... XS[src/xs_config.c:xs_read_configuration:320]: OK XS[src/xmms-sid.c:xs_reinit:163]: initializing emulator engine #1... XS[src/xmms-sid.c:xs_reinit:177]: init#1: OK, 1 XS[src/xmms-sid.c:xs_reinit:189]: init#2: OK, 0 XS[src/xmms-sid.c:xs_init:226]: OK GLib-ERROR **: gmem.c:135: failed to allocate 998535286 bytes aborting... ** (bug-buddy:761): WARNING **: Impossible de charger l'icône pour Ouvrir le dossier -------------------------------------------------- Memory status: size: 1064755200 vsize: 0 resident: 1064755200 share: 0 rss: 591900672 rss_rlim: 0 CPU usage: start_time: 1165751082 rtime: 0 utime: 654 stime: 0 cutime:519 cstime: 0 timeout: 135 it_real_value: 0 frequency: 0 Backtrace was generated from '/usr/bin/gedit' Using host libthread_db library "/lib/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread -1208621360 (LWP 758)] 0x00846402 in __kernel_vsyscall ()
+ Trace 93006
Thread 1 (Thread -1208621360 (LWP 758))
Stack trace with debug symbols Confirming the bug.
oups, confirming for real
*** Bug 385395 has been marked as a duplicate of this bug. ***
*** Bug 387334 has been marked as a duplicate of this bug. ***
*** Bug 388347 has been marked as a duplicate of this bug. ***
*** Bug 389606 has been marked as a duplicate of this bug. ***
*** Bug 390380 has been marked as a duplicate of this bug. ***
*** Bug 390341 has been marked as a duplicate of this bug. ***
*** Bug 390583 has been marked as a duplicate of this bug. ***
*** Bug 391175 has been marked as a duplicate of this bug. ***
*** Bug 391694 has been marked as a duplicate of this bug. ***
Here is the log of an irc discussion about the bug: (14:25:25) <paolo> so I tried to find a way to fix a bug that is really pissing me (14:27:35) <paolo> BTW, I'm speaking of the "out-of-memory" in gedit_convert_to_utf8 (14:27:46) <pbor> yeah (14:28:14) <paolo> too many people is experiencing it (14:28:22) <pbor> well, actually avoiding the silly strdup in the non-converting case would be a good enough stop-gap solution (14:28:38) <paolo> and I think we can try to alleviate this problem (14:29:04) <paolo> pbor: sure, this could be a first step (14:29:13) <nud> paolo: would it be possible (at first) to avoid crashing but notice there is not enough memory ? (14:29:17) <pbor> we need to convert in chunks and feed chuncks to the buffer (14:29:25) <paolo> I think the problem cannot be solved since if you try to open a 100Gb file in gedit it will crash (14:29:29) <nud> so at least it doesn't crash, and we can smarten our way later (14:29:52) <paolo> well, it not so easy (14:29:56) <pbor> nud: we could use try_malloc instead of blindly strduping (14:29:57) <nud> otherwise you'll just crash for a bigger file, which is not that smart either (14:30:23) <paolo> I think the solution is this one (14:30:26) <pbor> paolo: yeah, I know it's not easy (14:31:00) <nud> otherwise we should have a way not to load the whole file in memory, but that one looks a lot more difficult to achieve (14:31:03) <nud> if not impossible (14:31:07) <paolo> - for files that does not need to be convert: do not strdup ;( (14:31:37) <paolo> - for files that should be converted to utf8 (14:32:13) <paolo> - convert it in chunks of X bytes (where X > 20000 or something) (14:32:42) <paolo> - if conversion fails it could be a real failure or not (14:32:42) <pbor> nud: it's not impossible... g_convert returns the 'remainder' that has not been converted, so you can convert in a loop (14:33:15) <nud> pbor: it's possible not to have the whole file in the gtktextbuffer ? (14:33:31) <paolo> - user the "remainder", if it is > 4 -> error, otherwise try to convert the following chunk (14:34:02) <paolo> all the chunks go in a list (14:34:15) <paolo> then if all the the file is converted. feed the list to the buffer (14:34:16) <pbor> nud: that isn't the problem, textbuffer doesn't malloc a single block of memory... the problem happens during g_convert where we put all the contents in a single string (14:35:02) <paolo> nud: see http://bugzilla.gnome.org/show_bug.cgi?id=352099#c41 (14:35:05) <pbor> paolo: why do we have to keep them in a list... can't we feed them to the buffer as we go? (14:35:07) <bugsbot> paolo: Bug 352099 cri, High, ---, gedit-maint@gnome.bugs, NEW, Crash on Text Editor (possible out-of-memory problem) (14:35:12) <paolo> you will see the crash is due a a very big malloc (14:35:25) <nud> pbor: it doesn't malloc but the idea was to spare memory by only having a subpart of the file in memory (14:35:31) <pbor> paolo: keeping them in a list means we cannot reuse the block of memory (14:35:38) <nud> doesn't vim do something like that ? less does, at least ;-) (14:35:51) <paolo> pbor: no, conversion could fail for example at the last byte of the file (14:36:41) <nud> paolo: but then you wouldn't spare memory, would you ? (14:36:42) <pbor> nud: that's a secondary problem, unless you go out of adress space swap will take care of things (more or less) (14:37:00) <paolo> nud: why? (14:37:07) <pbor> paolo: and why is that a problem? if the error occurs we clear the buffer (14:37:08) <nud> since you'd have two copies of the file, one in the list and one in the buffer (14:37:13) <paolo> pbor: well, swap space is << of address space (14:37:40) <paolo> nud: no, we will free the list while feeding the buffer (14:37:46) <nud> ok (14:38:22) <pbor> paolo: but it means that we have to allocate a large number of 2000 bytes buffers (14:38:23) <paolo> pbor: syntax hl and all text buffer machinery like view updating and so on will work (14:38:47) <pbor> paolo: while I'd rather reuse the same (14:38:51) <paolo> pbor: we can choose big block of 4 Mb for example (14:39:27) <paolo> in this way you will have multiple blocks only a very big files (14:39:56) <paolo> note that the blocks are allocated from g_convert so we cannot choose their real size (14:40:17) <pbor> dunno, I don't like the idea of mallocing 4MB every time we open a simple text file either (14:40:30) <paolo> no, we don't malloc them (14:41:04) <paolo> we split the input file in block of X bytes (4 Mb or less, we can decide later) (14:41:40) <paolo> then convert the first X bytes, g_convert will allocate Y bytes for the result, we put them in a list (14:41:43) <paolo> and so on (14:42:02) <paolo> then if the entire file is converted (14:42:14) <paolo> we put the first Y bytes in the buffer and free them (14:42:17) <paolo> and so on (14:42:37) <paolo> otherwise try with another encoding (14:43:12) <pbor> yes, I got what you mean (14:43:41) <pbor> it's still not clear to me why we cannot simply put them in the buffer instead of keeping them in a list (14:43:46) <paolo> I agree with you that using the buffer could be a better solution, but there is no need to freeze view updating while populating the buffer (14:44:20) <paolo> we can disable syntax hl, but not view updating (14:44:40) <pbor> we can use a separate buffer and attach it to the view after it has been populated (14:45:31) <paolo> yep, I also thought to this solution (14:45:54) <paolo> but I'm not sure gedit will manage it in the correct way (14:46:04) <pbor> anyway, even with the list it would be a great improvement (14:46:57) <nud> paolo: cant you disconnect the buffer from the view ? (14:46:59) *nud goes anyway (14:47:01) nud quit (Ex-Chat) (14:47:03) <paolo> furthermore when you fill the buffer, I suspect strange operation will happen inside the data structure (14:47:35) <pbor> yes... but that's why I would prefer populating as we go (14:48:13) <pbor> I am scared that populating from a list of chunks would expose performance problems (14:48:32) <paolo> we could use the list of temporary solution and later propose a change to gtktextview to freeze it (14:48:43) <pbor> like the view doing a whole lot of work every time we insert a block and then redo it for the next block etc (14:49:26) <pbor> well, actually we should maybe propose a to move this whole conversion/pupulate business inside gtk itself whenit works :)
*** Bug 393433 has been marked as a duplicate of this bug. ***
*** Bug 393581 has been marked as a duplicate of this bug. ***
*** Bug 394254 has been marked as a duplicate of this bug. ***
*** Bug 395468 has been marked as a duplicate of this bug. ***
*** Bug 396010 has been marked as a duplicate of this bug. ***
*** Bug 396732 has been marked as a duplicate of this bug. ***
*** Bug 397433 has been marked as a duplicate of this bug. ***
*** Bug 397491 has been marked as a duplicate of this bug. ***
*** Bug 397953 has been marked as a duplicate of this bug. ***
*** Bug 399240 has been marked as a duplicate of this bug. ***
*** Bug 400062 has been marked as a duplicate of this bug. ***
*** Bug 402067 has been marked as a duplicate of this bug. ***
*** Bug 404744 has been marked as a duplicate of this bug. ***
*** Bug 405199 has been marked as a duplicate of this bug. ***
*** Bug 406503 has been marked as a duplicate of this bug. ***
*** Bug 407448 has been marked as a duplicate of this bug. ***
*** Bug 407762 has been marked as a duplicate of this bug. ***
*** Bug 408033 has been marked as a duplicate of this bug. ***
*** Bug 410304 has been marked as a duplicate of this bug. ***
*** Bug 410326 has been marked as a duplicate of this bug. ***
*** Bug 412347 has been marked as a duplicate of this bug. ***
*** Bug 412364 has been marked as a duplicate of this bug. ***
*** Bug 412989 has been marked as a duplicate of this bug. ***
*** Bug 413064 has been marked as a duplicate of this bug. ***
*** Bug 414497 has been marked as a duplicate of this bug. ***
*** Bug 414680 has been marked as a duplicate of this bug. ***
*** Bug 414996 has been marked as a duplicate of this bug. ***
*** Bug 415602 has been marked as a duplicate of this bug. ***
*** Bug 417071 has been marked as a duplicate of this bug. ***
*** Bug 417089 has been marked as a duplicate of this bug. ***
*** Bug 417951 has been marked as a duplicate of this bug. ***
*** Bug 418017 has been marked as a duplicate of this bug. ***
*** Bug 418223 has been marked as a duplicate of this bug. ***
*** Bug 418565 has been marked as a duplicate of this bug. ***
*** Bug 419372 has been marked as a duplicate of this bug. ***
*** Bug 419558 has been marked as a duplicate of this bug. ***
*** Bug 419603 has been marked as a duplicate of this bug. ***
*** Bug 421029 has been marked as a duplicate of this bug. ***
*** Bug 420827 has been marked as a duplicate of this bug. ***
*** Bug 421223 has been marked as a duplicate of this bug. ***
*** Bug 421932 has been marked as a duplicate of this bug. ***
*** Bug 422102 has been marked as a duplicate of this bug. ***
*** Bug 422128 has been marked as a duplicate of this bug. ***
*** Bug 423155 has been marked as a duplicate of this bug. ***
*** Bug 423080 has been marked as a duplicate of this bug. ***
*** Bug 424804 has been marked as a duplicate of this bug. ***
*** Bug 425565 has been marked as a duplicate of this bug. ***
*** Bug 426071 has been marked as a duplicate of this bug. ***
*** Bug 426771 has been marked as a duplicate of this bug. ***
*** Bug 427549 has been marked as a duplicate of this bug. ***
*** Bug 426692 has been marked as a duplicate of this bug. ***
*** Bug 427814 has been marked as a duplicate of this bug. ***
*** Bug 428238 has been marked as a duplicate of this bug. ***
*** Bug 429847 has been marked as a duplicate of this bug. ***
*** Bug 430575 has been marked as a duplicate of this bug. ***
*** Bug 430988 has been marked as a duplicate of this bug. ***
*** Bug 431411 has been marked as a duplicate of this bug. ***
*** Bug 431797 has been marked as a duplicate of this bug. ***
*** Bug 431952 has been marked as a duplicate of this bug. ***
*** Bug 422977 has been marked as a duplicate of this bug. ***
*** Bug 433631 has been marked as a duplicate of this bug. ***
*** Bug 434258 has been marked as a duplicate of this bug. ***
*** Bug 435522 has been marked as a duplicate of this bug. ***
*** Bug 435808 has been marked as a duplicate of this bug. ***
*** Bug 438395 has been marked as a duplicate of this bug. ***
*** Bug 439330 has been marked as a duplicate of this bug. ***
*** Bug 440736 has been marked as a duplicate of this bug. ***
*** Bug 446618 has been marked as a duplicate of this bug. ***
*** Bug 446971 has been marked as a duplicate of this bug. ***
*** Bug 447483 has been marked as a duplicate of this bug. ***
*** Bug 442340 has been marked as a duplicate of this bug. ***
*** Bug 453705 has been marked as a duplicate of this bug. ***
*** Bug 454234 has been marked as a duplicate of this bug. ***
*** Bug 455559 has been marked as a duplicate of this bug. ***
ALL the duplicates of the last 4 months are from different distros with version 2.16. I have not seen a single report about this on 2.18. Maybe this has been fixed in the meantime.
*** Bug 461140 has been marked as a duplicate of this bug. ***
*** Bug 461311 has been marked as a duplicate of this bug. ***
*** Bug 461547 has been marked as a duplicate of this bug. ***
*** Bug 462511 has been marked as a duplicate of this bug. ***
*** Bug 463643 has been marked as a duplicate of this bug. ***
*** Bug 464537 has been marked as a duplicate of this bug. ***
In reply to comment #128) > ALL the duplicates of the last 4 months are from different distros with version > 2.16. > I have not seen a single report about this on 2.18. > Maybe this has been fixed in the meantime. > I am not able to reproduce the bug in 2.18 anymore. A 150 MB text file is opened successfully.
*** Bug 467213 has been marked as a duplicate of this bug. ***
*** Bug 471012 has been marked as a duplicate of this bug. ***
*** Bug 472688 has been marked as a duplicate of this bug. ***
*** Bug 474182 has been marked as a duplicate of this bug. ***
*** Bug 466699 has been marked as a duplicate of this bug. ***
*** Bug 476098 has been marked as a duplicate of this bug. ***
*** Bug 474479 has been marked as a duplicate of this bug. ***
*** Bug 478391 has been marked as a duplicate of this bug. ***
*** Bug 479093 has been marked as a duplicate of this bug. ***
*** Bug 479077 has been marked as a duplicate of this bug. ***
*** Bug 481829 has been marked as a duplicate of this bug. ***
*** Bug 483318 has been marked as a duplicate of this bug. ***
*** Bug 480718 has been marked as a duplicate of this bug. ***
*** Bug 486265 has been marked as a duplicate of this bug. ***
from bug 489350:
+ Trace 173546
*** Bug 489350 has been marked as a duplicate of this bug. ***
*** Bug 488927 has been marked as a duplicate of this bug. ***
*** Bug 488926 has been marked as a duplicate of this bug. ***
*** Bug 500260 has been marked as a duplicate of this bug. ***
*** Bug 477525 has been marked as a duplicate of this bug. ***
*** Bug 516837 has been marked as a duplicate of this bug. ***
*** Bug 516625 has been marked as a duplicate of this bug. ***
*** Bug 594338 has been marked as a duplicate of this bug. ***
This is finally fixed! We now do encoding conversion in chunks using gio's GCharsetConverter