Bug 504413
| Summary: | xmgrace wont start in FC11 | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Mark van Rossum <mvanross> |
| Component: | grace | Assignee: | José Matos <jamatos> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | high | Docs Contact: | |
| Priority: | low | ||
| Version: | 11 | CC: | cunio, eloranta, harsh_uict, jamatos, lada48, mhuhtala, paul, pertusus |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2009-07-31 18:59:20 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Perhaps related to bug 488510 I see this, too, with the same strace output.This is up-to-date F11 with grace-5.1.22-3.fc11.i586. To add to the complication, it works fine my other computer, which is a 64bit FC11. (In that case I display the window remotely.) I'm confirming the same, Fedora 11 i586 32bit! The solution is to change directory to /usr/share/grace and start xmgrace being in this directory. I am puzzled why this happens. I can confirm that it fails in x86-32 but it works in x86-64. Initially I suspected that it was related to the fonts changes in F11 but this would not explain why it works in one arch and not on the other. Confirming the same on fc11.i686 32 bit. I just compiled the latest xmgrace from source. Runs fine. However, the FC11 rpm of xmgrace (or grace that is) does not. Same problem fc11.i686. Tried to install from source but could not...missing M*tiff. However, when you untar source you get folder "fonts". I copied this folder into the directory /usr/share/grace/fonts (overwrote whatever was there) and xmgrace works normally. I can open it from any directory. I am no advanced user, maybe only the default path in fonts is wrong or something with symbolic links. You guys are in better position to fix this. bizarrely - modifying the FontDataBase file in ALMOST any way "fixes" it. If you modify the number of fonts it lists or remove any of the lines or remove the '\n' at the very end of the file - then xmgrace starts working from any directory. Maybe there is something very special and very fragile about how it reads this file. (In reply to comment #9) > bizarrely - modifying the FontDataBase file in ALMOST any way "fixes" it. If > you modify the number of fonts it lists or remove any of the lines or remove > the '\n' at the very end of the file - then xmgrace starts working from any > directory. > Maybe there is something very special and very fragile about how it reads > this file. My FontDataBase file does not have a \n at the end. :-) Are you able to reproduce this bug on 64 bits machine? I only get this behavior on 32 bits. Running strace on the running instance it fails after reading the file and all its lines. This bug is quite puzzling. :-) Probably a separate issue but on most intel based video cards, the fonts are completely garbled. ATI & others seem to be just fine. I don't have a 64bit machine to try it on right now - only x86. look at the file in a hexeditor - is the last char in the file 0a? (In reply to comment #11) > Probably a separate issue but on most intel based video cards, the fonts are > completely garbled. ATI & others seem to be just fine. https://bugzilla.redhat.com/show_bug.cgi?id=484273 Worse than that, my home machine is a desktop with an intel graphics card and does not show this problem. I saw this bug on a friend's laptop, the bug is gone with F11, so I really suspect that this is related with the xorg driver. (In reply to comment #12) > I don't have a 64bit machine to try it on right now - only x86. I have been able to reproduce this bug only on 32 bits. I suspect that there is some memory violation of some type, running valgrind over the executable I get (note that then grace will start, there is no crash): $ valgrind xmgrace ==2471== Memcheck, a memory error detector. ==2471== Copyright (C) 2002-2008, and GNU GPL'd, by Julian Seward et al. ==2471== Using LibVEX rev 1884, a library for dynamic binary translation. ==2471== Copyright (C) 2004-2008, and GNU GPL'd, by OpenWorks LLP. ==2471== Using valgrind-3.4.1, a dynamic binary instrumentation framework. ==2471== Copyright (C) 2000-2008, and GNU GPL'd, by Julian Seward et al. ==2471== For more details, rerun with: -v ==2471== ==2471== Invalid write of size 1 ==2471== at 0x72E80D: intT1_GetFileSearchPath (in /usr/lib/libt1.so.5.1.2) ==2471== by 0x72AC4F: intT1_scanFontDBase (in /usr/lib/libt1.so.5.1.2) ==2471== by 0x72B857: T1_InitLib (in /usr/lib/libt1.so.5.1.2) ==2471== by 0x8094EB4: (within /usr/bin/xmgrace) ==2471== by 0x804E8E5: (within /usr/bin/xmgrace) ==2471== by 0x37EA65: (below main) (in /lib/libc-2.10.1.so) ==2471== Address 0x4046884 is not stack'd, malloc'd or (recently) free'd ==2471== ==2471== Source and destination overlap in memcpy(0x424DDB0, 0x424DDC4, 60) ==2471== at 0x4007B55: memcpy (mc_replace_strmem.c:402) ==2471== by 0xB3BFF3: _XmBuildResources (in /usr/lib/libXm.so.2.0.1) ==2471== by 0xB24717: (within /usr/lib/libXm.so.2.0.1) ==2471== by 0x4983659: (within /usr/lib/libXt.so.6.0.0) ==2471== by 0x498364A: (within /usr/lib/libXt.so.6.0.0) ==2471== by 0x498364A: (within /usr/lib/libXt.so.6.0.0) ==2471== by 0x4983B4A: XtInitializeWidgetClass (in /usr/lib/libXt.so.6.0.0) ==2471== by 0x4984BBF: _XtCreateWidget (in /usr/lib/libXt.so.6.0.0) ==2471== by 0x4984F91: XtCreateWidget (in /usr/lib/libXt.so.6.0.0) ==2471== by 0xB0790D: XmCreateForm (in /usr/lib/libXm.so.2.0.1) ==2471== by 0x80D47CC: (within /usr/bin/xmgrace) ==2471== by 0x804F32C: (within /usr/bin/xmgrace) ==2471== ==2471== ERROR SUMMARY: 37 errors from 2 contexts (suppressed: 41 from 2) ==2471== malloc/free: in use at exit: 661,712 bytes in 10,627 blocks. ==2471== malloc/free: 21,227 allocs, 10,600 frees, 3,125,512 bytes allocated. ==2471== For counts of detected errors, rerun with: -v ==2471== searching for pointers to 10,627 not-freed blocks. ==2471== checked 1,324,868 bytes. ==2471== ==2471== LEAK SUMMARY: ==2471== definitely lost: 365 bytes in 14 blocks. ==2471== possibly lost: 0 bytes in 0 blocks. ==2471== still reachable: 661,347 bytes in 10,613 blocks. ==2471== suppressed: 0 bytes in 0 blocks. ==2471== Rerun with --leak-check=full to see details of leaked memory. > look at the file in a hexeditor - is the last char in the file 0a? Fair enough. :-) THe fonts being corrupted on some Intel cards seems to be related to graphics acceleration. If I set "noaccel" to "true" option in my xorg.conf, xmgrace works just fine. On the same system X11 version of emacs showed the same problem... It also started working after specifying noaccel true. The intel card in question is: 82845G/GL[Brookdale-G]/GE as shown by lspci. At home I have newer Intel card (forgot the model) and that seems to work correctly. I can confirm that removing the newline (x0a) from /etc/grace/FontDataBase resolves the problem. No idea why... (In reply to comment #15) > THe fonts being corrupted on some Intel cards seems to be related to graphics > acceleration. If I set "noaccel" to "true" option in my xorg.conf, xmgrace > works just fine. On the same system X11 version of emacs showed the same > problem... It also started working after specifying noaccel true. The intel > card in question is: 82845G/GL[Brookdale-G]/GE as shown by lspci. At home I > have newer Intel card (forgot the model) and that seems to work correctly. Could you, please, add this to #484273? (In reply to comment #16) > I can confirm that removing the newline (x0a) from /etc/grace/FontDataBase > resolves the problem. No idea why... How did you remove that last newline \n? Is there a simple recipe to remove the last newline from a file if it is the last character? I have been playing with some of the coreutils without any success. :-( Any help is appreciated. :-) I removed it with a text editor. With any other tool just read the whole file -1. grace-5.1.22-4.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/grace-5.1.22-4.fc11 grace-5.1.22-4.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report. Since the update is out for more than a week and there are no new complains and (important!) it works for me on 32 and 64 bits I will close the bug. If for some reason this does not work please reopen the bug with further details. Thanks. |
Description of problem: starting xmgrace from xterm just hangs there. strace xmgrace gives: munmap(0xb8030000, 4096) = 0 access("/usr/share/X11/locale/C/XLC_LOCALE", R_OK) = 0 open("/usr/share/X11/locale/C/XLC_LOCALE", O_RDONLY) = 4 fstat64(4, {st_mode=S_IFREG|0644, st_size=772, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb8030000 read(4, "# $Xorg: C,v 1.3 2000/08/17 19:4"..., 4096) = 772 read(4, ""..., 4096) = 0 close(4) = 0 munmap(0xb8030000, 4096) = 0 futex(0x288380, FUTEX_WAIT, 2, NULL (Note, my system is currently under a heavy load, but that should not matter).