Bug 504413 - xmgrace wont start in FC11
xmgrace wont start in FC11
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: grace (Show other bugs)
11
All Linux
low Severity high
: ---
: ---
Assigned To: José Matos
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-06-06 09:04 EDT by Mark van Rossum
Modified: 2014-01-21 01:13 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-07-31 14:59:20 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Mark van Rossum 2009-06-06 09:04:20 EDT
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).
Comment 1 Mark van Rossum 2009-06-06 10:34:38 EDT
Perhaps related to bug 488510
Comment 2 Mikko Huhtala 2009-06-09 12:18:02 EDT
I see this, too, with the same strace output.This is up-to-date F11 with grace-5.1.22-3.fc11.i586.
Comment 3 Mark van Rossum 2009-06-09 12:38:15 EDT
To add to the complication, it works fine my other computer,
which is a 64bit FC11.

(In that case I display the window remotely.)
Comment 4 Jacek Pawlyta 2009-06-18 08:04:06 EDT
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.
Comment 5 José Matos 2009-06-18 12:34:35 EDT
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.
Comment 6 Harsh 2009-06-24 13:10:17 EDT
Confirming the same on fc11.i686 32 bit.
Comment 7 Jussi Eloranta 2009-07-04 22:08:01 EDT
I just compiled the latest xmgrace from source. Runs fine. However, the FC11 rpm of xmgrace (or grace that is) does not.
Comment 8 lsd 2009-07-07 14:33:47 EDT
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.
Comment 9 seth vidal 2009-07-16 16:10:51 EDT
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.
Comment 10 José Matos 2009-07-17 15:19:51 EDT
(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. :-)
Comment 11 Jussi Eloranta 2009-07-17 16:26:25 EDT
Probably a separate issue but on most intel based video cards, the fonts are completely garbled. ATI & others seem to be just fine.
Comment 12 seth vidal 2009-07-17 18:07:35 EDT
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?
Comment 13 José Matos 2009-07-18 06:18:19 EDT
(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.
Comment 14 José Matos 2009-07-18 06:24:16 EDT
(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. :-)
Comment 15 Jussi Eloranta 2009-07-18 15:34:44 EDT
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.
Comment 16 Paul van Maaren 2009-07-19 14:16:07 EDT
I can confirm that removing the newline (x0a) from /etc/grace/FontDataBase resolves the problem. No idea why...
Comment 17 José Matos 2009-07-20 14:47:46 EDT
(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?
Comment 18 José Matos 2009-07-20 14:58:08 EDT
(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. :-)
Comment 19 seth vidal 2009-07-20 15:04:09 EDT
I removed it with a text editor. With any other tool just read the whole file -1.
Comment 20 Fedora Update System 2009-07-21 05:17:57 EDT
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
Comment 21 Fedora Update System 2009-07-23 15:11:34 EDT
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.
Comment 22 José Matos 2009-07-31 14:59:20 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.