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 372379 - crash in Text Editor: opening an odt file on a...
crash in Text Editor: opening an odt file on a...
Status: RESOLVED DUPLICATE of bug 354046
Product: gedit
Classification: Applications
Component: general
2.16.x
Other All
: High critical
: ---
Assigned To: Gedit maintainers
Gedit maintainers
Depends on:
Blocks:
 
 
Reported: 2006-11-08 09:51 UTC by sim
Modified: 2006-11-14 08:59 UTC
See Also:
GNOME target: ---
GNOME version: 2.15/2.16


Description sim 2006-11-08 09:51:29 UTC 
Version: 2.16.1

What were you doing when the application crashed?
opening an odt file on a samba share


Distribution: Ubuntu 6.10 (edgy)
Gnome Release: 2.16.1 2006-10-02 (Ubuntu)
BugBuddy Version: 2.16.0

Memory status: size: 44191744 vsize: 0 resident: 44191744 share: 0 rss: 20434944 rss_rlim: 0
CPU usage: start_time: 1162979406 rtime: 0 utime: 59 stime: 0 cutime:52 cstime: 0 timeout: 7 it_real_value: 0 frequency: 0

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

(no debugging symbols found)
Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread -1227204944 (LWP 21802)]
(no debugging symbols found)
0xffffe410 in __kernel_vsyscall ()

+ Trace 84284

Thread 1 (Thread -1227204944 (LWP 21802))

  • #0 __kernel_vsyscall
  • #1 __waitpid_nocancel
    from /lib/tls/i686/cmov/libpthread.so.0
  • #2 gnome_gtk_module_info_get
    from /usr/lib/libgnomeui-2.so.0
  • #3 <signal handler called>
  • #4 g_utf8_validate
    from /usr/lib/libglib-2.0.so.0
  • #5 gedit_convert_from_utf8
  • #6 gedit_convert_to_utf8
  • #7 gedit_document_new
  • #8 gedit_document_new
  • #9 g_source_get_current_time
    from /usr/lib/libglib-2.0.so.0
  • #10 g_main_context_dispatch
    from /usr/lib/libglib-2.0.so.0
  • #11 g_main_context_check
    from /usr/lib/libglib-2.0.so.0
  • #12 g_main_loop_run
    from /usr/lib/libglib-2.0.so.0
  • #13 gtk_main
    from /usr/lib/libgtk-x11-2.0.so.0
  • #14 main
  • #0 __kernel_vsyscall 






Comment 1


Paolo Borelli





          2006-11-08 09:56:14 UTC
        



Thanks for taking the time to report this bug.
This particular bug has already been reported into our bug tracking system, but the maintainers need more information to fix the bug. Could you please answer the questions in the other report in order to help the developers?


*** This bug has been marked as a duplicate of 363596 ***






Comment 2


Karsten Bräckelmann





          2006-11-14 00:09:51 UTC
        



Actually, this is the same issue as another bug.

Sim, the need for more information still stands, though. :)


*** This bug has been marked as a duplicate of 354046 ***






Comment 3


sim





          2006-11-14 08:47:29 UTC
        



I had a openoffice file (.odt) that wouldn't open in openoffice. It said 'read error' in openoffice. Then i tried to open the file in gedit. It crashed. The file was on a samba mount. I couldn't read any files from this filesystem. It was producing errors in the syslog. After umount mount cycle, everything worked OK.






Comment 4


sim





          2006-11-14 08:59:54 UTC
        



Some speculation: 

As one can read in comment #15 from 354046, that crash relates to filesystem corruption. Here fsck fixed the file, and in this case cifs remount fixed it.

So could it be, that an unexpected error code occurs on a read() call, or 0 bytes are read? 

As UTF-8 parsing is a state machine, what happens with the parser on buffer bounderies? Or with an empty buffer? Or a garbage filled buffer?