bugGnome Chemistry Utils - Bugs: bug #40194, Crash because of invalid...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #40194: Crash because of invalid "fragment"

Submitted by:  Martin Steghöfer <martinsteghoefer>
Submitted on:  Mon 07 Oct 2013 10:51:53 AM UTC  
 
Category: NoneSeverity: 4 - Important
Item Group: NoneStatus: Fixed
Privacy: PublicAssigned to: Jean Bréfort <jean_brefort>
Open/Closed: Closed

Mon 07 Oct 2013 10:51:53 AM UTC, original submission:

The file attached to this bug report loads without any errors. But once loaded, many operations (as little as hovering over the only object in the file can be enough) make the program crash with a segmentation fault.

The reason seems to be that after loading the file there is a Fragment object whose m_Atom member is NULL. Various actions can trigger functions that call member of this m_Atom, typically the calling sequence goes through the "FragmentAtom::SetZ -> Fragment::OnChangeAtom" call path, like here for hovering over the "fragment":

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7b219f6 in gcp::Fragment::OnChangeAtom (this=0xe897e0) at fragment.cc:1196
1196 string sym = m_Atom->GetSymbol ();
(gdb) backtrace
#0 0x00007ffff7b219f6 in gcp::Fragment::OnChangeAtom (this=0xe897e0) at fragment.cc:1196
#1 0x00007ffff7b19207 in gcp::FragmentAtom::SetZ (this=0xf48600, Z=-1) at fragment-atom.cc:66
#2 0x00007ffff7b19098 in gcp::FragmentAtom::FragmentAtom (this=0xf48600, fragment=0xe897e0, Z=-1) at fragment-atom.cc:50
#3 0x00007ffff7b19eef in gcp::FragmentResidue::FragmentResidue (this=0xf48600, fragment=0xe897e0, symbol=0x7fffffffd480 "Et") at fragment-residue.cc:40
#4 0x00007ffff7b2113e in gcp::Fragment::GetAtomAt (this=0xe897e0, x=649.912109375, y=188.8304443359375, z=0) at fragment.cc:1122
#5 0x00007ffff7b78df4 in gcp::View::OnMotion (this=0xb3fcf0, client=0xe89870, x=162.47802734375, y=47.207611083984375, state=16) at view.cc:1037
#6 0x00007ffff4223d57 in gccv::CanvasPrivate::OnMotion (canvas=0xb40a60, event=0xfa6e80) at canvas.cc:144
#7 0x00007ffff6b3a3be in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#8 0x00007ffff49c33b7 in ?? () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#9 0x00007ffff49dbe82 in g_signal_emit_valist () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#10 0x00007ffff49dcae2 in g_signal_emit () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#11 0x00007ffff6c5b684 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#12 0x00007ffff6b386bc in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#13 0x00007ffff6b39fa5 in gtk_main_do_event () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#14 0x00007ffff593ed98 in ?? () from /usr/lib/x86_64-linux-gnu/libgdk-3.so.0
#15 0x00007ffff5949f9c in ?? () from /usr/lib/x86_64-linux-gnu/libgdk-3.so.0
#16 0x00007ffff49c33b7 in ?? () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#17 0x00007ffff49dbe82 in g_signal_emit_valist () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#18 0x00007ffff49dd012 in g_signal_emit_by_name () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#19 0x00007ffff5944439 in ?? () from /usr/lib/x86_64-linux-gnu/libgdk-3.so.0
#20 0x00007ffff5937be8 in ?? () from /usr/lib/x86_64-linux-gnu/libgdk-3.so.0
#21 0x00007ffff66f5f03 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#22 0x00007ffff66f53a6 in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#23 0x00007ffff66f56f8 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#24 0x00007ffff66f5afa in g_main_loop_run () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#25 0x00007ffff6b39455 in gtk_main () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#26 0x000000000040358b in main (argc=0, argv=0x7fffffffe1a0) at main.cc:150

The file was created using the version 0.12 of GChemPaint, while the crash happened in 0.14.3. I understand that the parsing of fragments has changed since 0.12 and now it doesn't seem to be possible to create faulty fragments like that any more. But even so, the program should not crash when using files with faulty fragments. Either fix it when loading the file, so all conditions (e.g. m_Atom != NULL) you are assuming are really met, or at least (minimum solution) check all conditions that you are assuming and refuse to load the file, if they are not met.

Cheers,
Martin Steghöfer

Martin Steghöfer <martinsteghoefer>

 

Attached Files
file #29305:  40194.patch added by jean_brefort (367B - text/x-patch - Patch to fix the crash. The fragment code clearly needs more work.)
file #29304:  Discodermolide 10.gchempaint added by martinsteghoefer (1KiB - application/x-gchempaint - File containing a faulty fragment causing a crash on several actions that are executed on it)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by martinsteghoefer (Submitted the item)
  • -unavailable- added by martinsteghoefer
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 8 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sat 15 Feb 2014 04:31:04 PM UTCjean_brefortOpen/ClosedOpen=>Closed
    Mon 07 Oct 2013 01:06:42 PM UTCjean_brefortAttached File-=>Added 40194.patch, #29305
      StatusConfirmed=>Fixed
    Mon 07 Oct 2013 12:40:52 PM UTCjean_brefortSeverity3 - Normal=>4 - Important
      StatusNone=>Confirmed
      Assigned toNone=>jean_brefort
    Mon 07 Oct 2013 10:51:53 AM UTCmartinsteghoeferAttached File-=>Added Discodermolide 10.gchempaint, #29304
      Carbon-Copy-=>Added martinsteghoefer

    Back to the top


    Powered by Savane 3.1-cleanup1