abrt version: 1.1.14 architecture: i686 Attached file: backtrace cmdline: xmgrace component: grace crash_function: _int_malloc executable: /usr/bin/xmgrace kernel: 2.6.35.6-48.fc14.i686.PAE package: grace-5.1.22-7.fc14 rating: 4 reason: Process /usr/bin/xmgrace was killed by signal 6 (SIGABRT) release: Fedora release 14 (Laughlin) time: 1290644257 uid: 500 How to reproduce ----- 1. suddently 2. 3.
Created attachment 462786 [details] File: backtrace
This may or may not be related to this bug: 657121. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Package: grace-5.1.22-7.fc14 Architecture: i686 OS Release: Fedora release 14 (Laughlin) How to reproduce ----- 1. started xmgrace from terminal 2. it crashed 3.
Package: grace-5.1.22-7.fc14 Architecture: i686 OS Release: Fedora release 14 (Laughlin) How to reproduce ----- 1. start grace 2. then crash 3.
Package: grace-5.1.22-7.fc14 Architecture: i686 OS Release: Fedora release 14 (Laughlin) How to reproduce ----- 1. Happens everytime I try to start xmgrace. This seems to only happen on mac minis (with intel graphics cards). 2. 3.
OK, I take it back. It does not work on nvidia systems either. I think that the computer where it worked had manually compiled xmgrace...
*** Bug 665239 has been marked as a duplicate of this bug. ***
Package: grace-5.1.22-7.fc14 Architecture: i686 OS Release: Fedora release 14 (Laughlin) How to reproduce ----- 1. just typing 'xmgrace' 2. 3. Comment ----- just type xmgrace somefile.xy
Package: grace-5.1.22-7.fc14 Architecture: i686 OS Release: Fedora release 14 (Laughlin) How to reproduce ----- 1.opened the program and it crashed 2. 3.
Created attachment 471082 [details] xmgrace workaround
Package: grace-5.1.22-7.fc14 Architecture: i686 OS Release: Fedora release 14 (Laughlin) How to reproduce ----- 1. I turned on my pc Dell Vostro 1500, with fedora 14 (x86, 32 bit) , kernel 2.6.35.10-74, GNOME2.32.0 2. I tried to run grace-5.1.22-7 through my taskbar. 3. grace crashed
Package: grace-5.1.22-7.fc14 Architecture: i686 OS Release: Fedora release 14 (Laughlin) (xvpappliance unknown) How to reproduce ----- 1. Start xmgrace 2. 3.
If you run xmgrace under valgrind (ie. valgrind xmgrace) then it works and the errors given include the section ==16808== Source and destination overlap in memcpy(0x434c5d8, 0x434c5ec, 60) ==16808== at 0x4007CB5: memcpy (mc_replace_strmem.c:602) ==16808== by 0x20FBE2: _XmBuildResources (in /usr/lib/libXm.so.2.0.1) ==16808== by 0x1F81DF: ??? (in /usr/lib/libXm.so.2.0.1) ==16808== by 0x5F8B8E7: ??? (in /usr/lib/libXt.so.6.0.0) ==16808== by 0x5F8B8DB: ??? (in /usr/lib/libXt.so.6.0.0) ==16808== by 0x5F8B8DB: ??? (in /usr/lib/libXt.so.6.0.0) ==16808== by 0x5F8BDA5: XtInitializeWidgetClass (in /usr/lib/libXt.so.6.0.0) ==16808== by 0x5F8CE27: _XtCreateWidget (in /usr/lib/libXt.so.6.0.0) ==16808== by 0x5F8D1F2: XtCreateWidget (in /usr/lib/libXt.so.6.0.0) ==16808== by 0x1DB3FE: XmCreateForm (in /usr/lib/libXm.so.2.0.1) ==16808== by 0x80E468D: ??? (in /usr/bin/xmgrace) ==16808== by 0x8053233: ??? (in /usr/bin/xmgrace) This indicates that memcpy is being used to copy overlapping memory areas, which is against POSIX definition of memcpy, but used to work until glibc introduced some code to try to speed up memcpy in glibc-2.12.90-4 which broke it. It will work within valgrind because that uses its own memcpy as part of its problem detection. It can be fixed by locating the troublesome memcpy and replacing it with memmove. See Bug 638477 for a long discussion of the same basic issue for the 64-bit flash plugin preview.
I have looked a bit further and I think the crash is happening before the above issue. The valgrind output has an earlier issue which is presumably the real cause, the full output is below ==2353== Memcheck, a memory error detector ==2353== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==2353== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info ==2353== Command: xmgrace ==2353== ==2353== Invalid write of size 1 ==2353== at 0xB1539E: intT1_GetFileSearchPath (t1env.c:827) ==2353== by 0xB117CF: intT1_scanFontDBase (t1base.c:457) ==2353== by 0xB12393: T1_InitLib (t1base.c:319) ==2353== by 0x809E2B6: ps_initgraphics (stdio2.h:98) ==2353== by 0x80527A5: drawseterrbars (plotone.c:1539) ==2353== by 0x86DE15: (below main) (libc-start.c:226) ==2353== Address 0x40248e4 is not stack'd, malloc'd or (recently) free'd ==2353== ==2353== Source and destination overlap in memcpy(0x41e9a68, 0x41e9a7c, 60) ==2353== at 0x4007CB5: memcpy (mc_replace_strmem.c:602) ==2353== by 0x20FBE2: _XmBuildResources (Scale.c:759) ==2353== by 0x1F81DF: _XmMessageBoxInstallImages (MessageB.c:728) ==2353== by 0x5F8B8E7: XtAppCreateShell (Create.c:724) ==2353== by 0x5F8B8DB: XtAppCreateShell (Create.c:724) ==2353== by 0x5F8B8DB: XtAppCreateShell (Create.c:724) ==2353== by 0x5F8BDA5: XtInitializeWidgetClass (Create.c:537) ==2353== by 0x5F8CE27: CloseDisplay (Display.c:612) ==2353== by 0x5F8D1F2: XtCloseDisplay (Display.c:668) ==2353== by 0x1DB3FE: XmCreateForm (ImageCache.c:397) ==2353== by 0x80E468D: incbet (incbet.c:251) ==2353== by 0x8053233: drawsetavalues (string3.h:107) ==2353== ==2353== ==2353== HEAP SUMMARY: ==2353== in use at exit: 627,094 bytes in 9,843 blocks ==2353== total heap usage: 21,757 allocs, 11,914 frees, 2,949,813 bytes allocated ==2353== ==2353== LEAK SUMMARY: ==2353== definitely lost: 418 bytes in 12 blocks ==2353== indirectly lost: 84 bytes in 3 blocks ==2353== possibly lost: 76,560 bytes in 2,782 blocks ==2353== still reachable: 550,032 bytes in 7,046 blocks ==2353== suppressed: 0 bytes in 0 blocks ==2353== Rerun with --leak-check=full to see details of leaked memory ==2353== ==2353== For counts of detected and suppressed errors, rerun with: -v ==2353== ERROR SUMMARY: 37 errors from 2 contexts (suppressed: 70 from 10)
Created attachment 473811 [details] fixed patch for t1lib I have tracked the problem down. It is in the t1lib-5.1.2-segf.patch fix to t1lib http://pkgs.fedoraproject.org/gitweb/?p=t1lib.git;a=blob_plain;f=t1lib-5.1.2-segf.patch;hb=f703f6b3d98c03cbc88e46c47145dc9ae36b9426 The problem is that the existing patch truncates a string to 900 characters by writing 0 at position 901. Unfortunately it doesn't check that the string is more than 900 characters long (and in Fedora 14 I am guessing it isn't), and so is writing 0 to a memory location used by something else. If I replace t1lib-5.1.2-segf.patch with the attached patch and rebuild t1lib then xmgrace works for me, and one less error is reported while running it under valgrind. I don't however think it is the right way to fix the segfault the original patch was written to fix - the right way to fix that would be to limit the string to 900 bytes as it is generated, rather than truncating it afterwards as the latter will leak some memory.
Changing package component from grace to t1lib.
*** Bug 675555 has been marked as a duplicate of this bug. ***
Backtrace analysis found this bug to be similar to bug #649917, closing as duplicate. Bugs which were found to be similar to this bug: grace: bug #649917, bug #654927, bug #675555, bug #699060, bug #753474, bug #766585, bug #766632 This comment is automatically generated. *** This bug has been marked as a duplicate of bug 649917 ***