Re: 21.2-b19-sneaky: linux: make-frame-on-display seg fault
25 years
Jan Vroonhof
Jan Vroonhof
Mark Thomas <mthomas(a)jprc.com> writes:
> #0 0x2ac21502 in XGetIMValues ()
> #1 0x80cf621 in IMInstantiateCallback (dpy=0x86a2bd8,
> client_data=0x86aba70 "\034\200=d9*P=baj\b=ba'", call_data=0x0)
> at /home/xemacs/build/xemacs-cvs-snapshot-19991102/src/input-method-xlib.c:249
> #2 0x2ac46846 in _XimRegisterIMInstantiateCallback ()
> #3 0x2ac219aa in XRegisterIMInstantiateCallback ()
> #4 0x80cf915 in XIM_init_frame (f=0x86aba70)
I think this is a known problem. There might even already be a patch
in the patch queue. Please contact Kazuyuki IENAGA <kazz(a)imasy.or.jp>
Jan
- 2 participants
- 1 comments
Re: Wow, I must have been bored... GPM stuff
25 years
Jan Vroonhof
Jan Vroonhof
wmperry(a)aventail.com (William M. Perry) writes:
> ** .../linux/drivers/char/console.c in the function
> ** tioclinux(). The following bit of code is brutal to
> ** us:
> **
> ** if (current->tty != tty && !suser())
> ** return -EPERM;
> **
> ** I even tried setting us as a process leader, removing
> ** our controlling terminal, and then using the TIOCSCTTY
> ** to set up a new controlling terminal, all with no luck.
If I read the code correctly you cannot use TIOCSCTTY on a tty that
already has a sesssion on it (if you are not root).
> ** What is even weirder is if you run XEmacs in a VC, and
> ** attach to it from another VC with gnuclient, go back to
> ** the original VC and hit a key, the mouse pointer
> ** displays (in BOTH VCs), until you hit a key in the
> ** second VC, after which it does not display in EITHER
> ** VC. Bizarre, no?
How do you see both VT's at once? Maybe the kernel just forgets to
remove the mouse cursor until at least one character is drawn (that
would be another kernel bug)
> If anybody cares to wade through linux/drivers/char/ and show me a way to
> get this working, the appropriate files are tty_io.c and console.c.
#if 0 the check out. If you look in tty_io.c you'll see that almost
all other such checks have met the same fate.
> The reason they do the check (I think) is that so somebody can't just call
> an ioctl() to set the selection on a VC that they do not own, and then call
> the ioctl() to do a paste, in effect getting a screendump of that other
> VC. It is still annoying though.
Yes, but as you wrote before if you don't have the tty open you cannot
call the ioctl in the first place. You can read from and write to the
tty, why shouldn't you be able to mess with the mouse cursor?
Jan
- 1 participants
- 0 comments
Re: (insert 8000) crashes XEmacs 21.2.16
25 years
Hrvoje Niksic
Hrvoje Niksic
"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes:
> Hrvoje> That would be a bad idea, I think. There could be code
> Hrvoje> that assumes that stuff in [0, 256) range is Latin 1, or
> Hrvoje> that internal representation is independent of the
> Hrvoje> selected environment.
>
> Good. Let's smoke those bad assumptions out. Ebola Redux! :-)
Not now, John. :-)
Yes, we'll exorcise Ebola sooner or later. The bulk of the work has
been done, and we *think* we've faced the worst of the consequences.
Now we can afford time to think about the issues and we needn't rush
into anything.
Case in point: a lot of code tries to increment characters, and gets
integers in return. The code works because insert and friends work
reasonably well with integers. If/when we modify insert to barf on
integers, (1+ ?a) will need to signal an error instead of returning
98. (It could also return ?b, but that's too ugly to think about.)
> Of course I'm only about 10% serious. But I think this is on the
> agenda anyway. I see no good reason why Latin-1 should be
> privileged once we get the 1-byte buffer stuff working, and a very
> good reason why it shouldn't be (subtle bugs). In fact, putting the
> default interpretation of ?\xA1 under user control is _exactly_ the
> point of the 1-byte buffers.
It's impossible to bring the interpretation of ?\xA1 under user
control because such things are evaluated at read-time, not at
run-time. (That's an important property of Lisp.) I suppose you
could make (insert #xA1) do the "right" thing at run-time, but I think
it would only create more confusion. As a certain lady would say, bad
gut feeling.
> To my mind, the real question may very well be timing. Do we
> implement the 1-byte buffers first, and then try to flush out the
> Latin-1 assumptions hidden throughout (possibly, anyway) the code?
As I pointed out above, there is no need to hurry with the latter.
There are much more important things to worry about in Mule, both with
the internals and with the interface.
- 1 participants
- 0 comments
XEmacs Build Report for XEmacs-21.2.20
25 years
XEmacs Build 'Bot
XEmacs Build 'Bot
Good afternoon XEmacs beta testers. I am in the process of building
XEmacs-21.2.20 for distribution. I have tested the attached
configuration. Have a great day!
Sincerely,
The XEmacs Build 'Bot (revision 2)
--
uname -a: SunOS miho 5.6 Generic_105181-05 sun4u sparc
./configure '--prefix=/usr/local/devel/xemacs-builds' '--cflags=-O' '--with-mule' '--without-x11' '--debug=no' '--error-checking=none'
XEmacs 21.2-b20 "Yoko" configured for `sparc-sun-solaris2.6'.
Where should the build process find the source code? /usr/local/devel/xemacs-builds/xemacs-21.2
What installation prefix should install use? /usr/local/devel/xemacs-builds
What operating system and machine description files should XEmacs use?
`s/sol2.h' and `m/sparc.h'
What compiler should XEmacs be built with? gcc -O
Should XEmacs use the GNU version of malloc? yes
Should XEmacs use the relocating allocator for buffers? yes
What window system should XEmacs use? none
Runtime library search path: /usr/local/qt/lib:/usr/local/lib:/usr/local/X11R6/lib
Compiling in support for Berkeley DB.
Compiling in support for GNU DBM.
Compiling in support for ncurses.
Compiling in Mule (multi-lingual) support.
Compiling in support for Canna on Mule.
Compiling in DSO module support.
movemail will use "dot-locking" for locking mail spool files.
- 1 participants
- 0 comments
Splash screen in help menu
25 years
SL Baur
SL Baur
Robin S Socha <robin(a)socha.net> writes in xemacs-beta(a)xemacs.org:
> And why do I need a "Splash" entry in the Help menu?
It's the same place where Netscape puts it. An entry was made for it
because there was no other single screen which displayed all the
relevant copyright notices.
- 1 participants
- 0 comments
Re: (insert 8000) crashes XEmacs 21.2.16
25 years
Hrvoje Niksic
Hrvoje Niksic
"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes:
> I don't have a problem with allowing people to use `255' as an
> abbreviation for `?\377', as long as they don't care if we define
> the default interpretation for bytes in GR to be Latin-2.
That would be a bad idea, I think. There could be code that assumes
that stuff in [0, 256) range is Latin 1, or that internal
representation is independent of the selected environment.
(However, `C-q ddd' *should* default to Latin 2 characters in the
Latin 2 environment.)
> But I can't see a good reason why "characters" with "code points"
> bigger than 255 should be permitted to be represented by integers as
> long as `int-char' doesn't take a character set argument.
Because it can be useful at times. I wouldn't disregard that
possibility completely. Also note that `make-char' does take a
charset argument.
- 2 participants
- 1 comments
Fixing call-process and fstat in 21.2-b19 on Windows NT
25 years
Adrian Aichner
Adrian Aichner
Could the experts in these areas please comment on this patch of mine?
I will add a ChangeLog after I resolve any remaining issues.
Please see
http://www.xemacs.org/list-archives/xemacs-beta/9911/msg00193.html for
my assessment of the fstat/stat problems on Windows NT. I'd like to
hear from you if I've drawn any wrong conclusions.
Changes to
src/callproc.c
src/ntproc.c
src/sysdep.c
and
src/sysdep.h
implement the call-process patch which is in 21.1.8 already.
However, following Ben's request, I have replaced stderr_out () with
warn_when_safe ().
The part I am concerned about is my ENCAPSULATION for fstat, which is
required on Windows NT to avoid inconsistencies between the already
encapsulated stat system call and the broken fstat on NT. Do I need
to qualify it somehow, so that it only affects native Windows NT
builds? I didn't understand how stat is only encapsualted on NT
native.
The files changed are:
src/nt.c
src/sysdep.c
src/sysfile.h
Please advise about any shortcomings of this patch and directions for
possible fixes.
Many thanks!
Adrian
I have verified a patched XEmacs to report consistent file times
cd d:\tmp\21.2\xemacs\
cvs diff
Compilation started at Wed Nov 10 03:09:36 1999 +0100 (W. Europe Standard Time)
Index: src/callproc.c
===================================================================
RCS file: /usr/CVSroot/XEmacs/xemacs/src/callproc.c,v
retrieving revision 1.29.2.6
diff -u -r1.29.2.6 callproc.c
--- callproc.c 1999/05/01 05:13:23 1.29.2.6
+++ callproc.c 1999/11/10 02:13:47
＠＠ -104,6 +104,9 ＠＠
{
int fd = XINT (Fcar (fdpid));
int pid = XINT (Fcdr (fdpid));
+#ifdef WINDOWSNT
+ HANDLE pHandle;
+#endif
if (!call_process_exited &&
EMACS_KILLPG (pid, SIGINT) == 0)
＠＠ -114,7 +117,17 ＠＠
/* #### "c-G" -- need non-consing Single-key-description */
message ("Waiting for process to die...(type C-g again to kill it instantly)");
+#ifdef WINDOWSNT
+ pHandle = OpenProcess(PROCESS_ALL_ACCESS, 0, pid);
+ if (pHandle == NULL)
+ {
+ warn_when_safe (Qprocess, Qerror,
+ "OpenProcess returns NULL process handle.");
+ }
+ wait_for_termination (pHandle);
+#else
wait_for_termination (pid);
+#endif
/* "Discard" the unwind protect. */
XCAR (fdpid) = Qnil;
＠＠ -170,6 +183,9 ＠＠
Lisp_Object infile, buffer, current_dir, display, path;
int fd[2];
int filefd;
+#ifdef WINDOWSNT
+ HANDLE pHandle;
+#endif
int pid;
char buf[16384];
char *bufptr = buf;
＠＠ -359,6 +375,20 ＠＠
#ifdef WINDOWSNT
pid = child_setup (filefd, fd1, fd_error, new_argv,
(char *) XSTRING_DATA (current_dir));
+ if (!INTP (buffer))
+ {
+ /* OpenProcess() as soon after child_setup as possible. It's too
+ late once the process terminated. */
+ pHandle = OpenProcess(PROCESS_ALL_ACCESS, 0, pid);
+ if (pHandle == NULL)
+ {
+ warn_when_safe (Qprocess, Qerror,
+ "OpenProcess returns NULL process handle.");
+ }
+ }
+ /* Close STDERR into the parent process. We no longer need it. */
+ if (fd_error >= 0)
+ close (fd_error);
#else /* not WINDOWSNT */
pid = fork ();
＠＠ -394,12 +424,14 ＠＠
if (!NILP (fork_error))
signal_error (Qfile_error, fork_error);
+#ifndef WINDOWSNT
if (pid < 0)
{
if (fd[0] >= 0)
close (fd[0]);
report_file_error ("Doing fork", Qnil);
}
+#endif
if (INTP (buffer))
{
＠＠ -507,7 +539,11 ＠＠
QUIT;
/* Wait for it to terminate, unless it already has. */
+#ifdef WINDOWSNT
+ wait_for_termination (pHandle);
+#else
wait_for_termination (pid);
+#endif
/* Don't kill any children that the subprocess may have left behind
when exiting. */
Index: src/nt.c
===================================================================
RCS file: /usr/CVSroot/XEmacs/xemacs/src/nt.c,v
retrieving revision 1.17.2.4
diff -u -r1.17.2.4 nt.c
--- nt.c 1999/07/05 05:56:43 1.17.2.4
+++ nt.c 1999/11/10 02:14:24
＠＠ -1313,6 +1313,40 ＠＠
#endif
+/* Since stat is encapsulated on Windows NT, we need to encapsulate
+ the equally broken fstat as well. */
+int
+fstat (int handle, struct stat *buffer)
+{
+ int ret;
+ BY_HANDLE_FILE_INFORMATION lpFileInfo;
+ /* Initialize values */
+ buffer->st_mode = 0;
+ buffer->st_size = 0;
+ buffer->st_dev = 0;
+ buffer->st_rdev = 0;
+ buffer->st_atime = 0;
+ buffer->st_ctime = 0;
+ buffer->st_mtime = 0;
+ buffer->st_nlink = 0;
+ ret = GetFileInformationByHandle((HANDLE) handle, &lpFileInfo);
+ if (!ret)
+ {
+ return -1;
+ }
+ else
+ {
+ buffer->st_mtime = convert_time (lpFileInfo.ftLastWriteTime);
+ buffer->st_atime = convert_time (lpFileInfo.ftLastAccessTime);
+ if (buffer->st_atime == 0) buffer->st_atime = buffer->st_mtime;
+ buffer->st_ctime = convert_time (lpFileInfo.ftCreationTime);
+ if (buffer->st_ctime == 0) buffer->st_ctime = buffer->st_mtime;
+ buffer->st_size = lpFileInfo.nFileSizeLow;
+ buffer->st_nlink = (short) lpFileInfo.nNumberOfLinks;
+ return 0;
+ }
+}
+
/* MSVC stat function can't cope with UNC names and has other bugs, so
replace it with our own. This also allows us to calculate consistent
inode values without hacks in the main Emacs code. */
Index: src/ntproc.c
===================================================================
RCS file: /usr/CVSroot/XEmacs/xemacs/src/ntproc.c,v
retrieving revision 1.14.2.10
diff -u -r1.14.2.10 ntproc.c
--- ntproc.c 1999/10/10 12:40:13 1.14.2.10
+++ ntproc.c 1999/11/10 02:14:30
＠＠ -445,16 +445,8 ＠＠
cp->procinfo.hThread=NULL;
cp->procinfo.hProcess=NULL;
- /* Hack for Windows 95, which assigns large (ie negative) pids */
- if (cp->pid < 0)
- cp->pid = -cp->pid;
-
/* pid must fit in a Lisp_Int */
-#ifdef USE_UNION_TYPE
- cp->pid = (cp->pid & ((1U << VALBITS) - 1));
-#else
- cp->pid = (cp->pid & VALMASK);
-#endif
+
*pPid = cp->pid;
Index: src/sysdep.c
===================================================================
RCS file: /usr/CVSroot/XEmacs/xemacs/src/sysdep.c,v
retrieving revision 1.32.2.7
diff -u -r1.32.2.7 sysdep.c
--- sysdep.c 1999/07/05 05:56:44 1.32.2.7
+++ sysdep.c 1999/11/10 02:14:44
＠＠ -234,8 +234,11 ＠＠
#endif /* NO_SUBPROCESSES */
-void
-wait_for_termination (int pid)
+#ifdef WINDOWSNT
+void wait_for_termination (HANDLE pHandle)
+#else
+void wait_for_termination (int pid)
+#endif
{
/* #### With the new improved SIGCHLD handling stuff, there is much
less danger of race conditions and some of the comments below
＠＠ -345,6 +348,53 ＠＠
Since implementations may add their own error indicators on top,
we ignore it by default. */
+#elif defined (WINDOWSNT)
+ int ret = 0, status = 0;
+ if (pHandle == NULL)
+ {
+ warn_when_safe (Qprocess, Qerror, "Cannot wait for NULL process handle.");
+ return;
+ }
+ do
+ {
+ QUIT;
+ ret = WaitForSingleObject(pHandle, 100);
+ }
+ while (ret == WAIT_TIMEOUT);
+ if (ret == WAIT_FAILED)
+ {
+ warn_when_safe (Qprocess, Qerror,
+ "WaitForSingleObject returns WAIT_FAILED for process handle %p.",
+ pHandle);
+ }
+ if (ret == WAIT_ABANDONED)
+ {
+ warn_when_safe (Qprocess, Qerror,
+ "WaitForSingleObject returns WAIT_ABANDONED for process handle %p.",
+ pHandle);
+ }
+ if (ret == WAIT_OBJECT_0)
+ {
+ ret = GetExitCodeProcess(pHandle, &status);
+ if (ret)
+ {
+ synch_process_alive = 0;
+ synch_process_retcode = status;
+ }
+ else
+ {
+ /* GetExitCodeProcess() didn't return a valid exit status,
+ nothing to do. APA */
+ warn_when_safe (Qprocess, Qerror,
+ "GetExitCodeProcess fails for process handle %p.",
+ pHandle);
+ }
+ }
+ if (pHandle != NULL && !CloseHandle(pHandle))
+ {
+ warn_when_safe (Qprocess, Qerror,
+ "CloseHandle fails for process handle %p.", pHandle);
+ }
#elif defined (EMACS_BLOCK_SIGNAL) && !defined (BROKEN_WAIT_FOR_SIGNAL) && defined (SIGCHLD)
while (1)
{
＠＠ -376,7 +426,7 ＠＠
Try defining BROKEN_WAIT_FOR_SIGNAL. */
EMACS_WAIT_FOR_SIGNAL (SIGCHLD);
}
-#else /* not HAVE_WAITPID and (not EMACS_BLOCK_SIGNAL or BROKEN_WAIT_FOR_SIGNAL) */
+#else /* not HAVE_WAITPID and not WINDOWSNT and (not EMACS_BLOCK_SIGNAL or BROKEN_WAIT_FOR_SIGNAL) */
/* This approach is kind of cheesy but is guaranteed(?!) to work
for all systems. */
while (1)
＠＠ -578,7 +628,11 ＠＠
static void
sys_subshell (void)
{
+#ifdef WINDOWSNT
+ HANDLE pid;
+#else
int pid;
+#endif
struct save_signal saved_handlers[5];
Lisp_Object dir;
unsigned char *str = 0;
＠＠ -617,7 +671,7 ＠＠
xyzzy:
#ifdef WINDOWSNT
- pid = -1;
+ pid = NULL;
#else /* not WINDOWSNT */
pid = fork ();
＠＠ -651,7 +705,7 ＠＠
#ifdef WINDOWSNT
/* Waits for process completion */
pid = _spawnlp (_P_WAIT, sh, sh, NULL);
- if (pid == -1)
+ if (pid == NULL)
write (1, "Can't execute subshell", 22);
#else /* not WINDOWSNT */
＠＠ -3036,6 +3090,15 ＠＠
return readlink (path, buf, bufsiz);
}
#endif /* ENCAPSULATE_READLINK */
+
+
+#ifdef ENCAPSULATE_FSTAT
+int
+sys_fstat (int fd, struct stat *buf)
+{
+ return fstat (fd, buf);
+}
+#endif /* ENCAPSULATE_FSTAT */
#ifdef ENCAPSULATE_STAT
Index: src/sysdep.h
===================================================================
RCS file: /usr/CVSroot/XEmacs/xemacs/src/sysdep.h,v
retrieving revision 1.11.2.1
diff -u -r1.11.2.1 sysdep.h
--- sysdep.h 1998/12/05 16:56:31 1.11.2.1
+++ sysdep.h 1999/11/10 02:14:45
＠＠ -48,7 +48,12 ＠＠
/* Wait for subprocess with process id `pid' to terminate and
make sure it will get eliminated (not remain forever as a zombie) */
+#ifdef WINDOWSNT
+#include <windows.h>
+void wait_for_termination (HANDLE pid);
+#else
void wait_for_termination (int pid);
+#endif
/* flush any pending output
* (may flush input as well; it does not matter the way we use it)
Index: src/sysfile.h
===================================================================
RCS file: /usr/CVSroot/XEmacs/xemacs/src/sysfile.h,v
retrieving revision 1.7.2.1
diff -u -r1.7.2.1 sysfile.h
--- sysfile.h 1998/12/05 16:56:32 1.7.2.1
+++ sysfile.h 1999/11/10 02:14:46
＠＠ -380,6 +380,18 ＠＠
# define sys_readlink readlink
#endif
+#ifdef ENCAPSULATE_FSTAT
+int sys_fstat (int fd, struct stat *buf);
+#endif
+#if defined (ENCAPSULATE_FSTAT) && !defined (DONT_ENCAPSULATE)
+# undef fstat
+/* Need to use arguments to avoid messing with struct stat */
+# define fstat(fd, buf) sys_fstat (fd, buf)
+#endif
+#if !defined (ENCAPSULATE_FSTAT) && defined (DONT_ENCAPSULATE)
+# define sys_fstat fstat
+#endif
+
#ifdef ENCAPSULATE_STAT
int sys_stat (CONST char *path, struct stat *buf);
#endif
cvs server: Diffing src/m
cvs server: Diffing src/s
cvs server: Diffing tests
cvs server: Diffing tests/DLL
cvs server: Diffing tests/Dnd
cvs server: Diffing tests/automated
cvs server: Diffing tests/mule
cvs server: Diffing tests/tooltalk
Compilation exited abnormally with code 1 at Wed Nov 10 03:14:21
- 1 participants
- 0 comments
Re: [PATCH] *.el is newer, etc. [was: [Success] XEmacs 21.1.8 "Bryce Canyon", i386-pc-win32]
25 years
Adrian Aichner
Adrian Aichner
>>>>> "APA" == Adrian Aichner <aichner(a)ecf.teradyne.com> writes:
APA> 1) It fixes incorrect messages stating
APA> file *.el is newer
APA> for packages installed during DST when DST ends.
This patch is incorrect. Please don't apply it.
A real solution is immanent.
Regards,
Adrian
- 1 participants
- 0 comments
Wow, I must have been bored... GPM stuff
25 years
William M. Perry
William M. Perry
Comment I just added to gpmevent.c after trying to get the mouse cursor
drawing correctly. This only happens if you attach to a running XEmacs.
/* Ok, now this is just freaky. Bear with me though.
**
** If you run gnuclient and attach to a XEmacs running in
** X or on another TTY, the mouse cursor does not get
** drawn correctly. This is because the ioctl() fails
** with EPERM because the TTY specified is not our
** controlling terminal. If you are the superuser, it
** will work just spiffy. The appropriate source file (at
** least in linux 2.2.x) is
** .../linux/drivers/char/console.c in the function
** tioclinux(). The following bit of code is brutal to
** us:
**
** if (current->tty != tty && !suser())
** return -EPERM;
**
** I even tried setting us as a process leader, removing
** our controlling terminal, and then using the TIOCSCTTY
** to set up a new controlling terminal, all with no luck.
**
** What is even weirder is if you run XEmacs in a VC, and
** attach to it from another VC with gnuclient, go back to
** the original VC and hit a key, the mouse pointer
** displays (in BOTH VCs), until you hit a key in the
** second VC, after which it does not display in EITHER
** VC. Bizarre, no?
**
** All I can say is thank god Linux comes with source code
** or I would have been completely confused. Well, ok,
** I'm still completely confused. I don't see why they
** don't just check the permissions on the device
** (actually, if you have enough access to it to get the
** console's file descriptor, you should be able to do
** with it as you wish, but maybe that is just me).
**
** William M. Perry - Nov 9, 1999
*/
If anybody cares to wade through linux/drivers/char/ and show me a way to
get this working, the appropriate files are tty_io.c and console.c.
The reason they do the check (I think) is that so somebody can't just call
an ioctl() to set the selection on a VC that they do not own, and then call
the ioctl() to do a paste, in effect getting a screendump of that other
VC. It is still annoying though.
*sigh*
Any Linux kernel jockeys out there that can get this working? Without a
kernel patch? :)
-Bill P.
- 1 participants
- 0 comments
21.2-b19-sneaky: linux: make-frame-on-display seg fault
25 years
Mark Thomas
Mark Thomas
In XEmacs 21.2 (beta19) "Sneaky Bastard 19991102" [Lucid] (i686-pc-linux, Mule) of Tue Nov 9 1999 on ulysses.jprc.com
configured using `configure --prefix=/home/xemacs/debug --with-mule --site-libraries=/home/xemacs/lib --site-includes=/home/xemacs/include --site-runtime-libraries=/home/xemacs/lib '--cflags=-g -Wall -Wno-switch' --with-dialogs=athena --with-widgets=athena'
Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:
xemacs -vanilla
in the *scratch* buffer evaluate:
(make-frame-on-display (concat (system-name) ":0"))
I discovered the crash when trying to use gnuclient between machines,
but I can make XEmacs crash by giving make-frame-on-display a
hostname. If I use ":0.0", "localhost:0.0", or "unix:0.0",
make-frame-on-display works fine, but if I give it the name of my
host, XEmacs crashes.
This is a RedHat Linux 5.2 box running a 2.2.12 kernel; XFree86 info
from rpm:
Name : XFree86 Distribution: Manhattan
Version : 3.3.2.3 Vendor: Red Hat Software
Release : 25 Build Date: Sat Oct 10 04:01:26 1998
Install date: Mon Feb 8 15:46:28 1999 Build Host: porky.redhat.com
Group : X11/XFree86 Source RPM: XFree86-3.3.2.3-25.src.rpm
The describe-installation, lisp backtrace, and the contents of my
*gdb* buffer follow.
uname -a: Linux ulysses.jprc.com 2.2.12 #1 SMP Wed Sep 8 17:41:43 EDT 1999 i686 unknown
../xemacs-cvs-snapshot-19991102/configure '--prefix=/home/xemacs/debug' '--with-mule' '--site-libraries=/home/xemacs/lib' '--site-includes=/home/xemacs/include' '--site-runtime-libraries=/home/xemacs/lib' '--cflags=-g -Wall -Wno-switch' '--with-dialogs=athena' '--with-widgets=athena'
XEmacs 21.2-b19 "Sneaky Bastard 19991102" configured for `i686-pc-linux'.
Where should the build process find the source code? /home/xemacs/build/xemacs-cvs-snapshot-19991102
What installation prefix should install use? /home/xemacs/debug
What operating system and machine description files should XEmacs use?
`s/linux.h' and `m/intel386.h'
What compiler should XEmacs be built with? gcc -g -Wall -Wno-switch
Should XEmacs use the GNU version of malloc? yes
(Using Doug Lea's new malloc from the GNU C Library.)
Should XEmacs use the relocating allocator for buffers? yes
What window system should XEmacs use? x11
Where do we find X Windows header files? /usr/X11R6/include
Where do we find X Windows libraries? /usr/X11R6/lib
Additional header files: /home/xemacs/include
Additional libraries: /home/xemacs/lib
Runtime library search path: /home/xemacs/lib
Compiling in support for XAUTH.
Compiling in support for XPM images.
Compiling in support for PNG image handling.
Compiling in support for (builtin) GIF image handling.
Compiling in support for JPEG image handling.
Compiling in support for TIFF image handling.
Compiling in support for X-Face message headers.
Compiling in native sound support.
Compiling in support for Berkeley DB.
Compiling in support for GNU DBM.
Compiling in support for ncurses.
Compiling in support for GPM (General Purpose Mouse).
Compiling in Mule (multi-lingual) support.
Compiling in XIM (X11R5+ I18N input method) support.
Using raw Xlib to provide XIM support.
Compiling in support for proper WM_COMMAND handling.
Using Lucid menubars.
Using Lucid scrollbars.
Using Athena native widgets.
Using Athena dialog boxes.
Compiling in DSO module support.
movemail will use "dot-locking" for locking mail spool files.
Compiling in extra code for debugging.
WARNING: ---------------------------------------------------------
WARNING: Compiling in support for runtime error checking.
WARNING: XEmacs will run noticeably more slowly as a result.
WARNING: Error checking is on by default for XEmacs beta releases.
WARNING: ---------------------------------------------------------
Lisp backtrace follows:
# bind (frame-being-created)
make-frame(nil #<x-device on "ulysses.jprc.com:0.0" 0x27ad>)
# bind (props connection type)
make-frame-on-device(x "ulysses.jprc.com:0" nil)
# bind (props display)
make-frame-on-display("ulysses.jprc.com:0")
eval((make-frame-on-display (concat (system-name) ":0")))
# bind (expr)
eval-interactive((make-frame-on-display (concat (system-name) ":0")))
# bind (standard-output opoint ignore-quotes eval-last-sexp-arg-internal)
eval-last-sexp(t)
# bind (standard-output)
#<compiled-function nil "...(13)" [standard-output terpri eval-last-sexp t] 2 920714 nil>()
call-interactively(eval-print-last-sexp)
# (condition-case ... . error)
# (catch top-level ...)
[1] + 19143 segmentation fault xemacs-21.2-b19 -vanilla
*gdb* buffer contents (changed non-ASCII characters to hexadecimal):
Current directory is /home/xemacs/debug/bin/
GNU gdb 4.17.0.4 with Linux/x86 hardware watchpoint and FPU support
(gdb) attach 19143
Attaching to program `/home/xemacs/debug/bin/xemacs-21.2-b19', Pid 19143
Reading symbols from /usr/arla/lib/libgetcwd.so.0.27...done.
Reading symbols from /usr/X11R6/lib/libXaw.so.6...done.
Reading symbols from /usr/lib/libtiff.so.3...done.
Reading symbols from /home/xemacs/lib/libpng.so.2...done.
Reading symbols from /usr/lib/libjpeg.so.62...done.
Reading symbols from /usr/lib/libz.so.1...done.
Reading symbols from /usr/X11R6/lib/libXpm.so.4...done.
Reading symbols from /usr/X11R6/lib/libXmu.so.6...done.
Reading symbols from /usr/X11R6/lib/libXt.so.6...done.
Reading symbols from /usr/X11R6/lib/libXext.so.6...done.
Reading symbols from /usr/X11R6/lib/libX11.so.6...done.
Reading symbols from /usr/X11R6/lib/libSM.so.6...done.
Reading symbols from /usr/X11R6/lib/libICE.so.6...done.
Reading symbols from /lib/libdl.so.2...done.
Reading symbols from /lib/libdb.so.2...done.
Reading symbols from /usr/lib/libgdbm.so.2...done.
Reading symbols from /usr/lib/libgpm.so.1...done.
Reading symbols from /usr/lib/libncurses.so.4...done.
Reading symbols from /lib/libm.so.6...done.
Reading symbols from /lib/libc.so.6...done.
Reading symbols from /lib/ld-linux.so.2...done.
Reading symbols from /lib/libnss_files.so.1...done.
0x2ad732de in __select ()
(gdb) cont
Continuing.
Program received signal SIGSEGV, Segmentation fault.
0x2ac21502 in XGetIMValues ()
(gdb) where
#0 0x2ac21502 in XGetIMValues ()
#1 0x80cf621 in IMInstantiateCallback (dpy=0x86a2bd8,
client_data=0x86aba70 "\034\200=d9*P=baj\b=ba'", call_data=0x0)
at /home/xemacs/build/xemacs-cvs-snapshot-19991102/src/input-method-xlib.c:249
#2 0x2ac46846 in _XimRegisterIMInstantiateCallback ()
#3 0x2ac219aa in XRegisterIMInstantiateCallback ()
#4 0x80cf915 in XIM_init_frame (f=0x86aba70)
at /home/xemacs/build/xemacs-cvs-snapshot-19991102/src/input-method-xlib.c:333
#5 0x81cf9ab in x_popup_frame (f=0x86aba70)
at /home/xemacs/build/xemacs-cvs-snapshot-19991102/src/frame-x.c:2085
#6 0x81cfc3a in x_init_frame_3 (f=0x86aba70)
at /home/xemacs/build/xemacs-cvs-snapshot-19991102/src/frame-x.c:2204
#7 0x8118a3d in Fmake_frame (props=137151492, device=141086784)
at /home/xemacs/build/xemacs-cvs-snapshot-19991102/src/frame.c:472
#8 0x8098577 in Ffuncall (nargs=3, args=0x7fffe954)
at /home/xemacs/build/xemacs-cvs-snapshot-19991102/src/eval.c:3178
#9 0x8063608 in execute_optimized_program (
program=0x86a0140 "=c0\t=c2\013\f\t#\"\207", stack_depth=6,
constants_data=0x83e2358)
at /home/xemacs/build/xemacs-cvs-snapshot-19991102/src/bytecode.c:743
#10 0x80630b1 in funcall_compiled_function (fun=138258500, nargs=3,
args=0x7fffeaf8)
at /home/xemacs/build/xemacs-cvs-snapshot-19991102/src/bytecode.c:516
#11 0x8098811 in Ffuncall (nargs=4, args=0x7fffeaf4)
at /home/xemacs/build/xemacs-cvs-snapshot-19991102/src/eval.c:3210
#12 0x8063608 in execute_optimized_program (
program=0x86a0118 "\b=c1k=ab\003=c2\020=c3=c4\b\r#\207\204=d9*", stack_depth=4,
constants_data=0x853cf00)
at /home/xemacs/build/xemacs-cvs-snapshot-19991102/src/bytecode.c:743
#13 0x80630b1 in funcall_compiled_function (fun=139671456, nargs=1,
args=0x7fffec00)
at /home/xemacs/build/xemacs-cvs-snapshot-19991102/src/bytecode.c:516
#14 0x8097fda in Feval (form=139568696)
at /home/xemacs/build/xemacs-cvs-snapshot-19991102/src/eval.c:3034
#15 0x809854e in Ffuncall (nargs=2, args=0x7fffee24)
at /home/xemacs/build/xemacs-cvs-snapshot-19991102/src/eval.c:3178
#16 0x8063608 in execute_optimized_program (
program=0x8687448 "\b=a2=c1a=ab!\bG=c2V=ab\e=c3=c4\bAB!\210\r=ab\r=c6=c7!\210=c8=c9!\210=c6=ca!\210\bA＠\207\b=a2=cba=ab0\bG=c2V=ab*=cc\bA＠!=ab#=cd\bA＠=c3=c2\b8!\"\210=c3\b!\210\r=ab\r=c6=ce!\210=c8=c9!\210=c6=ca!\210\bA＠\207=c3\b!\207", stack_depth=5, constants_data=0x83fc518)
at /home/xemacs/build/xemacs-cvs-snapshot-19991102/src/bytecode.c:743
#17 0x80630b1 in funcall_compiled_function (fun=138392680, nargs=1,
args=0x7fffefcc)
at /home/xemacs/build/xemacs-cvs-snapshot-19991102/src/bytecode.c:516
#18 0x8098811 in Ffuncall (nargs=2, args=0x7fffefc8)
at /home/xemacs/build/xemacs-cvs-snapshot-19991102/src/eval.c:3210
#19 0x8063608 in execute_optimized_program (
program=0x86872e0 "\b=ab\004p=aa\002=c1`=c2\e\034\035=c6=c7=c8 \036\t=ca\216=cb\016\f!\210\212=c2f=cda=ae\005=ce =cda\023=cf=d0!\210\013=ab\n=c2f=d1a=ab\004=c2u\210\214e\f}\210=d2p!\211\036\023=a2=d4a=ab\r=d5=d6=d7\016\023=d8BBBD=aa\003\016\023-!!+\207a", stack_depth=8,
constants_data=0x83fc568)
at /home/xemacs/build/xemacs-cvs-snapshot-19991102/src/bytecode.c:743
#20 0x80630b1 in funcall_compiled_function (fun=138392708, nargs=1,
args=0x7ffff178)
at /home/xemacs/build/xemacs-cvs-snapshot-19991102/src/bytecode.c:516
#21 0x8098811 in Ffuncall (nargs=2, args=0x7ffff174)
at /home/xemacs/build/xemacs-cvs-snapshot-19991102/src/eval.c:3210
#22 0x8063608 in execute_optimized_program (
program=0x867dd58 "p\030=c1 \210=c2=c3!\210=c1 )\207", stack_depth=2,
constants_data=0x84aa9e0)
at /home/xemacs/build/xemacs-cvs-snapshot-19991102/src/bytecode.c:743
#23 0x80630b1 in funcall_compiled_function (fun=138392652, nargs=0,
args=0x7ffff344)
at /home/xemacs/build/xemacs-cvs-snapshot-19991102/src/bytecode.c:516
#24 0x8098811 in Ffuncall (nargs=1, args=0x7ffff340)
at /home/xemacs/build/xemacs-cvs-snapshot-19991102/src/eval.c:3210
#25 0x8099ab7 in apply1 (fn=138392652, arg=137151492)
at /home/xemacs/build/xemacs-cvs-snapshot-19991102/src/eval.c:3793
#26 0x8069113 in Fcall_interactively (function=138395404,
record_flag=137151492, keys=137151492)
at /home/xemacs/build/xemacs-cvs-snapshot-19991102/src/callint.c:394
#27 0x8096b64 in Fcommand_execute (cmd=138395404, record=137151492,
keys=137151492)
at /home/xemacs/build/xemacs-cvs-snapshot-19991102/src/eval.c:2613
#28 0x80eb712 in execute_command_event (command_builder=0x85df450,
event=141149120)
at /home/xemacs/build/xemacs-cvs-snapshot-19991102/src/event-stream.c:4343
#29 0x80ebe4f in Fdispatch_event (event=141149120)
at /home/xemacs/build/xemacs-cvs-snapshot-19991102/src/event-stream.c:4634
#30 0x8072aed in Fcommand_loop_1 ()
at /home/xemacs/build/xemacs-cvs-snapshot-19991102/src/cmdloop.c:575
#31 0x807286f in command_loop_1 (dummy=137151492)
at /home/xemacs/build/xemacs-cvs-snapshot-19991102/src/cmdloop.c:490
#32 0x8094972 in condition_case_1 (handlers=137151588,
bfun=0x8072848 <command_loop_1>, barg=137151492,
hfun=0x8072064 <cmd_error>, harg=137151492)
at /home/xemacs/build/xemacs-cvs-snapshot-19991102/src/eval.c:1630
#33 0x807218b in command_loop_3 ()
at /home/xemacs/build/xemacs-cvs-snapshot-19991102/src/cmdloop.c:252
#34 0x80721b3 in command_loop_2 (dummy=137151492)
at /home/xemacs/build/xemacs-cvs-snapshot-19991102/src/cmdloop.c:263
#35 0x8094502 in internal_catch (tag=137225708,
func=0x80721a8 <command_loop_2>, arg=137151492, threw=0x0)
at /home/xemacs/build/xemacs-cvs-snapshot-19991102/src/eval.c:1305
#36 0x80723f8 in initial_command_loop (load_me=137151492)
at /home/xemacs/build/xemacs-cvs-snapshot-19991102/src/cmdloop.c:301
#37 0x808fa9c in xemacs_21_2_b19_i686_pc_linux (argc=2, argv=0x7ffff9b4,
envp=0x7ffff9c0, restart=0)
at /home/xemacs/build/xemacs-cvs-snapshot-19991102/src/emacs.c:1873
#38 0x80906a4 in main (argc=2, argv=0x7ffff9b4, envp=0x7ffff9c0)
at /home/xemacs/build/xemacs-cvs-snapshot-19991102/src/emacs.c:2298
(gdb) quit
The program is running. Quit anyway (and detach it)? (y or n) y
Detaching from program: /home/xemacs/debug/bin/xemacs-21.2-b19 Pid 19143
- 1 participants
- 0 comments