Better behaviour for interactive apps on leaf overflow?
10 years
Aidan Kehoe
Aidan Kehoe
Hello!
We’ve been using libgmp for our bignum support in XEmacs for a decade or so
now, thanks to Jerry James, one of our more active developers. XEmacs Lisp is
in spirit a Lisp-2 close in philosophy and history to Common Lisp, and it’s
correct and pleasant to have good bignum support.
One of our design (and implementation!) goals for XEmacs Lisp is that it
should be impossible for Lisp to crash XEmacs, something very important in
preserving our users’ data. We supply our own allocation functions to gmp and
handle our failures ourselves to minimise the risk of that happening. But, it
is still perfectly possible for Lisp to do something like this, where lsh is
the bitwise left shift operation, and most-positive-fixnum is 2 to the 30th
minus one:
(lsh (lsh most-positive-fixnum #xFFFFFF80) #xFFFFFF80)
On a 32-bit machine this will eventually fail with the following message:
(gdb) r -batch -eval "(lsh (lsh most-positive-fixnum #xFFFFFF80) #xFFFFFF80)"
Starting program: /Sources/xemacs-21.5-integer-length/src/xemacs -batch -eval "(lsh (lsh most-positive-fixnum #xFFFFFF80) #xFFFFFF80)"
gmp: overflow in mpz type
Program received signal SIGABRT, Aborted.
0x95187c5a in __kill () from /usr/lib/libSystem.B.dylib
(gdb)
Now, this abort isn’t wrapped, gmp calls it unconditionally in
realloc.c:_mpz_realloc(). This is frustrating for XEmacs; from our
perspective, we’d like to throw an error in this situation in the same way we
do when we divide by zero, rather than crash the entire process and have the
user lose so much of his or her state. Our garbage collector will take care of
the lost memory.
Best,
Aidan Kehoe
--
‘Tramadol is further fed to cattle […] when working them […] (as draft
animals) so that the animals do not get tired quickly. …’
— Angewandte Chemie, Sept 2014, describing the social context of
(synthetic) tramadol having been found in Cameroon tree roots.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
- 1 participants
- 2 comments
XEmacs 21.4.24 "Standard C" Released
10 years
Vin Shelton
Vin Shelton
I have tagged and uploaded XEmacs 21.4.24, "Standard C", to the XEmacs
ftp site. The tarball can be found here:
http://ftp.xemacs.org/xemacs-21.4/xemacs-21.4.24.tar.gz .
It is my fervent hope that this will be the last 21.4 release of XEmacs.
Regards,
Vin Shelton
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
- 3 participants
- 2 comments
XEmacs on OS X Yosemite = Segfault
10 years
Johann 'Myrkraverk' Oskarsson
Johann 'Myrkraverk' Oskarsson
Hi all,
I've been trying to compile XEmacs on Yosemite (OS X 10.10.2) with the
LLVM compiler from XCode.
So far, all versions I've tried (21.4 and 21.5) are failing with a
segmentation fault.
21.4.24 fails like this.
Dumping under the name xemacs
Testing for Lisp shadows ...
make[1]: *** [xemacs.dmp] Segmentation fault: 11
make[1]: *** Deleting file `xemacs.dmp'
make: *** [src] Error 2
21.5.34 fails like this.
Dumping under the name xemacs
if test -f dump-size; then \
../lib-src/insert-data-in-exec temacs xemacs.dmp
xemacs ` ./temacs -si`; \
ret=$? ; \
if test ${ret} -eq 2; then \
rm -f dump-size ; \
else \
if test ${ret} -eq 1; then \
exit 1; \
else \
chmod +x xemacs ; \
fi ; \
fi ; \
fi
dumped_data found at offset 0x3d5d10, patching.
dumped_data found at offset 0x3d5d10, patching.
if test ! -f dump-size; then \
../lib-src/insert-data-in-exec -s xemacs.dmp > dump-size ; \
rm -f dump-data.o xemacs xemacs.dmp temacs;\
/Applications/Xcode.app/Contents/Developer/usr/bin/make xemacs; \
fi
./xemacs -no-packages -batch -no-autoloads -l update-elc-2.el -f
batch-update-elc-2 /Users/johann/build/xemacs-21.5.34/src/../lisp
make[1]: *** [update-elc-2] Segmentation fault: 11
make: *** [src] Error 2
Do you guys have any suggestions on how to figure out what's wrong, or
configuration flags to try?
My ./configure lines are as follows.
21.4: ./configure --compiler=cc --cflags=-std=gnu89 --with-athena=xaw
--with-mule --with-png=no
21.5: ./configure --with-mule --without-png
Johann
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
- 2 participants
- 1 comments
Summary of XEmacs Issue Tracking System Issues
10 years
XEmacs Issue Tracking System
XEmacs Issue Tracking System
ACTIVITY SUMMARY (2015-03-31 - 2015-04-07)
XEmacs Issue Tracking System at http://tracker.xemacs.org/XEmacs/its/
To view or respond to any of the issues listed below, click on the issue
number. Do NOT respond to this message.
568 open ( +0) / 317 closed ( +0) / 885 total ( +0)
Open issues with patches: 13
Average duration of open issues: 2038 days.
Median duration of open issues: 2219 days.
Open Issues Breakdown
new 260 ( +0)
deferred 6 ( +0)
napping 3 ( +0)
verified 58 ( +0)
assigned 145 ( +0)
committed 19 ( +0)
documented 3 ( +0)
done/needs work 15 ( +0)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
- 1 participants
- 0 comments
Re: Generated Headers - Quite the Can of Worms
10 years
Vin Shelton
Vin Shelton
Hi, Henry!
Thanks for your efforts on this. I have copied xemacs-beta on my reply.
On Sun, Mar 29, 2015 at 9:52 PM, Henry S. Thompson <ht(a)inf.ed.ac.uk> wrote:
> OK, small progress. Using VS6:
>
> Adding the following to syswindows.h at around line 605, in the
> _non_-CYGWIN_HEADERS branch
>
> typedef int WINBOOL;
> typedef intptr_t LONG_PTR;
> typedef uintptr_t ULONG_PTR;
> typedef uintptr_t DWORD_PTR;
> /* #define PCIDLIST_ABSOLUTE_ARRAY LPCITEMIDLIST *
> typedef const PCIDLIST_ABSOLUTE *PCIDLIST_ABSOLUTE_ARRAY;* */
> typedef LPCITEMIDLIST PCIDLIST_ABSOLUTE;
>
> allows several of the -msw.c files to compile.
>
> More similar work is required, I think.
>
> Oops: the last typedef above is wrong - I read the commented-lines above
> that backwards!
Thanks for making sure the native Windows build continues to work.
I appreciate your taking the lead on this, because I haven't made any
substantive progress on this over the weekend.
Here are a few comments:
1. I have checked in the configure changes, so please make your next
patchsets based off of current version control. Please split your
patchset into two patches: one containing the w32api refactoring /
unicode regeneration and a second one containing the 64-bit
(DEVICE_TYPE_) changes.
2. Back when I was looking at updating the unicode definitions, I had
a slightly different regexp in lib-sr/make-mswin-unicode.pl:
my $rettype_re = "(SHSTDAPI_\\(${tok_ch}+${ws_re}\\*?\\)|${tok_ch}" .
"[A-Za-z_0-9 \t\n\r\f]*?${tok_ch})";
I think this regexp is a little more restrictive than the one you
used, but I'm not sure that it makes a difference.
3. Here are my current definitions for the syswindows.h block:
#else /* !CYGWIN_HEADERS */
#define W32API_VER(major,minor) 0
#define W32API_INSTALLED_VER 0
/* Some types that show up in Cygwin headers but not in Visual Studio headers,
and cause problems if we used Cygwin headers to generate
intl-auto-encap-win32.[ch]. */
typedef LPCVOID PCVOID;
typedef int WINBOOL;
typedef intptr_t LONG_PTR;
typedef uintptr_t ULONG_PTR;
typedef uintptr_t DWORD_PTR;
typedef ITEMIDLIST ITEMIDLIST_ABSOLUTE;
typedef ITEMIDLIST_ABSOLUTE *PIDLIST_ABSOLUTE;
typedef const ITEMIDLIST_ABSOLUTE *PCIDLIST_ABSOLUTE;
/* Defined in w32api/winuser.h */
#define GCLP_MENUNAME (-8)
#define GCLP_HBRBACKGROUND (-10)
#define GCLP_HCURSOR (-12)
#define GCLP_HICON (-14)
#define GCLP_HMODULE (-16)
#define GCLP_WNDPROC (-24)
#define GCLP_HICONSM (-34)
#define GWLP_USERDATA (-21)
#define GWLP_WNDPROC (-4)
#define GWLP_HINSTANCE (-6)
#define GWLP_HWNDPARENT (-8)
#define GWLP_USERDATA (-21)
#define GWLP_ID (-12)
#define DWL_MSGRESULT 0
#define DWL_DLGPROC 4
#define DWL_USER 8
#ifdef _WIN64
#undef DWL_MSGRESULT
#undef DWL_DLGPROC
#undef DWL_USER
#endif
#define DWLP_MSGRESULT 0
#define DWLP_DLGPROC DWLP_MSGRESULT + sizeof(LRESULT)
#define DWLP_USER DWLP_DLGPROC + sizeof(DLGPROC)
#endif /* CYGWIN_HEADERS */
Not all of these definitions are necessary, but I think it's probably
best to include the entire GCLP/GWLP definition block.
Thanks for digging in on this.
-Vin
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
- 3 participants
- 9 comments