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.
can you attach the file in question?
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.
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?
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
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 ?
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
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 ?
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
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 ?
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é
Created attachment 327537 [details] Xorg.0.log as requested
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?
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?
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.
Okay, I'm going to move this to kernel. Thank you for taking the time to investigate.
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
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.