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

Bug#541160: Bug#541236: #541236 xterm: word selection selects whitespace characters too



On 2009-08-16 10:59:14 -0400, Thomas Dickey wrote:
> On Sat, Aug 15, 2009 at 03:26:45AM +0200, Vincent Lefevre wrote:
> > tags 541236 patch
> > thanks
> > 
> > On 2009-08-14 20:53:52 -0400, Thomas Dickey wrote:
> > > Here's a copy of current changes for #246, which includes a fix
> > > for this bug.
> > 
> > Thanks, I've tested it and it indeed fixes this bug.
> 
> Looking at my email, it's not clear whether you still found a segmentation
> violation after applying the patch for alignment, which would also address
> 541160.

Your patch fixes bug 541236 only. Bug 541160 is still there.

> Is that still reproducible?
> 
> If so, perhaps a valgrind log would help.

==32692== Memcheck, a memory error detector.
==32692== Copyright (C) 2002-2008, and GNU GPL'd, by Julian Seward et al.
==32692== Using LibVEX rev 1884, a library for dynamic binary translation.
==32692== Copyright (C) 2004-2008, and GNU GPL'd, by OpenWorks LLP.
==32692== Using valgrind-3.4.1-Debian, a dynamic binary instrumentation framework.
==32692== Copyright (C) 2000-2008, and GNU GPL'd, by Julian Seward et al.
==32692== For more details, rerun with: -v
==32692== 
==32692== My PID = 32692, parent PID = 32263.  Prog and args are:
==32692==    /home/vinc17/software/xterm-244.patched/obj-x86_64-linux-gnu/xterm
==32692== 
==32696== Warning: invalid file descriptor -1 in syscall close()
==32692== Invalid write of size 1
==32692==    at 0x430560: Reallocate (screen.c:547)
==32692==    by 0x4308B9: ScreenResize (screen.c:2009)
==32692==    by 0x5DD03A9: XtConfigureWidget (in /usr/lib/libXt.so.6.0.0)
==32692==    by 0x508E6FF: XawVendorShellExtResize (in /usr/lib/libXaw7.so.7.0.0)
==32692==    by 0x5DCD107: XtDispatchEventToWidget (in /usr/lib/libXt.so.6.0.0)
==32692==    by 0x5DCD92A: (within /usr/lib/libXt.so.6.0.0)
==32692==    by 0x5DCCB3A: XtDispatchEvent (in /usr/lib/libXt.so.6.0.0)
==32692==    by 0x42AE17: xevents (misc.c:459)
==32692==    by 0x4187AD: VTparse (charproc.c:3437)
==32692==    by 0x418BE1: VTRun (charproc.c:4957)
==32692==    by 0x4243B0: main (main.c:2414)
==32692==  Address 0x108103dd2 is not stack'd, malloc'd or (recently) free'd
==32692== 
==32692== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==32692==  Access not within mapped region at address 0x108103DD2
==32692==    at 0x430560: Reallocate (screen.c:547)
==32692==    by 0x4308B9: ScreenResize (screen.c:2009)
==32692==    by 0x5DD03A9: XtConfigureWidget (in /usr/lib/libXt.so.6.0.0)
==32692==    by 0x508E6FF: XawVendorShellExtResize (in /usr/lib/libXaw7.so.7.0.0)
==32692==    by 0x5DCD107: XtDispatchEventToWidget (in /usr/lib/libXt.so.6.0.0)
==32692==    by 0x5DCD92A: (within /usr/lib/libXt.so.6.0.0)
==32692==    by 0x5DCCB3A: XtDispatchEvent (in /usr/lib/libXt.so.6.0.0)
==32692==    by 0x42AE17: xevents (misc.c:459)
==32692==    by 0x4187AD: VTparse (charproc.c:3437)
==32692==    by 0x418BE1: VTRun (charproc.c:4957)
==32692==    by 0x4243B0: main (main.c:2414)
==32692==  If you believe this happened as a result of a stack overflow in your
==32692==  program's main thread (unlikely but possible), you can try to increase
==32692==  the size of the main thread stack using the --main-stacksize= flag.
==32692==  The main thread stack size used in this run was 8388608.
==32692== 
==32692== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 8 from 1)
==32692== malloc/free: in use at exit: 785,352 bytes in 2,154 blocks.
==32692== malloc/free: 6,605 allocs, 4,451 frees, 1,299,471 bytes allocated.
==32692== For counts of detected errors, rerun with: -v
==32692== searching for pointers to 2,154 not-freed blocks.
==32692== checked 1,124,184 bytes.
==32692== 
==32692== LEAK SUMMARY:
==32692==    definitely lost: 3,689 bytes in 6 blocks.
==32692==      possibly lost: 0 bytes in 0 blocks.
==32692==    still reachable: 781,663 bytes in 2,148 blocks.
==32692==         suppressed: 0 bytes in 0 blocks.
==32692== Rerun with --leak-check=full to see details of leaked memory.

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)



Reply to: