bug-gnu-pspp
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: PSPP-BUG: [GUI] PSPPire closes unexpectedly when entering text with


From: Ben Pfaff
Subject: Re: PSPP-BUG: [GUI] PSPPire closes unexpectedly when entering text with a length greater than 80 bytes (Utilities | Data File comments)
Date: Mon, 7 Oct 2013 20:41:05 -0700
User-agent: Mutt/1.5.21 (2010-09-15)

Thanks.  They didn't seem necessary when I tested, so I applied the
patch.

On Sun, Oct 06, 2013 at 06:58:04PM +0200, John Darrington wrote:
> If, as you say, those lines are unnecessary, then please apply the patch that 
> you posted.
> 
> J'
> 
> 
> On Sun, Oct 06, 2013 at 09:40:22AM -0700, Ben Pfaff wrote:
>      On Sun, Oct 06, 2013 at 06:28:14PM +0200, John Darrington wrote:
>      > I don't seem to be able to reproduce this crash.
>      > 
>      > It looks as if the code you deleted was designed to move the cursor to 
> the end of the text,
>      > after something has been pasted.  Which is probably what the user 
> wants.  
>      
>      I don't think this is necessary, because GtkTextView maintains its
>      cursor as a mark.  Inserting a newline in its buffer prior to the cursor
>      will push along onto the next line anyway, without extra help.
>      
>      > I don't know why is is crashing.  Does it fix the problem if you call  
> gtk_text_buffer_place_cursor
>      > only if gtk_text_iter_forward_to_line_end returns TRUE ?
>      
>      The problem is that the GtkTextIter gets invalidated by the
>      gtk_text_buffer_insert() call.  On my system, at least, I get a
>      Gtk-WARNING about this:
>      
>          (psppire:13161): Gtk-WARNING **: Invalid text buffer iterator: 
> either the iterator is uninitialized, or the characters/pixbufs/widgets in 
> the buffer have been modified since the iterator was created.
>          You must use marks, character numbers, or line numbers to preserve a 
> position across buffer modifications.
>          You can apply tags and insert marks without invalidating your 
> iterators,
>          but any mutation that affects 'indexable' buffer contents (contents 
> that can be referred to by character offset)
>          will invalidate all outstanding iterators
>      
>      Running under valgrind shows a subsequent bad memory access that I
>      imagine to be related to the previous warning:
>      
>          Invalid read of size 4
>             at 0x44C9B4F: gtk_text_iter_make_real (gtktextiter.c:202)
>             by 0x44CB9CC: gtk_text_iter_forward_line (gtktextiter.c:2490)
>             by 0x44CBF0F: gtk_text_iter_forward_to_line_end 
> (gtktextiter.c:4052)
>             by 0x808B902: wrap_line (comments-dialog.c:84)
>             by 0x4416777: _gtk_marshal_VOID__BOXED_STRING_INT 
> (gtkmarshalers.c:1425)
>             by 0x4C12DC1: g_closure_invoke (gclosure.c:777)
>             by 0x4C24C95: signal_emit_unlocked_R (gsignal.c:3621)
>             by 0x4C2CB55: g_signal_emit_valist (gsignal.c:3300)
>             by 0x4C2CCD2: g_signal_emit (gsignal.c:3356)
>             by 0xD9E75B7: ???
>           Address 0x1c is not stack'd, malloc'd or (recently) free'd
>      
>      
>          Process terminating with default action of signal 11 (SIGSEGV): 
> dumping core
>           Access not within mapped region at address 0x1C
>             at 0x44C9B4F: gtk_text_iter_make_real (gtktextiter.c:202)
>             by 0x44CB9CC: gtk_text_iter_forward_line (gtktextiter.c:2490)
>             by 0x44CBF0F: gtk_text_iter_forward_to_line_end 
> (gtktextiter.c:4052)
>             by 0x808B902: wrap_line (comments-dialog.c:84)
>             by 0x4416777: _gtk_marshal_VOID__BOXED_STRING_INT 
> (gtkmarshalers.c:1425)
>             by 0x4C12DC1: g_closure_invoke (gclosure.c:777)
>             by 0x4C24C95: signal_emit_unlocked_R (gsignal.c:3621)
>             by 0x4C2CB55: g_signal_emit_valist (gsignal.c:3300)
>             by 0x4C2CCD2: g_signal_emit (gsignal.c:3356)
>             by 0xD9E75B7: ???
>      
>      The patch I provided avoids the warning and the bad memory accesses.
> 
> -- 
> PGP Public key ID: 1024D/2DE827B3 
> fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
> See http://sks-keyservers.net or any PGP keyserver for public key.
> 





reply via email to

[Prev in Thread] Current Thread [Next in Thread]