October 1999 - XEmacs-Beta - XEmacs Mailing List Archives

Re: Patches Applied for 21.1.8 24 years, 6 months

Adrian Aichner

>>>>> "Craig" == Craig Lanning <CraigL(a)DyCon.com> writes: Craig> I have now updated from CVS, applied this patch, and Craig> recompiled. Craig> Individual tests work! Craig> Package updates via PUI work!!! (better that they used to) Craig> Stress test: Craig> (dotimes (i 200 "grep test passed") Craig> (unless Craig> (zerop (call-process "grep" nil '(t nil) nil Craig> "drivers" "c:\winnt\system.ini")) Craig> (error "Incorrect call-process return value!"))) Craig> runs to completion without showing the Blue Screen of Death!!!!! Craig> It first glance, I would say that we have a winner. That's great news! Craig> Craig Craig> P.S. When I quit XEmacs (c-X c-C) the following was printed Craig> to STDERR: Craig> Fatal error: assertion failed, file console.h, line 419, Craig> RECORD_TYPEP (obj, &lrecord_console) I assume this is related to another os_subtype check in ntproc.c: static BOOL CALLBACK find_child_console (HWND hwnd, child_process * cp) { DWORD thread_id; DWORD process_id; thread_id = GetWindowThreadProcessId (hwnd, &process_id); if (process_id == cp->procinfo.dwProcessId) { char window_class[32]; GetClassName (hwnd, window_class, sizeof (window_class)); if (strcmp (window_class, (os_subtype == OS_WIN95) ? "tty" : "ConsoleWindowClass") == 0) { cp->hwnd = hwnd; return FALSE; } } /* keep looking */ return TRUE; } I don't have a solution yet. What do you think we should do to determine os_subtype under mingw32? The sample program you sent looks equivalent to what src/ntheap.c has. Perhaps Andy can comment what to do? Anyway, I feel a lot better now than I did a few days ago. Best regards, Adrian Craig> and the shell hung waiting for XEmacs to exit. Craig> Otherwise nothing was printed to STDERR!

3 participants
2 comments

Re: "Unknown Host" Update, more evidence 24 years, 6 months

Jan Vroonhof

Gerald Gutierrez <gutier(a)intergate.bc.ca> writes: > I've looked at the .el files and know that open-network-stream uses > open-network-stream-internal, which Emacs says is a "built-in > function". I gather that means it's not written in Lisp but is a part > of Emacs itself. It seems more evident than ever that this is a Emacs > problem (bug even!). Yes. But the code path in Emacs here is extremely simple. One of the first things it does is call gethostbyname() like all normal Unix software does. If you get more time to investigate try running Emacs under strace/truss. Jan

1 participants
0 comments

Re: Unmark pdumped objects 24 years, 6 months

Jan Vroonhof

Olivier Galibert <galibert(a)pobox.com> writes: > In the current state of XEmacs 21.2, i.e. with purecopy emasculated, > there are almost no readonly objects. Then we have to make more of them. Is there any sensible heuristic that could be used here. For instance clear all mark bits. mark with as roots all byte compiled lisp. all strings without properties When we get to objects which we do not want to make read only (i.e. symbols), then either 1. Stick them on some lists as new roots. 2. Mark them with Kyle's "referenced form RO object list". Then dump with the mark bits as they are in addition making each marked object readonly. This from an unfounded guess that most cons pairs at dump time are referenced from byte-compiled lisp.. Jan

1 participants
0 comments

Re: Unmark pdumped objects 24 years, 6 months

Hrvoje Niksic

Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: > Hrvoje Niksic <hniksic(a)srce.hr> writes: > > > optimize_compiled_function() is supposed to be lazy. Doing all that > > works (and allocating all that data) for a bunch of functions that > > might not get called could be perceived as wasteful. > > The CPU work is irrelevant. Wasteful in memory/disk space, not CPU. > This is dumping time. Anyway, if the function doesn't get used > often, why are dumping it? Because other functions from the same file might be used often. Or because the function can get called from C code.

1 participants
0 comments

XEmacs 21.2.19+ MULE fatal bug 24 years, 6 months

Yoshiki Hayashi

This bug report will be sent to the XEmacs Development Team, not to your local site managers!! Please write in English, because the XEmacs maintainers do not have translators to read other languages for them. In XEmacs 21.2 (beta19) "Shinjuku" [Lucid] (i686-pc-linux, Mule) of Thu Oct 7 1999 on buck configured using `configure --prefix=/opt/local --with-mule' Please describe exactly what actions triggered the bug and the precise symptoms of the bug: This bug happens with only CVS version of XEmacs 21.2.19. XEmacs 21.1.7 and plain XEmacs 21.2.19 is fine. Save the following file as test and type C-x C-f test RET then, XEmacs dumps core. Below is an excerpt from ding mailing list. First part is iso-8859-1 and second part is iso-2022-jp. This cannot be the valid coding-system on the whole, but this is common in MIME messages. XEmacs crashed when I was trying to read an e-mail. -- Yoshiki Hayashi

1 participants
1 comments

Re: Unmark pdumped objects 24 years, 6 months

Hrvoje Niksic

Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: > Olivier Galibert <galibert(a)pobox.com> writes: > > > > 'f' is called. optimize_compiled_function munches the string and > > replaces it with a (newly allocated) opaque. > > Then this is wrong. We must strive for readonlyness. Is there any > reason we cannot call optimize_compiled_function on all functions > just before dumping? optimize_compiled_function() is supposed to be lazy. Doing all that works (and allocating all that data) for a bunch of functions that might not get called could be perceived as wasteful. Martin could probably offer a more coherent comment on that.

3 participants
4 comments

Re: Unmark pdumped objects 24 years, 6 months

Jan Vroonhof

Olivier Galibert <galibert(a)pobox.com> writes: > 'f' is called. optimize_compiled_function munches the string and > replaces it with a (newly allocated) opaque. Then this is wrong. We must strive for readonlyness. Is there any reason we cannot call optimize_compiled_function on all functions just before dumping? > There are a bunch of definitively not readonly objects in the dumped > data. Vobarray comes to mind. This is the core of the problem. In my comments I was of course assuming read-only objects. Therefore there must be a way to only sweep non-readonly objects and we must minimize that set (preferably they would even be on their own pages in the file). Jan

2 participants
1 comments

Re: Patches Applied for 21.1.8 [includes essential pathc] 24 years, 6 months

Gunnar Evermann

Martin Buchholz <martin(a)xemacs.org> writes: > I wrote the code that called pstack, originally. Observe that I was > careful enough to check for the existence of the executable. Perhaps > the problem is that XEmacs is in a possibly broken state, having just > crashed, and so even things like calling access() is dangerous. In that case wouldn't it be possible to do that check (and maybe even the sprintf) unconditionally early on in main() and set some variable like pstack_available_p. That would only leave the system() in the signal handler. Of course this variable could potentially be overwritten by the crash but that's probably rather unlikely to happen. What happens if pstack finds an utterly corrupted stack. Can it crash or (worse) hang? > It would have been nice if Steve indicated WHY this code is #if'ed > out. yes, indeed. > # if 0 /* This is evil, rarely useful, and causes grief in some cases. */ FWIW the ChangeLog entry says: Wed Mar 12 14:29:40 1997 Steven L Baur <steve(a)altair.xemacs.org> * emacs.c (fatal_error_signal): (mostly) useless check on /usr/proc/bin/pstack removed. Not much better, is it? :-) The only problem with these pstack traces is that they might discourage people from obtaining a real backtrace with their debugger from the core, but that's a risk I'm willing to take. I see comments like 'I couldn't find the core file' far too often and many people don't even bother reading our crash message but just send it verbatim to us. The more useful info we put in there the better. Gunnar -- Gunnar Evermann Speech, Vision & Robotics Group Engineering Department Cambridge University

1 participants
0 comments

Re: Patches Applied for 21.1.8 [includes essential pathc] 24 years, 6 months

Gunnar Evermann

Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: > Gunnar Evermann <ge204(a)eng.cam.ac.uk> writes: > > > Incidentally is there any reason why we do not try to print some kind > > of C stacktrace from our signal handler? > > Usual reason: Nobody wrote the patch. Boring but true. OK, I can try doing it. > > The Sun Workshop version did that and sometimes it was really > > helpful. > > That means the code is already somewhere for solaris...? yes, in fatal_error_signal() Basically it calls system("pstack <pid>"). It is currently #if 0'd -- Apparently Steve didn't like it. Steve: could you explain why? > > somewhat platform specific but I think at least for Solaris and > > linux/glibc it should be easy (didn't Ulrich post something about that > > some time ago?). > > Yes. And W.Perry tried it on their in-house software. Maybe they can > be asked for help. (Note that this is for glibc 2.1 and up). Actually I have just tried it and it's trivial to get the addresses. The big problem is converting them into symbols. The only way seems to involve 'addr2line' which is part of the gnu binutils... > At least we don't suffer from the "GDB development process too slow > for Linux" aka "Linux changing its signal handler trampoline too > often" aka "short backtrace" problem. well, I hope we won't just convert it into a "GNU binutils development is too slow" problem. :-) Gunnar

3 participants
2 comments

Re: Unmark pdumped objects 24 years, 6 months

Jan Vroonhof

Hrvoje Niksic <hniksic(a)srce.hr> writes: > optimize_compiled_function() is supposed to be lazy. Doing all that > works (and allocating all that data) for a bunch of functions that > might not get called could be perceived as wasteful. The CPU work is irrelevant. This is dumping time. Anyway, if the function doesn't get used often, why are dumping it? Jan

1 participants
0 comments

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

XEmacs-Beta October 1999