XEmacs-Beta December 2017

xemacs-beta@xemacs.org

8 participants
18 discussions

Summary of XEmacs Issue Tracking System Issues 6 years, 4 months

XEmacs Issue Tracking System

ACTIVITY SUMMARY (2017-12-12 - 2017-12-19) 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. 574 open ( +0) / 323 closed ( +0) / 897 total ( +0) Open issues with patches: 13 Average duration of open issues: 2992 days. Median duration of open issues: 3203 days. Open Issues Breakdown new 266 ( +0) deferred 6 ( +0) napping 3 ( +0) verified 57 ( +0) assigned 145 ( +0) committed 19 ( +0) documented 3 ( +0) done/needs work 15 ( +0)

1 participants
0 comments

Summary of XEmacs Issue Tracking System Issues 6 years, 4 months

XEmacs Issue Tracking System

ACTIVITY SUMMARY (2017-12-05 - 2017-12-12) 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. 574 open ( +0) / 323 closed ( +0) / 897 total ( +0) Open issues with patches: 13 Average duration of open issues: 2985 days. Median duration of open issues: 3196 days. Open Issues Breakdown new 266 ( +0) deferred 6 ( +0) napping 3 ( +0) verified 57 ( +0) assigned 145 ( +0) committed 19 ( +0) documented 3 ( +0) done/needs work 15 ( +0)

1 participants
0 comments

XEmacs 21.4.24 hangs when fd is pipe 6 years, 4 months

Johann 'Myrkraverk' Oskarsson

Hi all, This pertains to 21.4.24 and earlier; I have not checked the 21.5 branch. There is a very rusty API called connec_to_file_descriptor() in process-unix.c. I am using it in an emodule. It works fine, from what I can tell. The problem I am encountering now, is that when the in fd is a pipe, and the pipe has less-than-internal-buffer-length it blocks on a subsequent read() system call. I am currently not sure how to "fix it". The culprit seems to be the if in Lstream_read(), inside the while loop. And the result is that it'll block on the read in filedesc_reader(). It's very wrong to adjust connect_to_file_descriptor() to make the resulting fd stream allow quits when read()ing. That just pushes the bug into user-visible space. Adding poll or select into the filedesc reader seems like the wrong solution, at first glance. Ideally, there should be a way to tell XEmacs to read() exactly once, but that also means getting rid of the while loop in Lstream_read() from what I can tell. Which may not be a good idea overall. Is there a way to fix this problem with minimal refactoring? Or am I cursed to have to fix all the internal buffering system in XEmacs to make connect_to_file_descriptor() usable with pipes? -- Johann I'm not from the internet, I just work there.

2 participants
3 comments

XEmacs 21.4.24 fails with the Clang Address Sanitizer at dump time 6 years, 4 months

Johann 'Myrkraverk' Oskarsson

Hi, This is what happens when I try to build XEmacs 21.4.24 with the address sanitizer enabled. This is the relevant ./configure switch: '--cflags=-std=gnu89 -g -fsanitize=address -fno-omit-frame-pointer' Dumping under the name xemacs ================================================================= ==56900==ERROR: AddressSanitizer: global-buffer-overflow on address 0x0001008b8da8 at pc 0x000100cba91a bp 0x7fff5fbf8110 sp 0x7fff5fbf78c8 READ of size 48 at 0x0001008b8da8 thread T0 #0 0x100cba919 in __asan_memcpy (libclang_rt.asan_osx_dynamic.dylib:x86_64+0x50919) #1 0x10015534c in pdump_dump_data dumper.c:634 #2 0x100154cab in pdump_scan_by_alignment dumper.c:828 #3 0x100153e8a in pdump dumper.c:1060 #4 0x1000fc22d in Fdump_emacs emacs.c:3217 #5 0x100100189 in Feval eval.c:3335 #6 0x100102f17 in Fprogn eval.c:775 #7 0x1000ffa3d in Feval eval.c:3308 #8 0x100102b83 in Fif eval.c:691 #9 0x1000ffa3d in Feval eval.c:3308 #10 0x100101e6c in Feval eval.c:3414 #11 0x1005312e7 in readevalloop lread.c:1449 #12 0x10052c86b in Fload_internal lread.c:737 #13 0x1001007a6 in Feval eval.c:3335 #14 0x10010d82b in condition_case_1 eval.c:1652 #15 0x10007f7cf in top_level_1 cmdloop.c:206 #16 0x10010c69b in internal_catch eval.c:1318 #17 0x10007ebec in initial_command_loop cmdloop.c:285 #18 0x1000f2d84 in xemacs_21_4_24_i386_apple_darwin14_5_0 emacs.c:2460 #19 0x1000fa5b5 in main emacs.c:2829 #20 0x7fff8818b5c8 in start (libdyld.dylib:x86_64+0x35c8) 0x0001008b8da8 is located 0 bytes to the right of global variable 'guts_of_unbound_marker' defined in 'symbols.c:3238:40' (0x1008b8d80) of size 40 SUMMARY: AddressSanitizer: global-buffer-overflow (libclang_rt.asan_osx_dynamic.dylib:x86_64+0x50919) in __asan_memcpy Shadow bytes around the buggy address: 0x100020117160: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x100020117170: 00 00 f9 f9 f9 f9 f9 f9 00 00 00 f9 f9 f9 f9 f9 0x100020117180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f9 0x100020117190: f9 f9 f9 f9 00 00 00 00 00 00 f9 f9 f9 f9 f9 f9 0x1000201171a0: 00 00 00 00 00 00 00 00 00 f9 f9 f9 f9 f9 f9 f9 =>0x1000201171b0: 00 00 00 00 00[f9]f9 f9 f9 f9 f9 f9 00 00 00 00 0x1000201171c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1000201171d0: f9 f9 f9 f9 00 00 00 00 00 00 00 00 01 f9 f9 f9 0x1000201171e0: f9 f9 f9 f9 00 00 00 00 00 00 00 00 00 00 00 00 0x1000201171f0: 00 00 00 00 f9 f9 f9 f9 00 00 00 00 00 00 00 00 0x100020117200: 00 00 00 00 f9 f9 f9 f9 00 00 00 00 00 00 00 00 Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb ==56900==ABORTING -- Johann I'm not from the internet, I just work there.

2 participants
1 comments

XEmacs crashes or hangs when running the update.el stage 6 years, 4 months

Mats Lidell

Hi, Gentoo has recently switched no using position independent code generation and in addition to that maybe other updates as well like new version of gcc etc. Whatever has changed both 21.4 and 21.5 ebuilds now fail due to different reasons but both fail in the dump step ether by core dumping or by hanging for ever. I have create the following two tickets in the gentoo bug tracker where you will find some more info (but I can of course create more info if needed.) https://bugs.gentoo.org/639214 https://bugs.gentoo.org/639642 I have tried to compile with using the -fno-pie flag in order to go back to position dependent code but that did not do the trick. I need some suggestions on how to debug this and even better some ideas what can cause this and how to fix this. This is a show stopper for XEmacs on Gentoo since moving to the new Gentoo profile requires rebuild of all packages. Yours -- %% Mats

2 participants
5 comments

Re: XEmacs head breaks on macOS 6 years, 4 months

Aidan Kehoe

Ar an seachtú lá is fiche de mí na Samhain, scríobh Michael Sperber: > Aidan Kehoe <kehoea(a)parhasard.net> writes: > > > Ar an séú lá is fiche de mí na Samhain, scríobh Michael Sperber: > > > > > Here goes ... > > > > Great, thank you. There’s a good chance this is an issue that Steve > > reported to me, addressed for him with > > https://bitbucket.org/xemacs/xemacs/commits/a3aa49cd . Please update and > > get back to me if it’s still unstable. > > Still unstable. (I updated on Friday, and bisected my way to the commit > I sent you.) OK. For unrelated reasons, I recently started using a build with NEWGC support on OS X regularly and have encountered the instability you describe. It seems newgc and the relocating allocator on OS X don’t play well together. I’ll investigate further over the next couple of weeks. -- ‘As I sat looking up at the Guinness ad, I could never figure out / How your man stayed up on the surfboard after forty pints of stout’ (C. Moore)

1 participants
0 comments

None 6 years, 4 months

Mats Lidell

1 participants
0 comments

Summary of XEmacs Issue Tracking System Issues 6 years, 4 months

XEmacs Issue Tracking System

ACTIVITY SUMMARY (2017-11-28 - 2017-12-05) 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. 574 open ( +0) / 323 closed ( +0) / 897 total ( +0) Open issues with patches: 13 Average duration of open issues: 2978 days. Median duration of open issues: 3189 days. Open Issues Breakdown new 266 ( +0) deferred 6 ( +0) napping 3 ( +0) verified 57 ( +0) assigned 145 ( +0) committed 19 ( +0) documented 3 ( +0) done/needs work 15 ( +0)

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 December 2017