Bug#439067: gv segmentation fault while starting up
package gv
tags 439067 + pending confirmed
thanks
* Paul Kimoto <[EMAIL PROTECTED]> [070822 16:53]:
> > Is the environment variable XUSERFILESEARCHPATH set?
>
> Yes, to "/home/mopsa/kimoto/app-defaults/%N". It doesn't seem to matter
> whether I have a "GV" file there or not.
>
> However! gv does not segfault if I unset XUSERFILESEARCHPATH.
Thanks for your feedback. I've finaly found the cause
(resource_buildDatabase implicitly destroying the display's database,
but calling XtResolvePathname when XUSERFILESEARCHPATH is set which
still needs it).
I'll upload a new package fixing this (most likely with the attached
patch) within the next days.
Hochachtungsvoll,
Bernhard R. Link
--- a/src/main.c 2007-08-27 17:20:30.0 +0200
+++ b/src/main.c 2007-08-27 17:05:02.0 +0200
@@ -597,13 +597,10 @@
}
/*### getting resources */
- gv_database = resource_buildDatabase (XtDatabase(gv_display),
- gv_display,
+ gv_database = resource_buildDatabase (gv_display,
gv_class,
gv_name,
&argc,argv);
- XrmSetDatabase (gv_display, gv_database);
-
/*### initializing widget set and creating application shell #*/
--- a/src/resource.c 2007-08-27 17:20:30.0 +0200
+++ b/src/resource.c 2007-08-27 17:08:50.0 +0200
@@ -114,13 +114,14 @@
###*/
XrmDatabase
-resource_buildDatabase (XrmDatabase gvdb,
+resource_buildDatabase (
Display *display,
char *app_class,
char *app_name,
int *argcP,
char **argv)
{
+ XrmDatabase gvdb = XtDatabase(display);
XrmDatabase db = NULL;
String *sP;
String s,t, rpath;
@@ -147,6 +148,9 @@
}
XrmCombineDatabase (gvdb, &db, True);
+ /* CombineDatabase destroyed gvdb==XtDatabase(display), which
+ * XtResolvePathname will access soon, so repair it: */
+ XrmSetDatabase (display, db);
/* ### user resources # */
INFMESSAGE(checking for user resources)
--- a/src/resource.h 2007-06-27 16:42:13.0 +0200
+++ b/src/resource.h 2007-08-27 17:09:25.0 +0200
@@ -38,9 +38,8 @@
#endif
);
-extern XrmDatabase resource_buildDatabase (
+extern XrmDatabase resource_buildDatabase (
#if NeedFunctionPrototypes
- XrmDatabase ,
Display *,
char *,
char *,
Bug#439067: gv segmentation fault while starting up
On Wed, Aug 22, 2007 at 11:01:46AM +0200, Bernhard R. Link wrote: > * Paul Kimoto <[EMAIL PROTECTED]> [070822 01:33]: >> When I run "gv" or "gv SOME_POSTSCRIPT_FILE", it dumps core immediately. > Does it happen for all files or only for specific ones? It happens for the few postscript files I bothered to check, and also when invoked without any arguments. > Does it still happen with an empty home directory? Yes. > Is the environment variable XUSERFILESEARCHPATH set? Yes, to "/home/mopsa/kimoto/app-defaults/%N". It doesn't seem to matter whether I have a "GV" file there or not. However! gv does not segfault if I unset XUSERFILESEARCHPATH. > A backtrace to this would be helpful. After installing (only) libx11-6-dbg, I was able to get the following backtrace: This GDB was configured as "i486-linux-gnu"... Using host libthread_db library "/lib/libthread_db.so.1". (gdb) run Starting program: /home/mopsa/kimoto/builds/gv-3.6.3dfsg.orig/src/gv Failed to read a valid object file image from memory. Program received signal SIGSEGV, Segmentation fault. 0xb7c4f1f7 in GetNEntry (table=0x808d3d8, names=0xbfec180c, classes=0xbfec1800, closure=0xbfec1394) at ../../src/Xrm.c:2483 2483../../src/Xrm.c: No such file or directory. in ../../src/Xrm.c (gdb) back #0 0xb7c4f1f7 in GetNEntry (table=0x808d3d8, names=0xbfec180c, classes=0xbfec1800, closure=0xbfec1394) at ../../src/Xrm.c:2483 #1 0xb7c4fdf3 in XrmQGetResource (db=0x8091c88, names=0xbfec180c, classes=0xbfec1800, pType=0xbfec1828, pValue=0xbfec1818) at ../../src/Xrm.c:2549 #2 0xb7d1a7ef in XtResolvePathname () from /usr/lib/libXt.so.6 #3 0x0806f799 in resource_buildDatabase (gvdb=0x8091c88, display=0x808d440, app_class=0x808a59a "GV", app_name=0x808a597 "gv", argcP=0xbfec2020, argv=0xbfec20a4) at resource.c:160 #4 0x0805f536 in main (argc=0, argv=0xbfec20a4) at main.c:600 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#439067: gv segmentation fault while starting up
* Paul Kimoto <[EMAIL PROTECTED]> [070822 01:33]:
> When I run "gv" or "gv SOME_POSTSCRIPT_FILE", it dumps core immediately.
> According to "strace gv", this happens right after
>
> stat64("/home/mopsa/kimoto/.gv", 0xbf9cf394) = -1 ENOENT (No such file or
> directory)
>
> (although "touch ~/.gv" doesn't help).
A backtrace to this would be helpfull.
Could you try to run:
gdb --args gv SOME_POSTSCRIPT_FILE
and then on the prompt
run
waiting for the fault and then
backtrace
and send the output of this?
(Even better would be with a version of gv compiled with debug versions,
and with the debug versions of all libraries installed, but even
without it might give already information what is at fault actually)
Does it happen for all files or only for specific ones?
Does it still happen with an emtpy home directory?
You can try with
mkdir /tmp/test
HOME=/tmp/test gv SOME_POSTSCRIPT_FILE
Is the environment variable XUSERFILESEARCHPATH set?
Thanks in advance,
Bernhard R. Link
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#439067: gv segmentation fault while starting up
Package: gv
Version: 1:3.6.3dfsg-2
When I run "gv" or "gv SOME_POSTSCRIPT_FILE", it dumps core immediately.
According to "strace gv", this happens right after
stat64("/home/mopsa/kimoto/.gv", 0xbf9cf394) = -1 ENOENT (No such file or
directory)
(although "touch ~/.gv" doesn't help).
I have
gs-gpl 8.56.dfsg.1-1. The GPL Ghostscript PostScript interpreter
libc6 2.6.1-1GNU C Library: Shared libraries
libice62:1.0.3-3 X11 Inter-Client Exchange library
libsm6 2:1.0.3-1+b1 X11 Session Management library
libx11-6 2:1.0.3-7 X11 client-side library
libxext6 1:1.0.3-2 X11 miscellaneous extension library
libxmu61:1.0.3-1 X11 miscellaneous utility library
libxpm41:3.5.6-3 X11 pixmap library
libxt6 1:1.0.5-3 X11 toolkit intrinsics library
xaw3dg 1.5+E-15 Xaw3d widget set
xserver-xorg-video-savage 1:2.1.3-1 X.Org X server -- Savage display driver
and the display itself is on a Thinkpad T23.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
