Bug 477022 - gedit consistently crashes Fedora 10 on a particular file name
gedit consistently crashes Fedora 10 on a particular file name
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
10
i386 Linux
low Severity low
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-12-18 13:06 EST by Andre Michaud
Modified: 2009-12-18 02:19 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-12-18 02:19:48 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Original file causing gedit to crash Fedora 10 (362 bytes, text/plain)
2008-12-18 19:10 EST, Andre Michaud
no flags Details
Output of dmesg (26.96 KB, application/octet-stream)
2008-12-19 15:07 EST, Andre Michaud
no flags Details
Xorg.0.log as requested (126.85 KB, text/plain)
2008-12-20 10:39 EST, Andre Michaud
no flags Details

  None (edit)
Description Andre Michaud 2008-12-18 13:06:20 EST
My recent install of Fedora 10 is unstable.  I have, however, identified a situation where the system crashes on a consistent basis.  I feel this may be of interest to developers.

The system will crash whenever:
  I access a file called:  clear_window_and_setup_plot.txt
  I create a file within gedit (any content) and save with the same name (must type the '.txt' )

I have changed the name and the crash will not occur on a file name that is different.  I have changed the name at the beginning, end and middle. It crashes consistently on the exact above name.


Version-Release number of selected component (if applicable):
gedit version 2.24.2

How reproducible: As above


Actual results:  gedit opens displays a grey area above th contents of the file.  The system craes.  Mouse movement OK, but not response to mouse clicks and no keyboard activity.  Must press system reset.


Expected results:  Normal gedit operation.
Comment 1 Ray Strode [halfline] 2008-12-18 13:39:09 EST
can you attach the file in question?
Comment 2 Andre Michaud 2008-12-18 19:10:12 EST
Created attachment 327393 [details]
Original file causing gedit to crash Fedora 10

Here is the original file that produced the problem.  Please remember that my system is quite unstable and crashes on other events as well.  I did quite a bit of hypothesis testing before comming to the conclusion described above.

Remember, I don't need this original file to re-create the crash.  A new instance of gedit with any text, saved as "clear_window_and_setup_plot.txt" will crash the system.

Additional observations:  

clear_window_and_setup_plot.txt in a diferent directory will crash the system.

File name changed to:
clear_window_and_setup_plox.txt does crash the system.
clear_window_and_setup_ploy.txt does crash the system.

clear_window_and_setup_plo.txt does not crash the system.
clear_window_and_setup_plot1.txt does not crash the system.
clear_window_and_setup_plot2.txt does not crash the system.

New instance of gedit, type a few characters, save as "clear_...plot.txt" crashes the system.  Re-boot. The saved file does exist.  Atttempt to open by double clicking. Result:  gedit opens, displays a wide grey band, the typed text and crashes the system. Re-boot.  Rename the file to "clear_..._plo.txt"  Double click, result:  Does not crash the system.

I hope that these observations are valuable.
Comment 3 Ray Strode [halfline] 2008-12-19 11:33:09 EST
I can't reproduce.  If you're getting a variety of odd crashes, it may be a hardware fault.

A few things:

1) Could it be overheating?  Is it stable on a fresh boot if the machine has been off for a long time?  Are you doing any sort of overclocking?

2) Could it be bad ram?  Have you tried running memtest?

3) Could it be a bogus kernel module?  If you run dmesg do you see any unsual and scary messages?  Are you running a non-standard kernel or a non-stock driver?

4) Can you open a terminal and type:
debuginfo-install gedit (as root)
and then as a user:

gdb gedit
run

then reproduce and when it crashes type

thread apply all backtrace full

and attach the result?
Comment 4 Andre Michaud 2008-12-19 15:07:33 EST
Created attachment 327492 [details]
Output of dmesg


Respecting your paragraph numbers above:

1) 	Hypothesis: Overheating.

	Observations:  I am not changing the clockspeed. I  haven't turned off this computer in a while.  “PC Health Status” from CMOS Setup reports:  CPU temp: 35 degree celcius, System Tempreature 25 degree. Vcore 1.43V, DDR25V: 2.54V,  +3.3V: 3.38V, +12V:  11.90V. Curent CPU FAN speed: 2996 RPM.  If you still would like to get observations after a (really) cold boot, please advise and let me know how long I should leave the computer off before doing this test.

2)	Hypothesis: Bad RAM

	Observations:  	Booted from DVD and ran Memtest86 v2.01 
	(start 12:34) Results:  WallTime:  1h06  ,Test Std,   Pass: 2    ,  Errors:  0

	
3)	I don't know anything abount non-standard kernels or drivers.  I am not an expert.  I have scanned the output to dmesg, but did not see anything unusual.  Will attach it's output in file “dmesg.out” for your inspection.

4)	Observtions from debug.  I installed the software as directed.  Ran gdb gedit as instructed. 

4a)  first attempt:  Re-produced the error.  The system crashes.  Unable to  execute “thread apply all backtrace full” command.  Last two lines in gdb terminal show at moment of crash:

	[New Thread 0xb65abb90 (LWP 6476) ]
	[Thread 0xb65abb90 (LWP 3143) exited]

Re-boot.   Is the information recoverable?  

4b) 2nd attempt:   Ran gdb gedit / run 
	– no longer able to produce crash !!!
	Closed gedit.  “Program exited normally.”   
	Result  of “thread apply all backtrace full:  “No Register”  	
	Closed terminal with gbd running.
	Double click “clear_window_and_setup_ploy.txt” - System crash
	Re-boot.

4c)  3rd attempt:   Ran gdb gedit / run 
	- reproduced crash . Same as in 4a).  Last oppened thread at time of crash: LWP 2886
	- re-boot

4d)	4th attempt:   Ran gdb gedit / run
	Crash -  Same as in 4a)


Unable to attach results.  I will wait for further instructions from you.  In the meantime:

Additional observation:

I have identified another file name that produces the same symptoms:  BIC.R
Original file obtained from archive:
http://probability.ca/cran/src/base/R-2/R-2.8.0.tar.gz

file in question is in directory:
R-2.8.0\src\library\stats4\R\

Again, I do not need to access or otherwise touch the original file to re-create the crash.  Simply saving a new file as BIC.R crashes the system with the same symptoms as described. (i.e. Grey band above text in file in a gedit window.)  Again, I have changed the name to BI.R and BIC1.R and these file names do not crash the system.  Changing the file back to BIC.R does crash the system.

Regards,
Andre Michaud
Comment 5 Ray Strode [halfline] 2008-12-19 15:22:45 EST
seems like it's exiting instead of crashing.

before doing run can you do
break _exit

and then when the break point hits do

t a a bt full

?
Comment 6 Andre Michaud 2008-12-19 15:59:22 EST
When I typed break _exit at the (gdb) prompt , the reply was:
	Function “_exit” not defined.Make breakpoint pending on future shared library load? (y or [n]) 

I replied “y”

“Breakpoint 1 (_exit) pending
(gdb) run

Result:  crash before Breakpoint 

2nd Try above with “exit” instead of “_exit”
Breakpoint 1 at 0x8064c4c
run 
Did not crash on save as BIC.R 
Crashed on save as clear_windo(...)txt
Crashed before hitting breakpoint.  Uanble to execute “t a a bt full”
reboot:

3rd  try
break exit
Breakpoint 1 at 0x8064c4c 
result:  Crashed before hitting breakpoint.

I have just made another significant (I think) observation.  I cannot produce the crash when logged in as a different user.  I have no idea if this is pertinent, however:  computer name is andre.fedora and the user name that produces the crashes is Andre

Please confirm that this is interesting to you !  If I re-install Fedora  10 and the symptoms disappear, I can get satisfation.  I'm leaving my machine in this state because I feel it is of value to you. 

Regards,
Andre
Comment 7 Ray Strode [halfline] 2008-12-19 19:38:08 EST
Because the problem isn't very widespread (you're the only reporter), the bug report isn't a super-critical one to track down.  If debugging is preventing you from getting work done and you think you can make the computer work for you by reinstalling or switching to a different user account, feel free.

Before you do that, though, can you attach ~/.gtk-bookmarks ?
Comment 8 Andre Michaud 2008-12-19 20:54:44 EST
I have 3 computers.  Unfortunately I can't use this as an excuse for my lack of productivity.  If you are interested (it may lead to something of interest and point to a bug that is mysterious and unreproducible in other situations) then I'm willing to carying out further observations for you.  On the other hand, just a bad install is not a bug, and if it disappears after a re-install, then we shouldn't "beat a dead horse."  It is so "weird".  How can a simple file name crash the system?

It's up to you.  

In any event I am not familiar with ~/.gtk-bookmarks .  Is this 'add bookmark' in Nautilus?  I've done a search for filename .gtk* and did not find a file to attach.  Please advise.

Andre
Comment 9 Ray Strode [halfline] 2008-12-19 23:26:57 EST
if you bring up a terminal and type:

ls ~/.gtk-bookmarks

and it says "No such file or directory" then you don't have it, which means it couldn't be the cause of your problems.

Can you attach the file /var/log/Xorg.0.log ?
Comment 10 Andre Michaud 2008-12-20 10:39:08 EST
Created attachment 327536 [details]
file .gtk-bokmarks as requested


.gtk-bookmarks does exist.  I guess the search utilities does not report files that start with a period.

(?Asside?  I've installed  “Configuration Editor” (Search for Files Manual, Chapter 4, Settings), to attempt to change this default of not reporting files that start with a period but I am unsuccessful.  This is out of topic for this bugzilla, however, a one liner pointing to where I'm going wrong in getting gnomme-search-tool to find files that start with a period would be appretiated.)

I have attached this file.

I will attach /var/log/Xorg.0.log as well.  FYI , the same directory also has:

Xorg.0.log.old 
Xorg.1.log
Xorg.1.log.old 
Xorg.2.log.old 
Xorg.2.log

If you are interested in preserving any of these files, let me know.  

Perhaps I should upload significant configuration folders to a ftp .  I could place several Gigs on  my ISP's server. Or make a DVD.  

Let's milk the observations we can from this machine state before we destroy it.  You are welcomed to indulge me, if you think it may be of value.

Regards,
André
Comment 11 Andre Michaud 2008-12-20 10:39:55 EST
Created attachment 327537 [details]
Xorg.0.log as requested
Comment 12 Ray Strode [halfline] 2008-12-20 11:39:16 EST
when you boot up, if you hold the ctrl key down you should see the grub boot menu.

if you then press "e" it should take you to a menu that says things like "kernel" and "initrd".  If you arrow to the line that says kernel and press "e" again and then add the word " nomodeset" to the end of the line and press enter followed by "b" your system should boot without modesetting enabled.

Does that prevent the crashes from happening?
Comment 13 Andre Michaud 2008-12-20 13:08:26 EST
Observation:
Grub menu:  Fedora (2.6.27.5-117.fc10.i686)
Architecture?  I thought I had an i386.  
I checked the DVD I burned to make this installation:  
I had labelled this DVD Fedora-10-i386-DVD
file .discinfo on the root directory of this DVD has:
	1227142402.812888
	Fedora 10
	i386
	ALL

if not interesting – ignore.

Following your instructions:

Screen:  [Minimal BASH-like line editing is supported (...) changes.]
<0f4-1ee2-49d0-9cd7-4be1bd041c47 rhgb quiet
And I type “nomodeset” at the end of this line.

Success !
Bug disappeared on double click:  clear_window ...and set_ploy.txt
Bug disappeared on double click:  clear_window ...and set_plot.txt
Bug disappeared on double click:  BIC.R
BUG disappeared on create a new file in gedit and save as BIC.R
BUG disappeared on create a new file in gedit and save as clear_...plot.txt

Reboot with modesetting enabled
System crashes on double click:  clear_window ...and set_ploy.txt

Re-boot with modesetting enabled
System crashes on double click:  clear_window ...and set_plot.txt

Reboot with modesetting enabled
Does not crash on save new file as BIC.R
System crashes on create a new file in gedit and save as clear_window_and_setup_plot.txt

Try again :
Reboot without modesetting enabled
Bug disappeared on double click:  clear_window ...and set_ploy.txt
Bug disappeared on double click:  clear_window ...and set_plot.txt
Bug disappeared on double click:  BIC.R

One more try:
Re-boot with modesetting enabled
Bug disappeared on double click:  clear_window ...and set_ploy.txt
System crashes on create a new file in gedit and save as clear_window_and_setup_plot.txt

Re-boot with modesetting enabled
System crashes on create a new file in gedit and save as clear_window_and_setup_plot.txt

What next?
Comment 14 Andre Michaud 2008-12-30 13:02:02 EST
I can no longer reproduce the crash.  I'm removing this installation from this pc.  One final observation: the mouse pointer icon gets corrupted when changing users. I hope the above observations proved usefull to you.
Comment 15 Ray Strode [halfline] 2009-01-05 14:12:38 EST
Okay, I'm going to move this to kernel.

Thank you for taking the time to investigate.
Comment 16 Bug Zapper 2009-11-18 07:41:48 EST
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 17 Bug Zapper 2009-12-18 02:19:48 EST
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.