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 95063 - gedit crashes when I start it up
gedit crashes when I start it up
Status: VERIFIED INCOMPLETE
Product: gedit
Classification: Applications
Component: general
2.0.2
Other other
: High critical
: ---
Assigned To: Gedit maintainers
gedit QA volunteers
: 100460 116504 116622 122241 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2002-10-07 11:18 UTC by pvinson
Modified: 2009-08-15 18:40 UTC
See Also:
GNOME target: ---
GNOME version: 2.0



Description pvinson 2002-10-07 11:59:33 UTC
Package: gedit
Severity: normal
Version: 2.0.2
Synopsis: gedit crashes when I start it up
Bugzilla-Product: gedit
Bugzilla-Component: general
BugBuddy-GnomeVersion: 2.0 (2.0.3)

Description:
Description of Problem:
After some period of time gedit starts to crash when I start it up...it
doesn't do after a fresh reboot, though.

Steps to reproduce the problem:
1. it just happens..no particular instance.
2. 
3. 

Actual Results:


Expected Results:


How often does this happen?
  A LOT

Additional Information:




Debugging Information:

Backtrace was generated from '/usr/bin/gedit'

(no debugging symbols found)...[New Thread 8192 (LWP 10143)]
0x420ae169 in wait4 () from /lib/i686/libc.so.6

Thread 1 (Thread 8192 (LWP 10143))

  • #0 wait4
    from /lib/i686/libc.so.6
  • #1 __DTOR_END__
    from /lib/i686/libc.so.6
  • #2 waitpid
    from /lib/i686/libpthread.so.0
  • #3 libgnomeui_module_info_get
    from /usr/lib/libgnomeui-2.so.0
  • #4 __pthread_sighandler
    from /lib/i686/libpthread.so.0
  • #5 <signal handler called>
  • #6 gconf_client_get_string_with_default
  • #7 gedit_prefs_manager_get_string
  • #8 gedit_prefs_manager_get_toolbar_buttons_style
  • #9 gedit_window_prefs_new
  • #10 gedit_mdi_app_created_handler
  • #11 g_cclosure_marshal_VOID__OBJECT
    from /usr/lib/libgobject-2.0.so.0
  • #12 g_closure_invoke
    from /usr/lib/libgobject-2.0.so.0
  • #13 signal_emit_unlocked_R
    from /usr/lib/libgobject-2.0.so.0
  • #14 g_signal_emit_valist
    from /usr/lib/libgobject-2.0.so.0
  • #15 g_signal_emit
    from /usr/lib/libgobject-2.0.so.0
  • #16 app_create
  • #17 app_clone
  • #18 bonobo_mdi_open_toplevel
  • #19 main
  • #20 __libc_start_main
    from /lib/i686/libc.so.6
  • #0 wait4
    from /lib/i686/libc.so.6




------- Bug moved to this database by unknown@bugzilla.gnome.org 2002-10-07 07:59 -------

The original reporter (pvinson@fit.edu) of this bug does not have an account here.
Reassigning to the exporter, unknown@bugzilla.gnome.org.
Reassigning to the default owner of the component, maggi@athena.polito.it.

Comment 1 Andrew Sobala 2002-10-07 15:24:13 UTC
Unique trace
Comment 2 Luis Villa 2002-10-28 21:37:54 UTC
Paolo: is this a gconf bug?
Comment 3 Paolo Maggi 2002-10-29 10:17:34 UTC
I don't think it is a gconf bug
Note that I'm not able to reproduce it.
Comment 4 Luis Villa 2002-11-07 19:45:34 UTC
Apologies for the spam- I'm removing 'bugsquad' from some keywords via the web
interface. This is a one-time only thing before I re-add bugsquad via the SQL
interface, which will generate no mail. Apologies again.
Comment 5 Paolo Maggi 2002-11-22 18:31:55 UTC
I'm still not able to reproduce it ... and I use gedit very often :-)

Are you still able to reproduce it?
Could you please attach a stack trace from a gedit compiled with
debugging symbols?
Comment 6 Elijah Newren 2002-12-05 21:32:42 UTC
*** Bug 100460 has been marked as a duplicate of this bug. ***
Comment 7 Elijah Newren 2002-12-05 21:37:57 UTC
Bug 100460 had some interesting comments that makes it sound like this
may be due to a memory leak of some other application that eats up all
available memory.  Of course, this is just a guess on my part.  But it
seems to be backed up by the fact that the reporter of this bug says
that it never happens after a fresh reboot.

Here's the relevant comments from 100460:

 Description of Problem:
 Gedit seems to be crashing after computer has been running so many
 days.  Usually gedit crashes after the computer has been running for
 least 2 days.  I get an additional error with the crash error.  The
 other one states that an error occurred while loading or saving
 configuration information.  Maybe this is a Gconf problem?

 Steps to reproduce the problem:
 1.  Have computer run least 2 days
 2.  Run Gedit, does always work right away.  Seems to be random

Also, there was one other comment in 100460 that might be relevant,
but it doesn't really affect the memory leak theory either way:

 Additional Information:
 This never happened when I was using the lastest Gnome from gnome.org
 while I was still using Red Hat Linux 7.3.  This problem started when
 I installed Red Hat Linux 8.0.  I don't know if that has anything to
 do with it, but you never know.

Because of this other bug report, I'm going to reopen.
Comment 8 Paolo Maggi 2002-12-13 15:17:14 UTC
James (aka snorp): could you please give a look at this bug?
Comment 9 Paolo Maggi 2003-04-17 12:21:47 UTC
Is someone still having this problem?
Comment 10 Paolo Maggi 2003-06-11 16:19:33 UTC
Closing it since nobody seems to be able to reproduce it.
Comment 11 Kjartan Maraas 2003-07-02 12:14:49 UTC
*** Bug 116504 has been marked as a duplicate of this bug. ***
Comment 12 Elijah Newren 2003-07-03 16:06:37 UTC
*** Bug 116622 has been marked as a duplicate of this bug. ***
Comment 13 Paolo Maggi 2004-02-12 12:08:02 UTC
*** Bug 122241 has been marked as a duplicate of this bug. ***
Comment 14 Paolo Maggi 2004-02-12 12:13:12 UTC
Please, note that all the duplicates of this bug are related to gedit
2.0.2.
I have not seen duplicates related to a newer version of gedit so I
suppose that somehow this bug has been fixed.
If you see this same bug reported against a newer version of gedit
(2.x.x with x >= 2), please, reopen it.